【Redis7学习日记】——复制、哨兵、集群

一、主从复制

1.1 相关概念

• 设置多个 Redis 数据库，master 以写为主， slave 以读为主

  • 当 master 数据库发生变化时，自动将新数据以异步的方式同步到与它关联的 slave 数据库中

• 功能概述:

  • 实现了读写分离、容灾恢复、数据备份，以及通过水平扩容来支持高并发

• 那我们如何来使用呢？

  • 通过配置 slave 从库来绑定到我们 master 主库上
  • 因为不是谁想连接到我们 master 库就能连上的，所以需要设置密码来验证：
    • master 如果配置了 requirepass 参数，那么就需要通过密码登录客户端
    • 那么，我们 slave 就要通过 masterauth 来设置校验密码，如果校验密码不正确，则 master 会拒绝 slave 的访问请求
  • 接下来就是常用命令的介绍：
    • 通过 info replication 命令可以查看复制结点的主从关系与配置信息
    • 通过 replicaof 主库IP 主库端口 命令可以将我们当前的 slave 库连接到 master 库上 【写到配置文件中的】
    • 通过 slaveof 主库IP 主库端口 命令可以建立从库与主库的临时连接关系
      • 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
      • 在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止和原主数据库的同步关系转而和新的主数据库同步，重新拜码头
    • 通过 slaveof no one 命令可以使当前数据库停止与其他数据库的同步，转成主数据库，自立为王

1.2 案例演示

1️⃣ 架构说明：

• 一个 Master 两个 Slave，都使用 VMware 的 CentOS 系统
  • 都安装 Redis，并拷贝配置文件到各自的 /myredis 目录下，并分别命令为
    • redis6379.conf、redis6380.conf、redis6381.conf
      

2️⃣ 小口诀：

• 要注意三个虚拟机要能互相 Ping 通，并注意防火墙设置
• 三大命令：
  • 主从复制：replicaof 主库IP 主库端口，配从（库）不配主（库）
  • 改换门庭：slaveof 新主库IP 新主库端口
  • 自立为王： slaveof no one

3️⃣ 修改配置文件的步骤： 【以 redis6379.conf 为例】

• 1、开启 daemonize yes 【因为Redis是单线程多进程模式，所以开启守护进程模式】
  

• 2、注释掉 bind 127.0.0.1 【让其他主机也能连接到这个 Redis】
  

• 3、protected-mode no 【关闭禁止公网访问 Redis】
  

• 4、指定端口 port 6369
  

• 5、指定当前工作目录 dir
  

• 6、指定 pid 文件名 pidfile
  

• 7、指定 log 文件名 logfile
  

• 8、指定 requirepass客户端登录密码
  

• 9、指定 dump.rdb 名字
  

• 10、指定 aof 文件名字 appendfilename 【AOF功能开不开都行，可选】
  
  

• 11、指定从机访问主机的密码 masterauth 【从机设置，主机无需设置】
  

4️⃣ 一仆二主：

（1）方案一：采用配置文件固定写死的方式

• 1、在从机配置文件中，通过 replicaof 主机IP 主机端口 来绑定到主机，如果master有密码还需配置 masterauth
  
  

• 2、先开启 master，然后再开启两个 slave
  

• 3、通过日志和命令查看主从关系

  • 主机日志：
    

  • 从机日志：
    

  • 命令： info replication
    

• 4、主从问题演示：

  • 从机可以执行写命令吗？
    

  • 从机切入点问题， slave是从头开始复制还是从切入点开始复制?

    • Y，首次一锅端，后续跟随，master写，slave跟

  • 主机shutdown后，从机会上位吗？
    

  • 主机shutdown后，重启后主从关系还在吗？从机还能否顺利复制？
    

  • .某台从机down后，master继续，从机重启后它能跟上大部队吗？

    • 与第二个问题一致

（2）方案二：命令操作手动指定

