redis使用中存在的问题及如何避免(二)

redis使用中存在的问题及如何避免(一)阐述了redis的阻塞问题及缓存穿透问题，本文将继续总结redis在使用中的问题及方案。

• 无底洞问题
  随着数据量和访问量的增加，须要增长更多的节点作水平扩容，键值会分布到更多的节点上，若客户端进行批量操做则一般会从不一样的节点上获取数据，相比于单机批量操做只涉及一次网络操做，分布式批量操做会涉及屡次网络交互。
  随着节点数的增多，客户端一次批量操做涉及的网络交互耗时也会不断增大；网络链接数增多，对节点性能也有必定影响。
  更多的节点不表明更高的性能，这就是无底洞问题。

• 雪崩问题
  因为缓存层承载着大量请求，有效的保护了存储层，但若是缓存层因为某些缘由不能提供服务，全部请求都会压到存储层，存储层流量暴增，致使存储层也会级联宕机。

  1. 保证缓存层服务高可用性
     Redis Sentinel或者Redis Cluster都实现了高可用
  2. 隔离限流降级
     对重要的资源Redis、Mysql、外部接口调用都进行隔离，机器、进程、线程等层面均可作隔离。
     可以使用漏桶、令牌桶等方式进行限流操做，将流量挡在应用上层。
     对出现问题的数据或功能作降级处理，友好的展现给用户。
  3. 提早演练测试

• 热点key重建优化
  缓存+过时时间策略便可以加速数据读写，又保证数据的按期更新，若出现以下两个问题，可能会对应用产生致命危害：

  1. 当前key是一个热点key，并发量很是大

  2. 重建缓存不能在短期内完成，如：复杂的sql、屡次IO、多个依赖等。
     在缓存失效的瞬间，有大量的线程来建立缓存，形成后端负载加大，甚至致使系统崩溃。
     方案：

     a.互斥锁
       只容许有一个线程去重建数据，其余线程等待构建完缓存，从新从缓存中获取数据。
     b.永远不过时
       设置逻辑过时时间，判断逻辑时间和当前时间大小，而后异步去构建数据覆盖老数据。
       
     a方案思路简单，能保证一致性；但代码复杂度增大，存在死锁风险，存在线程池阻塞风险。
     b方案基本能够杜绝热点key问题；但不保证一致性，逻辑过时时间增长代码维护成本。