redis高可用：主从、哨兵、集群

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协议实现协同，节点太多通信成本高，占用网络资源。
扩缩容只能手动。数据迁移时会阻塞。