redis高可用（主从、哨兵、集群） 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再移除节点。
优点可扩展，高可用。
缺点 【redis高可用（主从、哨兵、集群）】节点依靠goss协议实现协同，节点太多通信成本高，占用网络资源。
扩缩容只能手动。数据迁移时会阻塞。