Redis使用小结

参与过多个系统的架构评审，其中，在分布式缓存Redis的部署方式以及使用方式上发现各系统五花八门的，故拿出来简要总结一下~

【主从模式】Redis缺省支持主从模式（Master-Slave），一主多从，Master负责读和写，Slave和Master同步支持读服务，从而实现缓存的读写分离。问题：Master为单点，挂，Slave不会升级为Master，Redis整体对外服务为不可写但仍可读……

【哨兵模式】增加哨兵（Sentinel）进程服务“守卫”Redis服务，Sentinel发现Master节点挂了以后，会从多个Slave中重新选举一个成为Master，原先Master在重启之后作为Slave对外服务；Sentinel也有挂掉的可能，所以会启动多个形成哨兵集群。客户端Client连接Sentinel的ip和port，由sentinel来提供Redis的高可用。问题：仍旧是单主，当数据量过大会出现Master放不下……

【Codis模式】单纯的哨兵模式没有解决Redis单主的问题，造成吞吐量瓶颈。豌豆荚公司提供了一个分布式Redis 解决方案，支持多主扩展。其核心思想是提供Codis-Proxy服务，处理和转发请求到Redis组（1主多从），对于客户端保持透明，Codis-Proxy采用ZooKeeper避免单点，但也额外的增加了部署复杂度。

【Cluster模式】为解决单主容量有限问题以及提高吞吐能力，Redis官方给出了Cluster集群模式（Redis 3.0之后版本支持，事实上在当时已经滞后于业界对Redis集群的需求了）。Redis-Cluster通过分槽算法建立虚拟分区，所有的键根据哈希函数映射到0 ～ 16383，计算公式：slot= CRC16(key)&16383。每一个Redis节点负责维护一部分槽以及槽所映射的键值数据，Redis节点之前通过Gossip协议进行通讯并完成彼此间的监测和复制功能。集群模式支持多个节点之间自动分割数据集，在某一节点遇到故障或无法与集群其余节点通信时仍能继续提供服务！

【中间件模式】也有通过HAProxy/Twemproxy + Keepalived + Sentinel等组合来完成Redis的高可用的，即Redis分组，分别以M-S模式部署，Sentinel充当状态监控管理者，HA或Tw完成Redis的负载均衡，KA保持HA、Tw的高可用性，通过VRRP协议提供一个虚拟IP供Client来访问。

【隔离模式】凡事有立有破，缓存的引入为了提高读写效率，但过度倚重集群会将所有业务数据“分槽”，当Redis局部出现集体性故障，同一业务数据因被“打散”存储而影响处理和有针对性的补救，有可能造成多个业务同时产生问题。基于业务的缓存区域划分，缓存数据通过分区彼此不受影响，且可以有针对性的配置扩展，同时在Client端以“缓存不可靠”为原则进行架构设计和客户端代码开发（建立业务连接池等），能保持的整体缓存架构相对简单、可控；此外，一套Master-Slave-Sentinel的缓存单元也有利于Docker化、可扩展、平台化……

【缓存穿透】一般缓存都是按照key去获取缓存数据，如果不存在对应的value，就去后端系统（一般是DB或二级服务）查找。如果key对应的value是一定不存在的，并且以这样的key产生大并发请求，就会对后端系统造成很大的压力，这就叫做缓存穿透。可以进行：1）对绝对不存在的key进行识别和过滤，参见布隆过滤器等；2）对（暂时）查询结果为空的key进行缓存，可以采用特殊值标识，如果对应Key数据产生时，清除Key缓存。

【缓存雪崩】当缓存重启或者大量缓存集中在某一个时间段失效，可能会产生大量缓存穿透，造成缓存雪崩，给后端系统带来很大压力。可以进行：1）通过加锁或者队列来控制读数据库写缓存的线程数量；2）不同key设置不同的过期时间，让缓存失效的时间点尽量均匀；3）二级缓存或备用缓存……不管哪种方式，都会增加实现复杂度，需具体问题具体分析。