https://xie.infoq.cn/article/…
高可用指通过设计缩小零碎不能提供服务的工夫，是分布式架构设计必须要思考的因素。
单点故障: 只部署一个节点，机器故障，服务就会进行。
redis 三种高可用模式

主从模式

部署多台机器就要思考多台机器的数据同步问题。redis 提供复制性能，一台 redis 数据库中的数据发生变化会主动同步到其余机器上。
主节点读写、从节点读。
默认配置的机器都是主节点，在 redis.conf 中配置后能够变成从节点。

# 配置主节点的 ip 和端口
slaveof 192.168.1.10 6379

# 从 redis2.6 开始，从节点默认是只读的
slave-read-only yes

# 假如主节点有登录明码，是 123456
masterauth 123456

#在启动从节点时，指定主节点
./redis-server --slaveof 192.168.1.10 6379

主节点挂了，在从节点 1 上执行 slaveof no one，将从节点变成主节点。在其余从节点上执行 slaveof 从节点 1。

主从复制的机制

• 从库连贯主库，发送 sync
• 主库收到 sync，执行 bgsava 生成 rdb 文件，应用缓冲区记录增量写
• 主库 bgsave 实现，向从库发送快照，持续记录增量写
• 从库收到快照，从库载入快照。
• 主库发送快照实现，开始发送缓冲区里的增量写
• 从库载入快照实现，开始执行缓冲区的增量写。（从库初始化实现）
• 主库每次执行写都向从库发送，从库会执行。
• 呈现断开重连后，2.8 后的版本会把断线期间的命令传给从库，增量复制。

• 主从刚刚连贯时全量同步，全量完结后增量同步。如有须要随时能够发动全量同步。

  长处

• 反对主从复制，能够读写拆散
• slave 能够承受 slave 的连贯和同步申请，分担 master 的同步压力。
• master 以非阻塞的形式为 slave 提供服务，同步期间不影响读写。

• slave 以阻塞的形式为 slave 提供服务，同步期间读会返回历史版本。？

  毛病

• 不能主动容错和复原，宕机会导致读写失败，须要手动切换 ip
• 主机宕机，没来得及同步到从机的数据会有不统一问题
• slave 重启时会和主机同步，多个 slave 同时重启会导致 masterIO 剧增宕机
• 集群容量达到下限时没法在线扩容?
• 数据冗余，耗费内存。

哨兵模式

哨兵是个独立过程，非数据节点，能够和 redis 机器部署在一起或离开。
哨兵向所有节点发送命令，期待响应，从而监控，像 zookeeper 的性能。
为了便于选举应用奇数个哨兵，哨兵间也会互相通信。
哨兵检测到 master 宕机，会主动把 slave 切换到 master 并通过公布订阅模式告诉其余从服务器换 master。

工作形式

• 每个哨兵每秒一次向所有节点发送 ping 命令（蕴含其余哨兵）
• 如果一个实例响应工夫超过 down-after-milliseconds, 则被标记为主观下线。
• 其余哨兵每秒一次确认此 master 确实进入主观下线。（sdown）
• 足够数量哨兵认定主观下线后，哨兵会进行投票，执行 failover，公布订阅告诉其余节点，此 master 被标记为主观下线。（odown）
• 失常状况下哨兵每 10s 向所有主从服务器发送 info 命令。
• master 主观下线时改成 1s 一次 info。

集群模式

没有应用一致性 hash 算法而是应用 slots 插槽。对数据进行分片，每个节点上贮存不同内容。节点间通过集群总线通信。
客户端能够连贯任何一个 node 操作，当 key 不在该 node 上时会指向正确的 node。去中心化。
集群部署须要至多 3 个 master，最好 3 主 3 从。
每个 key 处在哪个节点上是依据 key 的 hash 对 16383 取余调配的。
半数以上主节点与 master1 失去通信，认定 master1 宕机，启用 slave。slave 也宕机，集群 fail，因为失落了一部分数据。
如果半数以上 master 宕机，不论是否有 slave，集群都 fail。
扩容：先加节点再重调配插槽、数据迁徙。
缩容：先重调配 slot 再移除节点。

长处

可扩大，高可用。

毛病

节点依附 goss 协定实现协同，节点太多通信老本高，占用网络资源。
扩缩容只能手动。数据迁徙时会阻塞。