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

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

• 雪崩问题
  由于缓存层承载着大量请求，有效的保护了存储层，但如果缓存层由于某些原因不能提供服务，所有请求都会压到存储层，存储层流量暴增，导致存储层也会级联宕机。

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

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

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

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

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