一、前言
多年前曾看到过一篇讲解Redis的文章，文章以单节点部署存在的不足开始，一步一步寻找解决方案来提高Redis服务的可用性，最终引出了Redis Cluster与Codis两种不同的集群方案，并给出了两种集群方案的优劣，文章质量非常高。
当时虽然理解了但后面就基本忘了差不多了，不如今天用自己的语言按照这篇文章的思路尝试自己描述一遍加深记忆与理解。
二、Redis部署方案的演进
1. 单点部署
系统中只有一个redis服务器，所有请求都打到这一台机器上。
随着业务发展，整个系统对redis读的请求量逐渐增加，一台机器逐渐扛不住，所以我们增加了两台从库来分担主库读压力，所以又有了主从架构
2. 简单主从
写的请求全部打到Master节点，读的请求分担到Slave节点，Slave是readonly的。
好了，我们现在抗住了较大的读请求，但是这个系统跟上面的单点系统都存在一个问题：Master节点挂掉后，整个系统不可写（因为Slave节点还存活所以系统还可以支撑部分读的请求），导致系统不可用。
虽然可以在发现故障后手动切换Slave节点为Master，但是人工操作还是需要消耗一段时间的，还是不可接受的。我们还需要优化架构提高系统可用性，因为我们引入哨兵机制，使得Master挂点后由Slave节点能够自动切换为Master继续提供服务。
3. 哨兵模式
Redis中提供了Sentinel的能力，Sentinel以一个单独进程的形式存在，它可以监控Master节点，一旦master节点挂点会立即选出一个Slave节点切换为新Master。因为Sentinel也存在单点故障的隐患，所以Sentinel通常也是一个集群形式。
Sentinel会监听Master节点与Slave节点，同时它们之间也会互相监听运行状态并交换节点检测的状态。
一个Sentinel检测到一个实例超过阈值时间没有回复PING，那这个实例会被该Sentinel标记为主观下线。如果Master被标记主观下线则所有Sentinel都要以每秒1次频率判断该Master是否下线，当超过一定数量的Sentinel都认为Master下线，则Master会被标记为客观下线，然后协商出来一个Slave作为Master节点。
到此为止我们已经实现了Redis的高可用，不过这时我们业务进入了一个高速发展的阶段，key的数量达到了一个非常高的量级，redis内存不断告急，运维不断的扩容，RDB文件这时变得特别大，主从同步也变得非常缓慢，另外这时写的请求量也上来了，单Master已经扛不住了，这时就需要分片存储了，将key均匀的分布到多个Master上，减小单台redis内存，分担单个Master压力。
4. Redis Cluster
Redis Cluster 是redis官方提供的分布式方案，它虚拟出16384个槽，通过crc16(key) % 16384计算出key映射到了哪个槽上，集群中的每个节点维护其中一部分槽，节点间会互相通信告诉其他节点自己维护了哪些槽。
客户端一开始会随机选择一个节点连接，然后发送自己要操作的key，该节点通过crc16(key) % 16384计算出key所在的槽，如果该槽由自己维护那就直接返回操作结果了，如果不是由它维护的槽它会返回一个MOVED操作，客户端根据MOVED操作提供的信息转向正确的节点。
5. Codis
Codis是豌豆荚开源的Redis分布式方案，Codis分为1024个槽，key到槽的算法为crc32(key) % 1024 槽位与节点的映射关系存储在CodisProxy上，因为CodisProxy也存在单点故障隐患，所以CodisProxy也要做集群。redis客户端连接到CodisProxy上而非真实的redis节点。
CodisProxy实际是利用Zookeeper来存储映射关系，不同CodisProxy用Zookeeper来同步映射。
Codis中还有一个codis-ha (ha：High Availability)的组件，用来监控CodisProxy的状态，同时替代了哨兵用来执行节点的主从切换，从而实现高可用。