• 为了演示效果：从机停机去掉配置文件中的配置项， 3台目前都是主机状态，各不从属
  

• 在预设的从机上通过 slaveof 主机IP 主机端口 来实现绑定
  

• 但是这种方式存在缺点：从机重启后，这种绑定关系就不复存在
  

• 也就是说：通过配置方式确定的主从关系更稳定，通过命令确定的主从关系只是当次生效

5️⃣ 薪火相传：

• 上一个slave可以是下一个slave的master,slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻主master的写压力
• 中途变更转向：会清除之前的数据，重新建立拷贝最新的
• slaveof 新主库IP 新主库端口
• 但是需要知道，尽管我们当前的这个 slave 作为其他 slave 的 master，但是也不能执行写命令

6️⃣ 客反为主：

• 通过SLAVEOF no one命令，使当前数据库停止与其他数据库的同步，转成主数据库

1.3 总结

🌔 1、复制工作原理和工作流程

• slave 启动，工作初请

  • slave 启动成功连接到 master 后会发送一个 sync 命令
  • slave 首次全新连接 master，一次性完全同步（全量复制）将被自动执行，slave 自身原有数据会被 master 数据覆盖清除

• 首次连接，全量复制：

  • master 节点收到 sync 命令后会开始在后台保存快照（即RDB持久化，主从复制时会触发RDB），同时收集所有接收到的用于修改数据集命令缓存起来，master 节点执行RDB持久化完后，master 将 rdb 快照文件和所有缓存的命令发送到所有 slave，以完成一次完全同步
  • 而 slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化

• 心跳持续，保持通信：

  • repl-ping-replica-period 10 【10s发送一个ping包，确认彼此通道是否还存在】
    

• 进入平稳，增量复制：

  • Master 继续将新的所有收集到的修改命令自动依次传给 slave，完成同步

• 从机下线，重连续传：master 会检查 backlog 里面的 offset， master 和 slave 都会保存一个复制的 offset 还有一个 masterId，offset 是保存在 backlog 中的， Master 只会把已经复制的 offset 后的数据复制给 Slave，类似于断点续传

🌔 2、复制的缺点

• 复制延迟，信号衰弱：

  • 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟
  • 当系统很繁忙的时候，延迟问题会更加严重
  • Slave机器数量的增加也会使这个问题更加严重

• master 挂了怎么办？

  • 默认情况下，不会在slave节点中自动重选一个master
  • 那每次都要人工干预，无人值守安装变成刚需

---

二、哨兵

2.1 相关概念

• Redis 哨兵（sentinel）是什么？

  • 吹哨人巡查监控后台 masteri主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务 【无人值守运维】
  • 监控 redis 的运行状态，包括 master 和 slave
  • 当 master down 机，能自动将一个 slave 切换成新的 master

• 哨兵的功能：

  • 主从监控：监控主从 redis 库运行是否正常
  • 消息通知：哨兵可以将故障转移的结果发送给客户端
  • 故障转移：如果 Master 出现异常，则会进行主从切换，将其中一个 Slave 作为新 Master
  • 配置中心：客户端通过连接哨兵来获得当前 Redis 服务的主节点地址

2.2 案例演示

1️⃣ Redis Sentinel 架构

• 使用三个哨兵：自动监控和维护集群，不存放数据，只是吹哨人
• 1主2从：用于数据读取和存放

• /myredis 目录下新建或者拷贝 sentinel.conf 文件
• 查看我们 /opt 目录下默认的 sentinel.conf 文件的内容
  

2️⃣ 重要参数说明：

• bind 服务监听地址，用于客户端连接，默认本机地址

• daemonize 是否以后台daemon方式运行 【守护线程】

• protected-mode 安全保护模式

• port 端口

• logfile 日志文件路径

• pidfile pid文件路径

• dir 工作目录

• sentinel monitor <master-name> <ip> <redis-port> <quorum> 设置要监控的 master 服务器

  • quorum 表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数
  • 至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移 【保证了公平性和高可用】

