小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
Redis 的集群模式是否让你眼花缭乱呢？为什么有的时候三个，有的时候两个，有的时候六个，九个。其实当我们系统很小时有一个就够了，但是我们往往想做到读写分离，为数据搞一个备份，那么主从复制就来了。但是呢主从复制下，主节点挂了，只能手动去设置主节点，不能自动进行，这时哨兵模式就出现了，通过哨兵监控各个节点，主机挂了，哨兵感知到，就会有一个哨兵发起投票选举自己为领导者，从而由自己进行故障转移。但是主从加哨兵只能保证高可用与读写分离，并不能解决写并发的压力，然后多主节点的redis cluster就出现了，将三种模式整合，就构成最小六个节点的高并发，高可用的redis集群。
1. Redis Cluster 的基本概念
官方
Redis Cluster 是提供在多个Redis 节点间共享数据的程序集
Redis Cluster 不支持keys命令
简单来说：Redis 集群就是就是多个Redis组合实现存储，集群会自动将数据存入不同的节点，部分Redis宕机，集群任然可以处理客户端指令，只是部分数据可能读取不到。
2. Redis Cluster 数据分片
Redis Cluster 并没有使用一致性hash的概念，而是引入hash槽的概念。
在Redis Cluster中一个有16384个哈希槽，
每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:
- 节点 A 包含 0 到 5500号哈希槽.
- 节点 B 包含5501 到 11000 号哈希槽.
- 节点 C 包含11001 到 16384号哈希槽.
这种模式很容易进行集群的缩展，扩展节点只需要分出部分哈希槽到新的节点，缩减节点只需要将去掉节点的哈希槽，分给集群其他节点即可，无需停机即可完成。
3. Redis 集群模型
3.1 Redis 主从复制模型
为保证写入Redis中的数据处于一直可以访问的状态，就需要将数据备份。这就是Redis的主从复制模型。
启动一台slave 的时候，会发送一个psync命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制。master就会启动一个线程，生成RDB快照，还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命名都发给slave。 传输过程中有什么网络问题啥的，会自动重连的，并且连接之后会把缺少的数据补上的。 RDB快照的数据生成的时候，缓存区也必须同时开始接受新请求，不然你旧的数据过去了，同步期间的增量数据就会缺失
3.2 Redis 哨兵模式
Redis的哨兵模式是为解决Redis主从模式，主节点宕机后，从结点无法代替主节点提供写服务问题而诞生的。
Sentinel 的作用：
- 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
- 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
Sentinel1先检测到这个结果，系统并不会马上进行failover过程，仅仅是Sentinel1主观的认为master服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。
哨兵必须用三个实例去保证自己的健壮性的，哨兵+主从并不能保证数据不丢失，但是可以保证集群的高可用。
为啥不能用两个哨兵：
两个哨兵的时候：
使用两个哨兵，主节点宕机，主节点下哨兵也挂了，只剩下一个哨兵，它无法让别人选举它为领导者，就无法实现切换。
三个个哨兵的时候：
使用三个哨兵，主节点宕机，主节点下哨兵也挂了，剩下两个哨兵，两个选举出一个哨兵进行故障转移，就可以实现切换。
3.3 Redis Cluster 模式
Redis Cluster 则主要是因为在主从模式中只有master节点支持写入，当并发写请求较多时，主从模式并不可以缓解写压力。那么我们是不是就可以多增加几个master就可以解决这个问题了，Redis Cluster就由此而生。
3.4 三者结合Redis Cluster 高可用模式
最少每个master配一个slave,不然哨兵就没有意义
4. Redis Cluster 一致性保证
Redis Cluster 是不保证数据强一致性.在一定情况下可能会发生写丢失。
- 客户端发送写命令到服务端。
- 服务端完成响应。
- 主结点将写操作复制到从结点上
出现数据不一致的情况分析：
-
服务端响应客户端发生在数据同步之前（这样可以极大提高响应速度，在一致性和性能面前，Redis选择了性能）。数据在复制失败，就会造成数据的不一致。
-
集群出现网络分区
集群包含A、B、C、A1、B1、C1六个节点，其中A、B、C为主结点，A1、B1、C1为从结点。网络分裂为 A 、C 、A1 、B1 和 C1 ，另一部分则包含节点 B 和客户端 Z 。Z向B发送命令，仍可写入，但是如果在网络分裂期间，数量多的一方将B1选举为主节点，这时客户端写入B的数据就会丢失。
