Redis分布式方案的发展和演变
主从复制时代
跟Kafka、RocketMQ、MySQL、ZooKeeper一样，Redis支持集群的架构，集群的节点有主节点和从节点之分。主节点叫master，从节点叫slave。slave会通过复制的技术，自动同步master的数据。
Redis主从复制解决了数据备份和一部分性能的问题。但是没有解决高可用的问题，在一主一从或者一主多从的情况下，如果主服务器挂了，对外提供的服务就不可用了，需要手动把从服务器切换成主服务器，然后再把剩余节点设置为它的从节点，这个比较费时，还会造成一定时间的服务不可用。
Sentinel哨兵时代
从Redis2.8版本起，提供了一个稳定版本的Sentinel哨兵来解决高可用的问题，它的思路是启动奇数个Sentinel的服务来监控Redis服务器来保证服务的可用性。
为了保证监控服务器的可用性，我们会对Sentinel做集群部署，Sentinel既监控所有的Redis服务，Sentinel之间也相互监控。 Sentinel本身没有主从之分，地位是平等的，只有Redis服务节点有主从之分。
Sentinel通过Raft共识算法，实现Sentinel选举，选举出一个leader，由leader完成故障转移。
Raft共识算法在线演示：http://thesecretlivesofdata.com/raft（非常直观，通俗易懂）
- Raft算法的应用很广泛，比如加密货币BTB，Spring Cloud注册中心Consul也用到了Raft算法。
- Raft算法的核心思想是：先到先得，少数服从多数。Sentinel的Raft实现跟原生的算法是有所区别的，但是大体思想一致。
哨兵的不足：主从切换的过程中会丢失数据，因为只有一个master；只能单点写，没有解决水平扩容的问题。
Redis Cluster 时代
Redis Cluster是在Redis 3.0的版本正式推出的，用来解决分布式的需求，同时也可以实现高可用，它是去中心化的，客户端可以连接到任意一个可用的节点。Redis Cluster可以看成是由多个Redis实例组成的数据集合。客户端不需要关注数据的子集到底存储在哪个节点，只需要关注这个集合整体。
Redis创建了16384个槽（slot），每个节点负责一定区间的slot。比如Node1负责0-5460，Node2负责5461-10922，Node3负责10923-16383。
对象分布到Redis节点的时候，首先是对Key用CRC16算法计算再%16384，得到一个slot的值，数据落到负责这个slot的Redis节点上。
key与slot的关系是永远不会变的，会变的只有slot和Redis节点的关系。
如果想让很多个key同时落在同一个节点怎么办呢，只需要在key里面加入{hash tag}即可。
Redis在计算槽编号的时候只会获取{}之间的字符串进行槽编号计算，如下所示：
user{666}base=...
user{666}fin=...
Redis-Cluster 特点
无中心结构。
数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布。
可扩展性，可线性扩展到1000个节点（官网推荐不超过1000个），节点可动态添加或删除。
高可用性，部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升。
降低运维成本，提高系统的扩展性和可用性。
Redis Cluster既能实现主从的角色分配，又能够实现主从切换，相当于集成了Replication和Sentinel的功能，目前来看属于最优解方案。