• sentinel auth-pass <master-name> <password> 当 master 设置了密码，哨兵监控的时候就需要输入我们的 master 的密码

• 其他指令：
  

3️⃣ 本次案例哨兵 sentinel 文件通用配置

• 我们将三个哨兵都同时配置进 192.168.111.169 同一台机器

  • sentinel26379.conf

    bind 0.0.0.0
    daemonize yes
    protected-mode no
    port 26379
    logfile "/myredis/sentinel26379.log"
    pidfile /var/run/redis-sentinel26379.pid
    dir /myredis
    sentinel monitor mymaster 192.168.111.169 6379 2
    sentinel auth-pass mymaster 111111
    

  • sentinel26380.conf

    bind 0.0.0.0
    daemonize yes
    protected-mode no
    port 26380
    logfile "/myredis/sentinel26380.log"
    pidfile /var/run/redis-sentinel26380.pid
    dir "/myredis"
    sentinel monitor mymaster 192.168.111.169 6379 2
    sentinel auth-pass mymaster 111111
    

  • sentinel26381.conf

    bind 0.0.0.0
    daemonize yes
    protected-mode no
    port 26381
    logfile "/myredis/sentinel26381.log"
    pidfile /var/run/redis-sentinel26381.pid
    dir "/myredis"
    sentinel monitor mymaster 192.168.111.169 6379 2
    sentinel auth-pass mymaster 111111
    

• master 主机配置文件说明
  

4️⃣ 整体测试：

• 1、先启动一主二从3个Redis实例，测试正常的主从复制

  • 169机器上新建redis6379.conf配置文件，由于要配合本次案例，请设置masterauth项访问密码为111111，不然后续可能报错master_link_status:down
    

  • 172机器上新建redis6380.conf配置文件，设置好replicaof
    

  • 173机器上新建redis6381.conf配置文件，设置好replicaof
    

• 注意：6379后续可能会变成从机，需要设置访问新主机的密码， 请设置masterauth项访问密码为111111，不然后续可能报错 master_link_status:down
  

• 2、分别启动三台Redis客户端：

  • redis-cli -a 111111 -p 6379
  • redis-cli -a 111111 -p 6380
  • redis-cli -a 111111 -p 6381

• 3、再启动三个哨兵完成监控：

  • redis-sentinel sentinel26379.conf --sentinel
  • redis-sentinel sentinel26380.conf --sentinel
  • redis-sentinel sentinel26381.conf --sentinel

• 启动三个哨兵监控后再测试一次主从复制
  

• 4、我们通过shutdown关闭 6379 服务器，模拟 master 挂了
  

• 5、问题思考：

（1）当我们master宕机后，两台从机数据还可以正常使用吗？

• 刚开始会显示连接失败的问题，因为内部正在进行激烈的竞争，过了一会儿就可以正常获取到我们的数据了
• 我们来了解一下 broken pipe：

	介绍
认识broken pipe	pipe是管道的意思，管道里面是数据流，通常是从文件或网络套接字读取的数据。当该管道从另一端突然关闭时，会发生数据突然中断，即是broken，对于socket来说，可能是网络被拔出或另一端的进程崩溃
解决问题	其实当该异常产生的时候，对于服务端来说，并没有多少影响。因为可能是某个客户端突然中止了进程导致了该错误
总结 Broken Pipe	这个异常是客户端读取超时关闭了连接,这时候服务器端再向客户端已经断开的连接写数据时就发生了broken pipe异常！

（2）是否会从剩下的 2 台机器上选出 master 呢？【我们查看一下哨兵的日志文件】

• sentinel26379.log
  

• sentinel26380.log
  

• sentinel26381.log
  

（3）谁会是新的 master，当原来的master恢复后，会不会出现双 master 的现象？

• 6381 成为新 master，上位成功
  

• 之前的 6379（master）恢复后，降级为 slave
  

