主从读写分享

• 进行复制中的主从服务器双方的数据库将保存相同的数据，概念上将这种现象称作“数据库状态一致”
  RDB 全量持久化 AOF append only if 增量持久化
• redis2.8版本之前使用旧版复制功能SYNC
  • SYNC是一个非常耗费资源的操作
    • 主服务器需要执行BGSAVE命令来生成RDB文件，这个生成操作会耗费主服务器大量的的
      CPU、内存和磁盘读写资源
    • 主服务器将RDB文件发送给从服务器，这个发送操作会耗费主从服务器大量的网络带宽和流
      量，并对主服务器响应命令
    • 请求的时间产生影响：接收到RDB文件的从服务器在载入文件的过程是阻塞的，无法处理命令
      请求
• 2.8之后使用PSYNC
  • PSYNC命令具有完整重同步（full resynchronization）和部分重同步（partial resynchronization1）两种模式
    • 部分重同步功能由以下三个部分构成：
      • 主服务的复制偏移量（replication offset）和从服务器的复制偏移量
      • 主服务器的复制积压缓冲区（replication backlog）,默认大小为1M
      • 服务器的运行ID(run ID),用于存储服务器标识，如从服务器断线重新连接，取到主服务器
        的运行ID与重接后的主服务器运行ID进行对比，从而判断是执行部分重同步还是执行完
        整重同步

集群模式

Redis 集群的数据分片

• 概念：Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的
  每个节点负责一部分hash槽,

• 举个例子,比如当前集群有3个节点,那么:

  • 节点 A 约包含 0 到 5500号哈希槽.
  • 节点 B 约包含5501 到 11000 号哈希槽.
  • 节点 C 约包含11001 到 16384号哈希槽.

• 查看集群信息redis-cli -p 7000 cluster nodes | grep master

  • 这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部
    分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从
    集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除
    或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.

• 从Redis宕机讲解分布式锁执行的异常场景流程

• 从Server服务宕机讲解分布式锁执行的异常场景流程

Redis 集群的主从复制模型

• 为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品. 在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.Redis集群做主从备份解决了这个问题

Redis 一致性保证

• 主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。 注意：Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区， 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。

Sentinel

Sentinel三大工作任务

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

Sentinel故障转移原理

• 主观下线：

  • 概念主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断
  • 主管下线特点：
    • 如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送
      PING 命令的 Sentinel 返回一个有效回复（valid reply）， 那么 Sentinel 就会将这个服务器标记
      为主观下线
    • 服务器对 PING 命令的有效回复可以是以下三种回复的其中一种：
      返回 +PONG 。
      返回 -LOADING 错误。
      返回 -MASTERDOWN 错误。

• 客观下线

  • 客观下线概念：

    • 指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL ismaster-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服
      务器已下线。）

  • 客观下线特点：

    • 从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法（strong quorum
      algorithm）， 而是使用了流言协议： 如果 Sentinel 在给定的时间范围内， 从其他 Sentinel 那
      里接收到了足够数量的主服务器下线报告， 那么 Sentinel 就会将主服务器的状态从主观下线改
      变为客观下线。 如果之后其他 Sentinel 不再报告主服务器已下线， 那么客观下线状态就会被移
      除。

  • 客观下线注意点：

    • 客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为
      下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。 只要一
      个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推
      选出， 并对失效的主服务器执行自动故障迁移操作。