目录
主从同步
哨兵模式
集群服务
随着业务的不断发展，单机 Redis 的性能已经不能满⾜我们的需求了，此时我们需要将单机 Redis 扩展为多机服务，Redis 多机服务主要包含以下 3 个内容：
- Redis 主从同步
- Redis 哨兵模式
- Redis 集群服务（Redis 3.0 新增功能）
主从同步
主从同步 (主从复制) 是 Redis ⾼可⽤服务的基⽯，也是多机运⾏中最基础的⼀个。我们把主要存储数据的节点叫做主节点 (master)，把其他通过复制主节点数据的副本节点叫做从节点 (slave)，如下图所示：
在 Redis 中⼀个主节点可以拥有多个从节点，⼀个从节点也可以是其他服务器的主节点，如下图所示：
主从服务器设置
在 Redis 运⾏过程中，我们可以使⽤ replicaof host port 命令，把⾃⼰设置为⽬标 IP 的从服
务器，执⾏命令如下：
127.0.0.1:6379> replicaof 127.0.0.1 6380
OK
如果主服务设置了密码，需要在从服务器输⼊主服务器的密码，使⽤ config set masterauth 主
服务密码命令的方式，例如：
127.0.0.1:6377> config set masterauth pwd123456
OK
主从同步优、缺点分析
主从同步具有以下 3 个优点：
- 性能方面：有了主从同步之后，可以把查询任务分配给从服务器，⽤主服务器来执⾏写操作，这样极⼤的提⾼了程序运⾏的效率，把所有压⼒分摊到各个服务器了；
- 高可用：当有了主从同步之后，当主服务器节点宕机之后，可以很迅速的把从节点提升为主节点，为 Redis 服务器的宕机恢复节省了宝贵的时间；
- 防⽌数据丢失：当主服务器磁盘坏掉之后，其他从服务器还保留着相关的数据，不⾄于数据全部丢失。
主从同步的缺点：这种模式本身存在⼀个致命的问题，当主节点奔溃之后，需要人工干预才能恢复 Redis 的正常使⽤。
哨兵模式
假如晚上发⽣了主从服务器宕机的情况，尤其是在主从服务器节点⽐较多的情况下，如果需要⼈⼯恢复，那么需要的时间和难度是很⼤的，因此我们需要⼀个⾃动的⼯具——Redis Sentinel (哨兵模式) 来把⼿动的过程变成⾃动的，让 Redis 拥有自动容灾恢复 (failover) 的能⼒。
也就是说：使⽤哨兵模式可以⽤来监控主从同步服务器节点，并在主从服务器出现问题的时候实现⾃动容灾恢复。
哨兵模式如下所示：
PS：Redis Sentinel（哨兵） 的最小分配单位是⼀主⼀从。
哨兵⼯作原理
哨兵的⼯作原理是，⾸先每个 Sentinel 会以每秒钟 1 次的频率，向已知的主服务器、从服务器和以及其它 Sentinel 实例，发送⼀个 PING 命令。
如果最后⼀次有效回复 PING 命令的时间超过 down-after-milliseconds 所配置的值 (默认
30s)，那么这个实例会被 Sentinel 标记为主观下线。
如果⼀个主服务器被标记为主观下线，那么正在监视这个主服务器的所有 Sentinel 节点，要以每秒 1 次的频率确认主服务器的确进⼊了主观下线状态。
如果有⾜够数量 (quorum 配置值) 的 Sentinel 在指定的时间范围内同意这⼀判断，那么这个主服务器被标记为客观下线。此时所有的 Sentinel 会按照规则协商⾃动选出新的主节点。注意：⼀个有效的 PING 回复可以是：+PONG、-LOADING 或者 -MASTERDOWN。如果返回值非以上三种回复，或者在指定时间内没有回复 PING 命令， 那么 Sentinel 认为服务器返回的回复⽆效(non-valid)。
集群服务
Redis 集群（Redis Cluster）是 Redis 多机运⾏最完美的终极⽅案，它是 Redis 3.0 之后推出的服务，它的出现可以让我们完全抛弃主从同步和哨兵模式来实现 Redis 多机运⾏。
Redis Cluster 是⽆代理模式去中心化的运⾏模式，客户端发送的绝⼤数命令会直接交给相关节点执⾏，这样⼤部分情况请求命令⽆需转发，或仅转发⼀次的情况下就能完成请求与响应，所以集群单个节点的性能与单机 Redis 服务器的性能是非常接近的，因此在理论情况下，当⽔平扩展⼀倍的主节点就相当于请求处理的性能也提⾼了⼀倍，所以 Redis Cluster 的性能是非常⾼的。
Redis Cluster 架构图如下所示：
从上图可以看出 Redis 的主从同步只能有⼀个主节点，⽽ Redis Cluster 可以拥有⽆数个主从节点，因此 Redis Cluster 拥有更强⼤的平⾏扩展能⼒，也就是说当 Redis Cluster 拥有两个主从节点时，从理论上来讲 Redis 的性能相⽐于单机服务来说性能提升了 2 倍。
