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

摘要：使用中存在的问题及如何避免一阐述了的阻塞问题及缓存穿透问题，本文将继续总结在使用中的问题及方案。更多的节点不代表更高的性能，这就是无底洞问题。可使用漏桶令牌桶等方式进行限流操作，将流量挡在应用上层。

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

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

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

保证缓存层服务高可用性
Redis Sentinel或者Redis Cluster都实现了高可用

隔离限流降级
对重要的资源Redis、Mysql、外部接口调用都进行隔离，机器、进程、线程等层面都可做隔离。
可使用漏桶、令牌桶等方式进行限流操作，将流量挡在应用上层。
对出现问题的数据或功能做降级处理，友好的展示给用户。

提前演练测试

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

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

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

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