集群伸缩
一、伸缩原理
集群伸缩 = 槽和数据在节点之间的移动
二、扩容集群
1.准备新节点（例如，加入6385,6386）
- 需要是集群模式 cluster_enabled = yes
- 配置和其他集群节点保持一致
- 启动后是一个孤儿节点
redis-server conf/redis-6385.conf
redis-server conf/redis-6386.conf
2.加入集群
- 方式一：通过meet操作将两个新节点加入到集群中
redis-cli -p 6379 cluster meet 127.0.0.1 6385
redis-cli -p 6379 cluster meet 127.0.0.1 6386
6385成为master的从属节点
redis-cli -p 6385 cluster replicate node-id
6386端口作为主节点，加入集群。
- 方式二：通过redis-trib.rb工具，将节点加入到集群
redis-trib.rb add-node newHost:newPort existsHost:existPort --slave --master-id
#
redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379
reids-trib.rb add-node 127.0.0.1:6386 127.0.0.1:6379
- 在没有图形化界面时，建议使用redis-trib.rb能够避免新节点已加入其它集群，造成故障
- 新节点加入到集群中，有两类作用
- 为它迁移槽和数据实现扩容
- 作为从节点负责参与故障转移
3.迁移槽和数据
基于原生命令
- 对目标节点发送：***cluster setslot ${slot} importing ${sourceNodeId}***，让目标节点准备导入槽的数据。
- 对源节点发送：***cluster set ${slot} migrating ${targetNodeId}***，让源节点准备迁出槽的数据
- 源节点循环执行：***cluster getkeysinslot ${slot} ${count}***，每次获取count个属于槽的键
- 在源节点上执行：***migrate ${targetIp} ${targetPort} key 0 ${timeout}***，将指定的key迁移
- 重复执行步骤③~步骤④直到槽下所有的数据迁移至目标节点
- 向集群内所有主节点发送***cluster setslot ${slot} node ${targetNodeId}***，通知槽分配给目标节点
![在这里插入图片描述]()
基于redis-trib.rb
#指定任意一个集群中的节点即可
redis-trib.rb reshard ${everyHost}:${everyPort}
#首先通过提示输入需要迁移多少个slot
#然后提示输入接收这些槽的nodeId
#接着提示输入源节点的节点ID集合，输入all则表示所有待迁移节点平均
redis-trib.rb reshard host:port --from ${fromNodeId} --to ${toNodeId}
--slots ${slotCount} --yes --timeout --pipeline ${batchSize}
#host:port 必传参数，集群内任意节点地址，用来获取整个集群信息
#--from 源节点ID，当有多个源节点用逗号分隔，如果是all，则源节点为集合内除目标节点外的所有主节点
#--to 目标节点ID，只能填写一个
#--slots 需要迁移槽的总数量
#--yes 迁移无需用户手动确认
#--timeout 每次migrate操作的超时时间，默认为60000毫秒=60秒
#--pipeline 控制每次批量迁移键的数量，默认是10
三、缩容集群
1.迁移槽到其他节点
#将槽从当前节点迁出可以使用上文中的reshard进行完成
redis-trib.rb reshard ${everyHost}:${everyPort}
redis-trib.rb reshard host:port --from ${fromNodeId} --to ${toNodeId}
--slots ${slotCount}
2.直接下线节点
redis-trib.rb del-node 127.0.0.1:7000 要下线的node-id
帮我们完成了forget命令和shutdown命令
或者通过以下方式
2.通知其他节点忘记下线节点
** #在‘其他节点’上依次执行如下命令，需要在60秒内执行
cluster forget ${downNodeId}
3.关闭节点
客户端路由
#计算指定key的对应的槽位
cluster keyslot ${key}
一、moved重定向
- 客户端给任一节点发送请求
- 节点计算该请求的槽位以及对应的节点
- 如果对应的节点是自身，则将执行命令并返回执行结果
- 如果对应的节点不是当前节点自身，将会返回一个moved异常：MOVED ${slot} ${targetHost} ${targetPort}
- 然后客户端再重新按照targetHost:targetPort连接另一redis节点，发送请求，跳转至第②步。
二、ask重定向
- ask请求发生在slot迁移的过程中
- 客户端向source发送命令（不存在moved重定向的情况）
- source节点回复客户端一个ASK重定向：ASK ${slot} ${targetHost} ${targetPort}
- 客户端给target节点发送一个Asking请求
- 然后紧接着客户端发送命令给target节点
- target节点执行请求并响应结果
三、MOVED VS ASK
- 两者都是客户端的重定向
- MOVED的场景下，可以确定槽不在当前节点
- ASK的场景下，槽还在迁移过程中
三、smart客户端（JedisCluster）
1.smart客户端原理：追求性能
- 从集群中选一个可运行节点，使用clutser slots初始化槽和节点映射
- 将cluster slots结果映射到本地，为每个节点创建JedisPool
- 准备执行命令
[外链图片转存失败(img-wqXdDQQt-1563007938392)(F:\workspace\imooc_workspace\carlosfu_workspace\one_redis_workspace\1546503077784.png)]
2.JedisCluster使用方法
Set<HostAndPort> nodeList = new HashSet<>();
nodeList.add(new HostAndPort("127.0.0.1" , 7000) );
nodeList.add(new HostAndPort("127.0.0.1" , 7001) );
nodeList.add(new HostAndPort("127.0.0.1" , 7002) );
nodeList.add(new HostAndPort("127.0.0.1" , 7003) );
nodeList.add(new HostAndPort("127.0.0.1" , 7004) );
nodeList.add(new HostAndPort("127.0.0.1" , 7005) );
JedisPoolConfig poolConfig = new JedisPoolConfig();
int timeout = 30_000;
JedisCluster jedisCluster = new JedisCluster(nodeList , timeout , poolConfig);
jedisCluster.set("hello" , "world");
System.out.println(jedisCluster.get("hello"));
//获取所有节点的JedisPool
Map<String,JedisPool> jedisPoolMap = jedisCluster.getClusterNodes();
3.使用技巧
- 单例：内置了所有节点的连接池
- 无需手动借还连接池
集群模式下批量操作的实现
mget、mset需要一组key必须在同一个槽下
1.串行GET/SET
- 含义：对每一个key在for循环中依次执行GET/SET
- 优点：执行简单
- 缺点：n个key就需要n次网络时间，效率低下
2.根据CRC16&16383的结果做内聚后串行IO
- 含义：在本地通过CRC16&16383计算出各个key的槽，然后以各个槽做内聚，然后串行依次访问各个node
3.根据CRC16&16383的结果做内聚后并行IO
- 含义：在本地通过CRC16&16383计算出各个key的槽，然后以各个槽做内聚，然后并行访问各个node
4.使用hash_tag的方式
- 当一个key包含 {} 的时候，就不对整个key做hash，而仅对 {} 包括的字符串做hash。
- 此时对每个key拼接一个字符串{tag}，就可以访问一个节点，完成O(1)的请求
5.四种方式的比较
| 方案 | 优点 | 缺点 | 网络IO |
|---|---|---|---|
| 串行mget | 编程简单 少量keys满足需求 |
大量keys请求延迟严重 | O(keys) |
| 串行IO | 编程较简单 少量节点满足需求 |
大量node延迟严重 | O(nodes) |
| 并行IO | 利用并行特性 延迟取决于最慢的节点 |
编程复杂 超时定位问题难 |
O(max_slow(node)) |
| hash_tag | 性能最高 | 读写增加tag维护成本 tag分布易出现数据倾斜 |
O(1) |
故障转移
一、故障发现
- 通过ping、pong消息实现故障发现：不需要sentinel
1.主观下线（pfail消息）
- 定义：某个节点认为另一个节点不可用，“偏见”
- 主观下线流程
- 节点1每秒定时给节点2发送PING消息
- 当节点2收到PING消息后返回的PONG消息被节点1收到时，节点1会更新与节点2的最后更新时间
- 否则如果PING/PONG失败，会触发通信异常断开连接
- 当与节点2最后的通信时间达到或大于***cluster-node-timeout***，则节点1主观认为节点2下线。
2.客观下线（fail消息）
- 定义：当半数以上持有槽的主节点都标记某节点主观下线
- 流程
- 当每个节点收到其他节点发来的PING消息时，会解析其中是否包含其他节点的主观下线消息
- 收到PING的结果会把收到的主观下线消息存入故障链表中
- 在故障链表中，节点可以知道有多少主节点主观下线
- 故障链表存在有效期，有效期为***cluster-node-timeout X 2***，防止很久之前的主观下线消息长久存在于故障链表中。
- 计算有效的下线报告数量，当达到半数以上时，就将节点更新为客观下线
- 并向集群广播下线节点的fail消息
3.客观下线的作用
- 通知集群内所有节点标记故障节点为客观下线
- 通知故障节点的从节点触发故障转移流程
二、故障恢复
1.资格检查（对从节点进行资格检查）
- 每个从节点检查与故障主节点的断线时间
- 超过cluster-node-timeout * cluster-slave-validity-factor取消资格
- cluster-slave-validity-factor：默认是10
###2.准备选举时间
-
对各个符合资格的从节点按照偏移量进行排序
-
偏移量越大（与主节点数据越接近）的节点准备选举时间越小（越早被选举，后续投票阶段可获得更多票数）
3.选举投票
- 由可用的master节点给各个符合资格的slave节点投票
- 准备选举时间越小的节点，越早被master节点投票，就更可能得到更多的票数
- 当投票数达到 （可用master节点数）/2 + 1，可以晋升成为master节点
4.替换主节点
- 当前从节点取消复制变成主节点（slaveof no one)
- 执行cluster del slot撤销故障主节点负责的槽，并执行cluster add slot把这些槽分配给自己
- 向集群广播自己的pong消息，表明已经替换了故障从节点
三、故障转移演练
Redis Clutser开发运维常见问题
一、集群完整性
- cluster-require-full-converage默认为yes
- 完整性要求***集群中所有节点都是在线状态***并且***16384个槽都在一个服务的状态***才对外提供服务
- 大多数业务无法容忍，cluster-require-full-coverage建议设置为no
二、带宽消耗
-
官方建议：RedisCluster的节点不要超过1000个
-
每秒的PING/PONG消息会引起大量的带宽消耗
-
消息发送频率：节点发现与其他节点通信时间超过cluster-node-timeout / 2时会直接发PING消息
-
消息数据量：slots槽数组（2KB空间）和整个集群1/10的状态数据（10个节点状态数据约1KB）
-
节点部署的机器规模：集群分布的机器越多且每台机器划分的节点数越均匀，则集群内整体的可用带宽越高
-
优化方法
- 避免使用“大”集群：避免多业务使用一个集群，大业务可用多集群
- cluster-node-timeout：影响带宽和故障转移时间，需要权衡
- 尽量均匀分配到多机器上：保证高可用和带宽
三、Pub/Sub广播
- 问题：publish在集群每个节点中广播：加重带宽压力
- 解决方案1：需要使用Pub/Sub时，为了保证高可用，可以单独开启一套Redis Sentinel
- 解决方案2：使用消息队列
四、数据倾斜
1.数据倾斜
- 节点和槽的分配不均匀
- redis-trib.rb info ip:port 查看节点、槽、键值分布
- redis-trib.rb rebalance ip:port 进行槽的均衡（谨慎使用）
- 不同槽对应的键值数差异较大
- CRC16正常情况下比较均匀
- 可能存在hashKey
- cluster countkeysnslot ${slot} 获取槽对应的键值个数
- 包含bigKey（大字符串、几百万元素的hash、set、zset、list）
- 可以在从节点上执行：redis-cli --bigkeys
- 优化数据结构
- 内存相关配置不一致
2.请求倾斜（热点key或者bigKey）
- 通过优化数据结构避免bigKey
- 热点Key不要使用hash_tag
- 当一致性要求不高时，可以用本地缓存+MQ
五、读写分离
- 只读连接：集群模式的从节点不接受任何读写请求
- 重定向到负责槽的主节点
- readonly命令可以读：连接级别的命令
- 读写分离：更加复杂
- 与主从复制有同样的问题：复制延迟、读取过期数据、从节点故障
- 需要实现自己的客户端：cluster slave ${nodeId}
- 思路与Redis Sentinel一致
六、数据迁移
- 官方迁移工具：redis-trib.rb import
- 只能从单机迁移到集群
- 不支持在线迁移：source需要停止写入
- 不支持断点续传
- 单线程迁移：影响速度
- 对source数据进行SCAN，然后进行导入操作
- 在线迁移
- 唯品会：redis-migrate-tool
- 豌豆荚：redis-port
- 均支持在线迁移，会伪装成source节点的slave，利用这份更新数据再传送给target
七、集群VS单机
- 集群限制
- key批量操作支持有限：例如mget、mset必须在一个slot
- Key事务和Lua支持有限，操作的Key必须在一个节点
- Key是数据分区的最小粒度，不支持bigKey分区
- 不支持多数据库：集群模式下只有db 0
- 复制只支持一层：不支持树形复制结构
- 分布式Redis不一定好
- Redis Cluster：满足容量和性能的扩展性，很多业务不需要
- 不多数客户端性能会降低
- 命令无法跨节点使用：mget、mset、scan、flush、sinter
- Lua和事务无法跨节点使用
- 客户端维护更复杂：SDK和应用本身消耗（例如更多的连接池）
- 很多场景下：Redis Sentinel已经足够好
- Redis Cluster：满足容量和性能的扩展性，很多业务不需要