企业网站seo运营,口碑营销方案怎么写,贪玩游戏官网,网站备案会掉吗在测试工作中#xff0c;涉及到与 redis 交互的场景变的越来越多了。关于redis本身就不作赘述了#xff0c;网上随便搜#xff0c;本人也做过一些整理。
今天只来复盘一下#xff0c;在测试过程中与 redis 的二三事儿。其中提到的案例是经过抽象化的#xff0c;用作辅助说…
在测试工作中涉及到与 redis 交互的场景变的越来越多了。关于redis本身就不作赘述了网上随便搜本人也做过一些整理。
今天只来复盘一下在测试过程中与 redis 的二三事儿。其中提到的案例是经过抽象化的用作辅助说明作用仅供参考。 一、更新 Key 异常
注意点先删除原 key 再存还是直接覆盖原 key
比如之前 A 服务每8小时去查询一次数据库更新到缓存里去。后来需求调整变成当数据库里有变动的时候就会发送MQ消息给服务 A然后A就去全量拉取库里数据再更新到缓存。
开发小哥实现的是先删除key再更新那么可能会导致这个时间如果有大量的请求进来就不能命中缓存。于是乎建议当从数据库拉来数据之后可以先和redis中原来的key值进行对比删除多余的缓存其他的覆盖更新。 二、Key的删除和丢失
注意点考虑key被删除或者key丢失后对上游的影响。
比如服务A 会同步一类数据到 redis然后发消息告诉 服务B。B 收到消息后拿到 redis 数据去找自己那边 MongoDB里的对应 key做更新操作若查不到key就会删除数据。
此时如果 redis 里产生了数据丢失key就不存在了那么同步过后会导致 MongoDB 里的数据被勿删。
于是乎这里建议方案是redis 那边涉及要删除key的话就更新key的值为空[]这时候 MongoDB 查询到值为空的key就去删除对应数据。 另外如果redis那边key 丢失了MongoDB这边也别就删数据了去调用一个实时接口去查询数据然后更新。 三、KEY 过期策略不当造成内存泄漏
首先回顾一下 redis 中 ttl key指令
当 key 不存在时返回 -2当 key 存在但没有设置剩余生存时间时返回 -1否则返回 key 的剩余生存时间单位是 s
通常大多数业务用到redis 都会设置过期时间。接下来了解一下 key 过期是如何清理的。
定期清理
Redis会定期主动淘汰一批已过期的key随机抽取一批key检查。
缺点可能存在很多KEY已过期仍未清理。
惰性清理
在获取某个 key 的时候redis 会检查一下这个 key 如果设置了过期时间并且已经过期就会删除这个 key不会返回任何东西。
缺点如果存在很多未去查询的过期key就没法走到惰性删除于是可能会有大量过期的key堆积在内存里导致内存耗尽。
一般来说业务会惰性和定期清理配合使用。
内存淘汰机制
但是如果定期清理漏掉了很多过期的key然后你也没及时去查也就没走惰性删除。此时依旧有可能大量过期的key堆积在内存里导致内存耗尽。
这时候需要内存淘汰机制有如下几个
noeviction当内存不足以容纳新写入数据时新写入操作会报错。这个一般很少用。allkeys-lru当内存不足以容纳新写入数据时在键空间中移除最近最少使用的key这个是最常用的。allkeys-random当内存不足以容纳新写入数据时在键空间中随机移除某个key。volatile-lru当内存不足以容纳新写入数据时在设置了过期时间的键空间中移除最近最少使用的key。volatile-random当内存不足以容纳新写入数据时在设置了过期时间的键空间中随机移除某个key。volatile-ttl当内存不足以容纳新写入数据时在设置了过期时间的键空间中有更早过期时间的key优先移除。
以上可以作个了解。
现在我也找了很多测试的朋友做了一个分享技术的交流群共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源没人解答问题坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化性能安全测试开发等等方面有一定建树的技术大牛
分享他们的经验还会分享很多直播讲座和技术沙龙
可以免费学习划重点开源的
qq群号110685036【暗号csdn999】 四、查询Redis异常时处理
很多时候redis 只是做一个缓存机制如果redis异常或者未取到数据是否有实时获取数据的兜底方案查接口 or 查库需要考虑。 五、redis 穿透、击穿、雪崩
穿透
用户想要查询一个数据发现redis内存数据库中没有也就是说没有命中缓存也是会向持久层数据库查询发现也没有那么本次查询失败。 如果此时用户很多高并发场景下都去查这个数据由于缓存都没有命中于是压力直接打到持久层数据库那里这就是缓存穿透。
解决方案可以用布隆过滤器、返回空对象设置过期时间。
击穿
缓存击穿是指一个key非常热点在不停的扛着高并发如果这个key失效了在失效的瞬间持续的并发量就会穿破缓存直接打到持久层数据库就像一个防御墙被凿开一个洞。
解决方案可以设置热点数据永不过期、加互斥锁等。
雪崩
是指在某一个时间段缓存集中过期失效或者redis宕机了。
解决方案
事前redis 高可用主从哨兵redis cluster避免全盘崩溃。事中本地 ehcache 缓存 hystrix 限流降级避免 MySQL 被打死。事后redis 持久化一旦重启自动从磁盘上加载数据快速恢复缓存数据。 六、Redis死锁
Redis锁小心使用不当造成锁不能释放陷入死锁。
目前常用的2种锁
SET Key UniqId Seconds
仅在单实例的场景下是安全的。如果不使用setnxexpiredel中间环节断了仍可能造成死锁 如果不用SET Key UnixTimestamp Seconds NX高并发下可能存在相同时间戳。
分布式Redis锁Redlock
此种方式比原先的单节点的方法更安全。
安全性在同一时间不允许多个Client同时持有锁。活性死锁锁最终应该能够被释放即使Client端crash或者出现网络分区通常基于超时机制。容错性只要超过半数Redis节点可用锁都能被正确获取和释放。 七、Redis持久化
当Redis数据需要长久有效时需要考虑是否做RDB和AOF持久化一般RDB和AOF配合使用但做持久化会影响性能。
目前接触到的业务做持久化的很少见。比如有个推荐系统Redis数据是长久有效的但却为了响应快不影响性能未做持久化而采用了其他的降级方案Hbase以及业务的兜底等。 八、缓存与数据库双写时的数据一致性
一般来说就是如果你的系统不是严格要求缓存数据库必须一致性的话允许缓存跟数据库偶尔不一致的情况那么最后好不要做这个一致性方案。
如果实现这个方案读请求和写请求串行化串到一个内存队列里去这样就可以保证一定不会出现不一致的情况。
但是串行化之后就会导致系统的吞吐量会大幅度的降低用比正常情况下多几倍的机器去支撑线上的一个请求。
还有一种适中的方式就是就是先更新数据库然后再删除缓存。可能会暂时产生不一致的情况但是发生的几率特别小。这时候通常并行写数据库和缓存可以加个事务都写成功才成功有一个环节失败了就回滚事务全失败。
关于双写一致性的问题其实可以另起一个篇幅来说了有兴趣的可以网上搜索一下后续可能会再进行整理。
END今天的分享就到此结束了点赞关注不迷路
