https://xie.infoq.cn/article/...
高可用指通过设计缩小零碎不能提供服务的工夫，是分布式架构设计必须要思考的因素。
单点故障:只部署一个节点，机器故障，服务就会进行。
redis 三种高可用模式
主从模式
部署多台机器就要思考多台机器的数据同步问题。redis提供复制性能，一台redis数据库中的数据发生变化会主动同步到其余机器上。
主节点读写、从节点读。
默认配置的机器都是主节点，在redis.conf中配置后能够变成从节点。
# 配置主节点的ip和端口slaveof 192.168.1.10 6379# 从redis2.6开始，从节点默认是只读的slave-read-only yes# 假如主节点有登录明码，是123456masterauth 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协定实现协同，节点太多通信老本高，占用网络资源。
扩缩容只能手动。数据迁徙时会阻塞。