Redis主从复制集群+高可用(Sentinel)自动故障迁移

单机、单节点、单实例Redis问题？

• 1.单点故障
• 2.容量有限
• 3.压力

AKF解决问题

AKF会带来新的问题？

• 解决单点问题，带来新的问题，数据一致性。

• 强一致性会造成可用性问题

• 弱一致性，允许丢失部分数据，Redis使用默认的异步复制，其特点是低延迟和高性能，是绝大多数 Redis 用例的自然复制模式。但是，从 Redis 服务器会异步的从主 Redis 服务器周期接收到的数据量。

• 采用可靠中间件，最终一致性

CAP三者不可兼得，在一个分布式系统中，该如何取舍：

(1) CA: 优先保证一致性和可用性，放弃分区容错。 这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。

(2) CP: 优先保证一致性和分区容错性，放弃可用性。在数据一致性要求比较高的场合(zookeeper,Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。

(3) AP: 优先保证可用性和分区容错性，放弃一致性。redis主从复制、Eureka就是这种架构。跟CP一样，放弃一致性不是说一致性就不保证了，而是逐渐的变得一致。

主从复制集群

• 主从复制3台机器6379/6380/6381分别启动

• 从节点启动后，slaveof或者replicaof 127.0.0.1 6379

  主节点信息
  
  从节点信息
  RDB第一次需要Flushing,后面只需要同步增量数据

• 主节点添加信息，从节点可以看到信息，并且从master同步RDB文件

• 宕机一台从节点，主节点添加信息，然后启动从节点，可以看到主节点的所有数据
  开启AOF后每次需要全量同步数据

• 主节点宕机，从节点会连接中断，不能提供写服务

• 手动操作从节点(6380)，replicaof no one，6381 执行 replicaof 127.0.0.1 6380，服务恢复
  6380 server日志

• slave-serve-stale-data yes
  如果为 yes（默认值），则从节点仍能够响应客户端的命令
  如果对数据一致性要求很高，则应设置为 no

• slave-read-only yes
  如果为 yes，代表为只读状态，但并不表示客户端用集群方式以从节点为入口连入集群时，不可以进行 set 操作，且 set 操作的数据不会被放在从节点的槽上，会被放到某主节点的槽上。

• repl-diskless-sync no
  控制主节点是否使用 diskless 复制（无盘复制），默认no：硬盘复制。

• repl-backlog-size 1mb
  复制积压缓冲区队列大小，默认：1 MB

• min-slaves-to-write 3 & min-slaves-max-lag 10
  从节点数量小于 3 个，或所有从节点的延迟值都大于 10s，则主节点拒绝执行写命令,接近强一致性

哨兵(Sentinel)

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

• 监控（Monitoring）：
  Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

• 提醒（Notification）：
  当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

• 自动故障迁移（Automatic failover）：
  当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

• sentinel.conf 配置
  port 26379
  sentinel monitor mymaster 127.0.0.1 6379 2
  

• 启动 Sentinel
  分别启动3个哨兵
  redis-server ./26379.conf --sentinel
  
  

• master服务宕机
  sentinel自动故障迁移
  

  PS: 主从复制集群+高可用(Sentinel)自动故障迁移结束，解决了单点故障和部分压力的问题，但是容量的问题还没有解决，下一篇文章分享Redis Cluster集群！！