江苏龙网

  1. 首页 > 人文 > >

辛德蕾拉|面试官：Redis缓存了解吗？面对这11道题是否有很多问号？(12)


如果一个内存队列中可能积压的更新操作特别多 ， 那么你就要加机器 ， 让每个机器上部署的服务实例处理更少的数据 ， 那么每个内存队列中积压的更新操作就会越少 。
其实根据之前的项目经验 ， 一般来说 ， 数据的写频率是很低的 ， 因此实际上正常来说 ， 在队列中积压的更新操作应该是很少的 。 像这种针对读高并发、读缓存架构的项目 ， 一般来说写请求是非常少的 ， 每秒的 QPS 能到几百就不错了 。
我们来实际粗略测算一下 。
如果一秒有 500 的写操作 ， 如果分成 5 个时间片 ， 每 200ms 就 100 个写操作 ， 放到 20 个内存队列中 ， 每个内存队列 ， 可能就积压 5 个写操作 。 每个写操作性能测试后 ， 一般是在 20ms 左右就完成 ， 那么针对每个内存队列的数据的读请求 ， 也就最多 hang 一会儿 ， 200ms 以内肯定能返回了 。
经过刚才简单的测算 ， 我们知道 ， 单机支撑的写 QPS 在几百是没问题的 ， 如果写 QPS 扩大了 10 倍 ， 那么就扩容机器 ， 扩容 10 倍的机器 ， 每个机器 20 个队列 。
（2）读请求并发量过高
这里还必须做好压力测试 ， 确保恰巧碰上上述情况的时候 ， 还有一个风险 ， 就是突然间大量读请求会在几十 毫秒的延时 hang 在服务上 ， 看服务能不能扛的住 ， 需要多少机器才能扛住最大的极限情况的峰值 。
但是因为并不是所有的数据都在同一时间更新 ， 缓存也不会同一时间失效 ， 所以每次可能也就是少数数据的缓存失效了 ， 然后那些数据对应的读请求过来 ， 并发量应该也不会特别大 。
（3）多服务实例部署的请求路由
可能这个服务部署了多个实例 ， 那么必须保证说 ， 执行数据更新操作 ， 以及执行缓存更新操作的请求 ， 都通过 Nginx 服务器路由到相同的服务实例上 。
比如说 ， 对同一个商品的读写请求 ， 全部路由到同一台机器上 。 可以自己去做服务间的按照某个请求参数的hash 路由 ， 也可以用 Nginx 的 hash 路由功能等等 。
（4）热点商品的路由问题 ， 导致请求的倾斜
万一某个商品的读写请求特别高 ， 全部打到相同的机器的相同的队列里面去了 ， 可能会造成某台机器的压力过大 。 就是说 ， 因为只有在商品数据更新的时候才会清空缓存 ， 然后才会导致读写并发 ， 所以其实要根据业务系统去看 ， 如果更新频率不是太高的话 ， 这个问题的影响并不是特别大 ， 但是的确可能某些机器的负载会高一些 。
10、redis 的并发竞争问题是什么？如何解决这个问题？了解redis 事务的 CAS 方案吗？面试官心理分析这个也是线上非常常见的一个问题 ， 就是多客户端同时并发写一个 key ， 可能本来应该先到的数据后到了 ， 导致数据版本错了；或者是多客户端同时获取一个 key ， 修改值之后再写回去 ， 只要顺序错了 ， 数据就错了 。
而且 redis 自己就有天然解决这个问题的 CAS 类的乐观锁方案 。
面试题剖析某个时刻 ， 多个系统实例都去更新某个 key 。 可以基于 zookeeper 实现分布式锁 。 每个系统通过zookeeper 获取分布式锁 ， 确保同一时间 ， 只能有一个系统实例在操作某个 key ， 别人都不允许读和写 。
辛德蕾拉|面试官：Redis缓存了解吗？面对这11道题是否有很多问号？你要写入缓存的数据 ， 都是从 mysql 里查出来的 ， 都得写入 mysql 中 ， 写入 mysql 中的时候必须保存一个时间戳 ， 从 mysql 查出来的时候 ， 时间戳也查出来 。
每次要写之前 ， 先判断一下当前这个 value 的时间戳是否比缓存里的 value 的时间戳要新 。 如果是的话 ， 那么可以写 ， 否则 ， 就不能用旧的数据覆盖新的数据 。
11、生产环境中的 redis 是怎么部署的？面试官心理分析看看你了解不了解你们公司的 redis 生产集群的部署架构 ， 如果你不了解 ， 那么确实你就很失职了 ， 你的redis 是主从架构？集群架构？用了哪种集群方案？有没有做高可用保证？有没有开启持久化机制确保可以进行数据恢复？线上 redis 给几个 G 的内存？设置了哪些参数？压测后你们 redis 集群承载多少QPS？


推荐阅读


上一篇：少年帮|Postman 测试接口南波万？资深程序员：那是你还没碰到它

下一篇：军事|又到惜别季，听这些老兵讲他们和战舰的故事