• 6380还是slave,只不过换了个新老大6381(6379变6381)，6380还是slave

• 6、对比配置文件我们可以发现：

  • 文件的内容在运行期间会被 sentinel 动态进行更改
  • Master–Slavet切换后，master_.redis…conf、slave_redis…conf和sentinel…conf的内容都会发生改变，即master redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

• 备注：

  • 生产都是不同机房不同服务器，很少出现3个哨兵全挂掉的情况
  • 可以同时监控多个master,一行一个

2.3 运行流程与原理

• 当一个主从配置中的master失效之后，sentinel可以选举出一个新的master用于自动接替原masterl的工作，主从配置中的其他redis服务器自动指向新的master同步数据。般建议sentinel采取奇数台，防l止某一台sentinel无法连接到master导致误切换

运行流程、故障切换

1️⃣ 当前为三个哨兵监控一主二从，正常运行中…

2️⃣ SDown主观下线（Subjectively Down）

• SDOWN(主观不可用)是单个sentinel自己主观上检测到的关于master的状态
• 从sentinel的角度来看如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件
• sentinel 配置文件中的 down-after-milliseconds 设置了判断主观下线的时间长度
  

3️⃣ ODown客观下线（Objectively Down）

• ODOWN需要一定数量的sentinel,多个哨兵达成一致意见才能认为一个master客观上已经宕掉

4️⃣ 选取出领导者哨兵（兵王）

