Redis集群的三种模式

复制：实现数据库读写分离，提高服务器的负载能力，master主要负责写操作，slave负责读操作。

主从模式

思想就是支持一主多从（Master、Slave）。有如下特点：

Master可进行读写操作，当写操作导致数据变化时，将自动同步给Slave。Slave通常是只读的，并且接受从Master同步过来的数据。
一台Master可以有多台Slave，但每台Slave只能有一个Master。
某台Slave宕机不影响其他Slave和Master的读写，重新启动后会将数据重新从Master同步过来。
Master宕机后不影响Slave的读，但该集群不再提供对Redis的写入功能。
Master宕机后不会从Slave中选举主节点。
在此种模式下，我们可以对Redis集群做容灾备份和读写分离，但是要注意，容灾备份并不能拯救你的误操作，因为无论增删改，Redis都将其作为写，同步到每个Slave节点上，所以容灾，是指不可预知的错误导致数据丢失，这种情况下可以从Slave节点中找到原数据的备份，从而进行数据恢复。

复制过程【redis2.8之后支持断点续传】：

1：当一个从数据库启动时，会向主数据库发送sync命令
2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来
3：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。
4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。

如果用主从复制，要确保master激活了持久化，或确保它不会在当掉后自动重启。原因：
slave是master的完整备份，因此如果master通过一个空数据集重启，slave也会被清掉。
配置redis复制功能时如果主数据库设置密码，需要在从数据的配置文件中通过masterauth参数设置主数据库的密码，这样从数据库在连接主数据库时就会自动使用auth命令认证。相当于做了一个免密码登录。

哨兵（Sentinel）模式

哨兵模式的工作特点：

哨兵模式是建立在主从模式的基础上，当Master节点宕机后，哨兵会从Slave节点中选择一个节点作为Master，并修改它们的配置文件，使其他的Slave指向新的Master。
当原先宕机的Master节点重新启动时，他将不再是Master，而是作为新Master的一个Slave节点存在。
哨兵节点是一个特殊的Redis节点（不存储数据），本质上也是一个进程，所以也有挂掉的可能，所以哨兵也存在集群模式。

redis的sentinel系统用于管理多个redis服务器，该系统主要执行三个任务：监控、提醒、自动故障转移。

1、监控（Monitoring）： Redis Sentinel实时监控主服务器和从服务器运行状态，并且实现自动切换。
2、提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Redis Sentinel 可以向系统管理员发送通知，也可以通过 API 向其他程序发送通知。
3、自动故障转移（Automatic failover）：当一个主服务器不能正常工作时，Redis Sentinel 可以将一个从服务器升级为主服务器，并对其他从服务器进行配置，让它们使用新的主服务器。当应用程序连接Redis 服务器时， Redis Sentinel会告之新的主服务器地址和端口。

哨兵模式工作原理：

每隔10秒，每个哨兵节点会向Master和Slave节点发送info命令获取最新的拓扑结构。
每隔1秒，每个哨兵节点会向Master和Slave节点还有其它哨兵节点发送ping命令做心跳检测，看看是否存在不可达的节点。
主观下线，如果某个哨兵向一个节点发出的心跳检测没有得到响应，那么该哨兵认为该节点已经下线。
客观下线，当哨兵主观下线的节点是主节点时，哨兵会向其他的哨兵询问对主节点的判断，当下线判断超过一定个数时，那么哨兵会认为主节点确实已经下线，那么会对主节点进行客观下线的判定。
故障转移，当Master节点客观下线时，哨兵会从Slave节点中选择一个节点作为Master节点，选择规则是选择与主节点复制相似度最高的节点，选择完成后会将其余的Slave节点指向新的Master节点，并监控原来的Master节点，当它回复后作为新Master节点的Slave存在，并且同步新Master节点的数据。
选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。
当使用sentinel模式时，客户端不用直接连接Redis，而是连接哨兵的ip和port，由哨兵来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，哨兵就会感知并将新的master节点提供给使用者。

注意：在使用sentinel监控主从节点的时候，从节点需要是使用动态方式配置的，如果直接修改配置文件，后期sentinel实现故障转移的时候会出问题。

Cluster模式

哨兵引入了主节点的自动故障转移，但哨兵无法对Slave进行自动故障转移，在读写分离场景下，Slave故障会导致读服务不可用，需要我们对Slave做额外的监控、切换操作。此外，哨兵仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题。

Cluster集群模式工作特点：

多个Redis节点互联，数据共享。
所有的节点都是主从模式，其中Slave不提供服务，只提供备用。
不支持同时处理多个Key，因为需要分发到多个节点上。
支持在线增加、删除节点。
客户端可以连接任何一个Master节点进行读写。

其实是你可以将请求发送到任意一个master上去执行。但是，每个master都会计算这个key对应的CRC16值，然后对16384个hashslot取模，找到key对应的hashslot，找到hashslot对应的master。

主观下线(pfail)：集群中的每个节点都会定期向其他节点发送ping消息，如果在一段时间内一直通信失败，则发送节点方认为接收节点存在故障，把接收节点标为主观下线(pfail)状态。
客观下线(fail)：当某个节点判断另一个节点主观下线后，相应的节点状态就会在集群中进行传播，如果集群中所有节点都将它标为主观下线，那么该节点为客观下线，并通知该节点的Slave进行故障转移操作。
故障转移：在某个节点客观下线后，该节点的从节点开始故障转移流程，首先进行资格检查，每个从节点检查与主节点的断开时间，超过一定时间的取消选举资格，然后同样在所有从节点中寻找复制偏移量最大的节点先开始进行选举，只有持有槽的主节点才有投票权，当从节点收集到过半的票数时，即晋升为Master，随即通知Slave当前Master变为自己。

注意：
1、如果某一个主节点和他所有的从节点都下线，redis集群会停止工作。redis集群不保证数据的强一致性，在特定的情况下，redis集群会丢失已经被执行过的写命令.
2、异步复制（asynchronous replication）是Redis集群可能会丢失写命令的其中一个原因，有时候由于网络原因，如果网络断开时间太长，redis集群就会启用新的主节点，之前发给主节点的数据就会丢失。

参考文献：
https://meta.solr.bj.duokanbox.com/solr/xmdb/gitv_milist/
https://rdc.hundsun.com/portal/article/669.html