• 当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）并由该领导者节点也即被选举出的兵王进行failover(故障迁移）

• 那么这个兵王是如何选出来的呢？

  • 采用的事 raft 算法，先到先得投票
    
  • 监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：
  • 即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者

5️⃣ 兵王推动故障切换流程并选出一个新的 master

（1）新主登基：某个 slave 被选中成为新 master

• 选出新 master 的规则，剩余 slave 节点健康前提下
  • redis.conf 文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先级越高）
  • 复制便宜位置 offset 最大的从节点 【可以理解为数据量大的】
  • 最小 Run ID 的从节点 【ASCII码字典排序】

（2）群臣俯首：所有 slave 认定新的 master

• 执行 slaveof no one 命令让选出来的从节点成为新的主节点，并通过 slaveof 命令让其他节点成为其从节点
• Sentinel leader 会对选举出的新 master 执行slaveof no one 操作，将其提升为master节点
• Sentinel leader 会对其它slave发送命令，让剩余的slave成为新的master节点的slave

（3）旧主拜服：回来的老 master 会变成 slave

• 将之前已下线的老master设置为新洗出的新master的从节点，当老master重新上线后，它会成为新master的从节点
• Sentinel leader会让原来的master降级为slave并恢复正常工作

• 上述的failoveri操作均由sentinel自己独自完成，完全无需人工干预

2.4 哨兵使用建议

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
• 哨兵节点的数量应该是奇数
• 各个哨兵节点的配置应一致
• 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
• 哨兵集群+主从复制，并不能保证数据零丢失承上启下引出集群

---

三、集群

3.1 相关概念

• 由于数据量过大，单个Master复制集难以承担，因此需要对多个复制集进行集群，形成水平扩展每个复制集只负责存储整个数据集的一部分，这就是Redis的集群，其作用是提供在多个Redis节点间共享数据的程序集

• Redis 集群是一个提供多个 Redis 节点间共享数据的程序集
• Redis 集群可以支持多个 Master

Redis 都有哪些功能

• Redis 集群支持多个 Master，每个 Master 又可以挂载多个 Slave

  • 支持读写分离
  • 支持数据的高可用 【指通过设计减少系统的不可用时间】
  • 支持海量数据的读写存储操作

• 由于 Cluster 自带的 sentinel（哨兵）的故障转移机制，内置了高可用的支持，无需再去使用哨兵功能

• 客户端与 Redis 的节点连接，不需要连接集群的所有节点，只需要连接集群中任意一个可用节点即可

• 槽位 slot 负责分配到各个物理节点，由对应集群负责维护节点、插槽和数据之间的关系

3.2 集群算法-分片-槽位slot

1️⃣ Redis 集群的槽位 slot：

2️⃣ Redis 集群的分片

• 分片是什么？

  • 使用Redis集群时我们会将存储的数据分散到多台Redis机器上 【这就是分片】
  • 简言之，集群中的每个Redis实例都被认为是整个数据的一个分片

• 如何找到给定 key 的分片？

  • 我们对key进行CRC16(key)算法处理并通过对总分片数量取模，然后，使用确定性哈希函数
  • 意味着给定的key将多次始终映射到同一个分片，我们可以推断将来读取特定key的位置

3️⃣ 优势：

• 最大的优势就是方便数据扩缩容和分派查找
  

4️⃣ 如何实现 slot 的槽位映射？

方案一：哈希取余分区

• 2亿条记录就是2亿个k,v，我们单机不行必须要分布式多机，假设有3台机器构成一个集群，用户每次读写操作都是根据公式：hash(key) % N个机器台数，计算出哈希值，用来决定数据映射到哪一个节点上

• 优点：

  • 简单粗暴，直接有效，只需要预估好数据规划好节点
  • 例如3台、8台、10台，就能保证一段时间的数据支撑
  • 使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡+分而治之的作用

• 缺点：

  • 原来规划好的节点，进行扩容或者缩容就比较麻烦了，不管扩缩，每次数据变动导致节点有变动，映射关系需要重新进行计算，在服务器个数固定不变时没有问题

  • 如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化：Hash(key)/3会变成Hash(key) /?。此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控

  • 某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌

方案二：一致性算法分区

• 在1997年由麻省理工学院中提出的，设计目标是为了解决分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数不OK了
• 提出一致性Hash解决方案，目的是当服务器个数发生变动时尽量减少影响客户端到服务器的映射关系
• 分为三大步骤：

（1）算法构造一致性哈希环

• 一致性哈希算法必然有个hash函数并按照算法产生hash值，这个算法的所有可能哈希值会构成一个全量集，这个集合可以成为一个hash空间[0,2^32-1]，这个是一个线性空间，但是在算法中，我们通过适当的逻辑控制将它首尾相连(0 = 2^32),这样让它逻辑上形成了一个环形空间
• 它也是按照使用取模的方法，前面笔记介绍的节点取模法是对节点（服务器）的数量进行取模。而一致性Hash算法是对2^32 取模，简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0-2^32-1 （即哈希值是一个32位无符号整形），整个哈希环如下图：整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、……直到2^ 32-1，也就是说0点左侧的第一个点代表2^32-1 ， 0 和 2^ 32-1在零点中方向重合，我们把这个由2^32个点组成的圆环称为Hash环

（2）Redis 服务器IP节点映射

• 将集群中各个节点映射到环上的某一位置

• 将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置

• 假如4个节点NodeA、B、C、D，经过IP地址的哈希函数计算(hash(ip))，使用IP地址哈希后在环空间的位置如下：
  
  （3）key 落到服务器的落键规则

• 当我们需要存储一个kv键值对时，首先计算key的hash值，hash(key)，将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上

• 如我们有Object A、Object B、Object C、Object D四个数据对象，经过哈希计算后，在环空间上的位置如下：根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上
  

• 一致性哈希算法的优点：

  • 较高的容错性：

    • 假设Node C宕机，可以看到此时对象A、B、D不会受到影响
    • 一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响
    • 简单说，就是C挂了，受到影响的只是B、C之间的数据且这些数据会转移到D进行存储
      

  • 扩展性:

    • 数据量增加了，需要增加一台节点NodeX，X的位置在A和B之间，那收到影响的也就是A到X之间的数据，重新把A到X的数据录入到X上即可，不会导致hash取余全部数据重新洗牌
      

• 一致性哈希算法存在的数据倾斜问题：

  • 一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题，例如系统中只有两台服务器：
    

• 对于一致性哈希算法的总结：

  • 为了在节点数目发生改变时迁移尽可能少的数据
  • 将所有的存储节点排列在收尾相接的Hash环上，每个key在计算Hash后会顺时针找到临近的存储节点存放
  • 优点：加入和删除节点只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响
  • 缺点：数据的分布和节点的位置有关，因为这些节点不是均匀的分布在哈希环上的，所以数据在进行存储时达不到均匀分布的效果

方案三：哈希槽分区

• 为了解决一致性哈希算法的数据倾斜问题，引出了我们的哈希槽，哈希槽实质就是一个数组，数组[0,2^14 -1]形成hash slot空间

• 哈希槽具体有什么作用呢？

  • 解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据
    

  • 槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配

• 那么有多少个哈希槽呢？

  • 一个集群只能有16384个槽，编号0-16383（0-2^14-1），这些槽会分配给集群中的所有主节点，分配策略没有要求
  • 集群会记录节点和槽的对应关系，解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取模，余数是几key就落入对应的槽里
  • HASH_SLOT = CRC16(key) mod 16384,以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了

• 那么哈希槽是如何计算的呢？

  • Redis 集群中内置了 16384 个哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点
  • Redis 集群中放置一个 key-value 时，redis先对key使用crc16算法算出一个结果然后用结果对16384求余数[ CRC16(key) % 16384]，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，也就是映射到某个节点上
  • 如下代码，key之A 、B在Node2， key之C落在Node3上
    
    

5️⃣ 经典面试题：

• 为什么说 Redis 集群的最大槽数为 16384 个呢？
  

  • 解释1：
    正常的心跳数据包带有节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置。
    这意味着它们包含原始节点的插槽配置，该节点使用2k的空间和16k的插槽，但是会使用8k的空间（使用65k的插槽）。
    同时，由于其他设计折衷，Redis集群不太可能扩展到1000个以上的主节点。
    因此16k处于正确的范围内，以确保每个主机具有足够的插槽，最多可容纳1000个矩阵，但数量足够少，可以轻松地将插槽配置作为原始位图传播。请注意，在小型群集中，位图将难以压缩，因为当N较小时，位图将设置的slot / N位占设置位的很大百分比
    

  • 解释2：
    (1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
    在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为65536时，这块的大小是: 65536÷8÷1024=8kb
    在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为16384时，这块的大小是: 16384÷8÷1024=2kb
    因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。
    (2)redis的集群主节点数量基本不可能超过1000个。
    集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者不建议redis cluster节点数量超过1000个。 那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。
    (3)槽位越小，节点少的情况下，压缩比高，容易传输
    Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。 如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

• 结论：
  

• Redis:集群不保证强一致性，这意味着在特定的条件下，Rediss集群可能会丢掉一些被系统收到的写入请求命令
  

3.3 案例演示

1️⃣ 三主三从Redis集群配置

• 找三台真实的虚拟机，各自创建mkdir -p /myredis/cluster

• 创建六个独立的Redis服务实例：

  • 本次案例设计说明（IP会有变换）：点击跳转
  • IP:192.168.111.175+端☐6381/端☐6382

    • vim /myredis/cluster/redisCluster6381.conf

      bind 0.0.0.0
      daemonize yes
      protected-mode no
      port 6381
      logfile "/myredis/cluster/cluster6381.log"
      pidfile /myredis/cluster6381.pid
      dir /myredis/cluster
      dbfilename dump6381.rdb
      appendonly yes
      appendfilename "appendonly6381.aof"
      requirepass 111111
      masterauth 111111
       
      cluster-enabled yes
      cluster-config-file nodes-6381.conf
      cluster-node-timeout 5000
      

    • vim /myredis/cluster/redisCluster6382.conf

      bind 0.0.0.0
      daemonize yes
      protected-mode no
      port 6382
      logfile "/myredis/cluster/cluster6382.log"
      pidfile /myredis/cluster6382.pid
      dir /myredis/cluster
      dbfilename dump6382.rdb
      appendonly yes
      appendfilename "appendonly6382.aof"
      requirepass 111111
      masterauth 111111
       
      cluster-enabled yes
      cluster-config-file nodes-6382.conf
      cluster-node-timeout 5000
      

  • IP:192.168.111.172+瑞☐6383/端☐6384

    • vim /myredis/cluster/redisCluster6383.conf

      bind 0.0.0.0
      daemonize yes
      protected-mode no
      port 6383
      logfile "/myredis/cluster/cluster6383.log"
      pidfile /myredis/cluster6383.pid
      dir /myredis/cluster
      dbfilename dump6383.rdb
      appendonly yes
      appendfilename "appendonly6383.aof"
      requirepass 111111
      masterauth 111111
      
      cluster-enabled yes
      cluster-config-file nodes-6383.conf
      cluster-node-timeout 5000
      

    • vim /myredis/cluster/redisCluster6384.conf

      bind 0.0.0.0
      daemonize yes
      protected-mode no
      port 6384
      logfile "/myredis/cluster/cluster6384.log"
      pidfile /myredis/cluster6384.pid
      dir /myredis/cluster
      dbfilename dump6384.rdb
      appendonly yes
      appendfilename "appendonly6384.aof"
      requirepass 111111
      masterauth 111111
       
      cluster-enabled yes
      cluster-config-file nodes-6384.conf
      cluster-node-timeout 5000
      

  • IP:192.168.111.174+瑞☐6385/端☐6386
    • vim /myredis/cluster/redisCluster6385.conf

      bind 0.0.0.0
      daemonize yes
      protected-mode no
      port 6385
      logfile "/myredis/cluster/cluster6385.log"
      pidfile /myredis/cluster6385.pid
      dir /myredis/cluster
      dbfilename dump6385.rdb
      appendonly yes
      appendfilename "appendonly6385.aof"
      requirepass 111111
      masterauth 111111
       
      cluster-enabled yes
      cluster-config-file nodes-6385.conf
      cluster-node-timeout 5000
      

    • vim /myredis/cluster/redisCluster6386.conf

    bind 0.0.0.0
    daemonize yes
    protected-mode no
    port 6386
    logfile "/myredis/cluster/cluster6386.log"
    pidfile /myredis/cluster6386.pid
    dir /myredis/cluster
    dbfilename dump6386.rdb
    appendonly yes
    appendfilename "appendonly6386.aof"
    requirepass 111111
    masterauth 111111
     
    cluster-enabled yes
    cluster-config-file nodes-6386.conf
    cluster-node-timeout 5000
    

• 通过 redis-cli 命令为6台机器构建集群关系

  • 构建主从关系：【自己练习的时候需要使用真实的地址】

  redis-cli -a 111111 --cluster create --cluster-replicas 1 192.168.111.175:6381 192.168.111.175:6382 192.168.111.172:6383 192.168.111.172:6384 192.168.111.174:6385 192.168.111.174:6386

  • --cluster-replicas 1 表示为每个master创建一个slave节点
    
    
  • 结果如下，代表三主三从构建成功
    

• 链接进入6381作为切入点，查看并检验集群状态

  • 查看节点状态：
    

  • info replication
    

  • cluster info
    

  • cluster nodes
    

2️⃣ 三主三从Redis集群读写

• 对 6381 新增两个 key 查看效果
  
• 为什么会报错呢？
  • 一定注意槽位的范围区间，需要路由到位，路由到位，路由到位，路由到位
    
• 那么我们该如何解决这种问题呢？
  • 防止路由失效加参数 -c，并新增两个 key 【优化路由】
    
• 查看集群信息：
  
• 查看某个key该属于对应的槽位值 CLUSTER KEYSLOT键名称
  

3️⃣ 主从容错切换迁移案例

• 容错切换迁移：
  • 主6381和从机切换，先停止主机6381
    • 6381主机停了，对应的真实从机上位
    • 6381作为1号主机分配的从机以实际情况为准，具体是几号机器就是几号
  • 再次查看集群信息，本次6381主6384从
    
  • 停止主机6381，再次查看集群信息 【6384成功上位并正常使用】
    
    
  • 随后，6381原来的主机回来了，是否会上位？

    • 结果：6381不会上位并以从节点形式回归

    • 恢复前：
      

    • 恢复后：
      
      

• 集群不保证数据一致性100%0K,一定会有数据丢失情况
  • Redis 集群不保证强一致性，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入请求命令
    
• 手动故障转移o节点从属调整该如何处理
  • 上面一换后6381、6384主从对调了，和原始设计图不一样了，该如何
  • 重新登陆6381机器
  • 常用命令 CLUSTER FAILOVER
    

4️⃣ 主从扩容案例：

• 新建6387、6388两个服务实例配置文件+新建后启动

  • IP:192.168.111.174+端☐6387/端☐6388

    • vim /myredis/cluster/redisCluster6387.conf

    bind 0.0.0.0
    daemonize yes
    protected-mode no
    port 6387
    logfile "/myredis/cluster/cluster6387.log"
    pidfile /myredis/cluster6387.pid
    dir /myredis/cluster
    dbfilename dump6387.rdb
    appendonly yes
    appendfilename "appendonly6387.aof"
    requirepass 111111
    masterauth 111111
    
    cluster-enabled yes
    cluster-config-file nodes-6387.conf
    cluster-node-timeout 5000
    

    • vim /myredis/cluster/redisCluster6388.conf

    bind 0.0.0.0
    daemonize yes
    protected-mode no
    port 6388
    logfile "/myredis/cluster/cluster6388.log"
    pidfile /myredis/cluster6388.pid
    dir /myredis/cluster
    dbfilename dump6388.rdb
    appendonly yes
    appendfilename "appendonly6388.aof"
    requirepass 111111
    masterauth 111111
     
    cluster-enabled yes
    cluster-config-file nodes-6388.conf
    cluster-node-timeout 5000
    

  • 启动87/88两个新的节点实例，此时他们自己都是master

    • redis-server /myredis/cluster/redisCluster6387.conf
    • redis-server /myredis/cluster/redisCluster6388.conf
      

  • 将新增的6387节点（空槽号）作为master节点加入原集群
    

  • 检查集群情况第1次
    

  • 重新分派槽号(reshard)

    • 命令:redis-cli -a 密码 --cluster reshard IP地址:端口号 redis-cli -a 密码 --cluster reshard 192.168.111.175:6381
      
      

  • 检查集群情况第2次
    

    • 槽号分派说明
      

  • 为主节点6387分配从节点6388
    

  • 检查集群情况第3次
    

5️⃣ 主从容缩案例：

• 目的：6387和6388下线
  

• 检查集群情况第一次，先获得从节点6388的节点ID
  

• 从集群中将4号从节点6388删除
  

• 将6387的槽号清空，重新分配，本例将清出来的槽号都给6381

  • redis-cli -a 111111 --cluster reshard 192.168.111.175:6381
    
    

• 检查集群情况第二次
  

• 将6387删除
  

• 检查集群情况第三次,6387/6388被彻底祛除B

  • redis-cli -a 111111 --cluster check 192.168.111.175:6381

3.4 集群常用操作命令和CRC16算法分析

• 不在同一个sot槽位下的多键操作支持不好，通识占位符登场
  

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

  • CRC16源码浅谈
    

• 常用命令

  • 集群是否完整才能对外提供服务 cluster-require-full-coverage
    

  • CLUSTER COUNTKEYSINSLOT槽位数字编号

    • 1 该槽位被占用
    • 0 该槽位没占用

  • CLUSTER KEYSLOT键名称, 该键应该存在哪个槽位上