Redis部署
一、redis hash tag
使用原因，出现错误
redis.exceptions.ResponseError: CROSSSLOT Keys in request don't hash to the same slot
在集群中，key会被划分到不同的槽中。不同的节点会拥有散列槽的一个子集。
多个key的操作、事务或者lua脚本调用多个key是允许的，只要所有被调用的key都在一个节点的hash槽中就可以。
哈希标签是确保两个键都在同一个哈希槽里的一种方式。
使用方法：
如果一个键包含一个 “{…}” 这样的模式，只有 { 和 } 之间的字符串会被用来做哈希以获取哈希槽；
第一个{ 和 第一个{ 右边的第一个} 是有效计算值。
Redis hash tag_hashtag redis_Dongguabai的博客-CSDN博客
二、redis的部署方式
2.1 单机模式
最简单的部署方式，即在一台机器上运行 Redis 服务。这种方式适用于数据量较小、读写量不是很大的应用场景。
2.2 主从复制模式
将一个 Redis 实例作为主节点，其他 Redis 实例作为从节点，主节点负责写入数据，从节点复制主节点的数据，实现数据的备份和读取负载均衡。这种方式适用于数据量较大、读写量较高的场景。
2.3 哨兵模式
在主从复制模式的基础上，引入 Redis Sentinel（哨兵），用于监控主节点的健康状态，当主节点出现故障时，自动将某个从节点升级为主节点，确保服务的高可用性。这种方式适用于对可用性要求较高的场景。
2.4 集群模式
将多个 Redis 实例组成一个集群，数据被分片存储在不同的节点上，每个节点负责存储一部分数据，通过集群代理将请求路由到正确的节点。这种方式适用于数据量非常大、读写量极高的场景。
三. Redis 哨兵模式故障切换机制
Redis 哨兵模式是一种高可用性的部署模式，在该模式下，Redis Sentinel（哨兵）会监控主节点的健康状态，当主节点出现故障时，自动将某个从节点升级为主节点，实现自动故障切换机制。Redis 哨兵模式的故障切换机制分为以下几个步骤：
监控主节点状态：哨兵会定期向主节点发送 PING 命令，用于检查主节点是否在线。如果连续几次 PING 命令失败，则哨兵认为主节点出现故障。
宣告主节点故障：当 quorum-1 个哨兵认为主节点出现故障时，哨兵会宣告主节点故障，并向其他哨兵发送通知消息。
选举新的主节点：哨兵会发起投票，选举出新的主节点。在投票过程中，哨兵会考虑每个从节点的优先级、最近一次与主节点通信的时间等因素，并选择最适合成为主节点的从节点。如果选举出的从节点数量不足 quorum，则选举失败。
向客户端广播新的主节点地址：一旦选举出新的主节点，哨兵会向所有客户端广播新的主节点地址，客户端收到广播消息后，会重新连接新的主节点。
更新从节点配置：一旦选举出新的主节点，哨兵会更新所有从节点的配置，使其成为新的主节点的从节点。
总之，Redis 哨兵模式的故障切换机制可以自动实现主从切换，确保服务的高可用性。在故障切换过程中，哨兵会选择最适合成为主节点的从节点，并将新的主节点地址广播给客户端，客户端重新连接新的主节点即可。
四、集群部署方式
4.1 槽位分配
集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
CRC16(‘my_key’)%16384 = 2412
4.2 redis节点扩容
4.2.1 将节点加入集群
redis-cli --cluster add-node {new host}:{new port} {exist host}:{exist port} 加入集群
redis-cli --cluster add-node 192.168.0.207:6380 192.168.0.31:6380
redis-cli --cluster add-node 192.168.0.208:6380 192.168.0.31:63804.2.2 确认集群状态
[root@kafka31 data]# redis-cli -p 6380
127.0.0.1:6380> cluster nodes
3c1b16407c984f33b7c0ff06b8a7bbcc59c1d91b 192.168.0.208:6380@16380 master - 0 1550229198271 11 connected
ed93d5ea74751d7124a2d5830ce0806a0c962d43 192.168.0.32:6380@16380 master - 0 1550229196000 2 connected 5461-10922
3ba3e8323b7b637c958977335bf7f7213c009929 192.168.0.35:6380@16380 slave ed93d5ea74751d7124a2d5830ce0806a0c962d43 0 1550229197267 5 connected
7fbf45fdc4d0780074f8fe324aac28ae686eebaa 192.168.0.34:6380@16380 slave 92fd7c2a7b7b8933d1019e72a852f621f6b4faff 0 1550229196264 10 connected
b94828e8816574d66b413c6bfa6de130eb14ee66 192.168.0.207:6380@16380 master - 0 1550229194000 0 connected
3641ec8359d5400e5540d77600a2360de8ca367e 192.168.0.33:6380@16380 master - 0 1550229194258 3 connected 10923-16383
a5ac7dfedd81f2ecd9dd101ef8d9d4f70f895bbf 192.168.0.36:6380@16380 slave 3641ec8359d5400e5540d77600a2360de8ca367e 0 1550229193256 6 connected
92fd7c2a7b7b8933d1019e72a852f621f6b4faff 192.168.0.31:6380@16380 myself,master - 0 1550229194000 10 connected 0-54604.2.3 使用redis-cli自动迁移槽
/usr/local/redis/bin/redis-cli --cluster reshard 1192.168.0.31:6380
前面有介绍过手动迁移槽的过程，但是过程繁琐，容易出错，这里使用redis-cli自动迁移槽。
redis-trib.rb reshard host:port --from --to --slots --yes --timeout --pipeline
参数说明：
host：port：必传参数，集群内任意节点地址，用来获取整个集群信息。
--from：制定源节点的id，如果有多个源节点，使用逗号分隔，如果是all源节点变为集群内所有主节点，在迁移过程中提示用户输入。
--to：需要迁移的目标节点的id，目标节点只能填写一个，在迁移过程中提示用户输入。
--slots：需要迁移槽的总数量，在迁移过程中提示用户输入。
--yes：当打印出reshard执行计划时，是否需要用户输入yes确认后再执行reshard。
-timeout：控制每次migrate操作的超时时间，默认为60000毫秒。
--pipeline：控制每次批量迁移键的数量，默认为10。 4.2.4 使用redis-cli迁移4096个槽到207
redis-cli --cluster reshard 192.168.0.31:6380
...
How many slots do you want to move (from 1 to 16384)? 4096 #要迁移多少个槽
What is the receiving node ID? b94828e8816574d66b413c6bfa6de130eb14ee66 #迁移到哪个节点
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
#要求输入源节点的id，这里输入31,32,33三个节点，输入done表示结束
Source node #1: 92fd7c2a7b7b8933d1019e72a852f621f6b4faff
Source node #2: ed93d5ea74751d7124a2d5830ce0806a0c962d43
Source node #3: 3641ec8359d5400e5540d77600a2360de8ca367e
Source node #4: done
最后会有一个迁移方案，输入yes表示同意，迁移开始。输入no表示不同意，重新设置迁移方案。迁移完成后，确认集群状态，0-1364 5461-6826 10923-12287这些槽分配给了207节点
[root@kafka31 data]# redis-cli -p 6380
127.0.0.1:6380> cluster nodes
3c1b16407c984f33b7c0ff06b8a7bbcc59c1d91b 192.168.0.208:6380@16380 master - 0 1550230101738 11 connected
ed93d5ea74751d7124a2d5830ce0806a0c962d43 192.168.0.32:6380@16380 master - 0 1550230098728 2 connected 6827-10922
3ba3e8323b7b637c958977335bf7f7213c009929 192.168.0.35:6380@16380 slave ed93d5ea74751d7124a2d5830ce0806a0c962d43 0 1550230100000 5 connected
7fbf45fdc4d0780074f8fe324aac28ae686eebaa 192.168.0.34:6380@16380 slave 92fd7c2a7b7b8933d1019e72a852f621f6b4faff 0 1550230100734 10 connected
b94828e8816574d66b413c6bfa6de130eb14ee66 192.168.0.207:6380@16380 master - 0 1550230098000 12 connected 0-1364 5461-6826 10923-12287
3641ec8359d5400e5540d77600a2360de8ca367e 192.168.0.33:6380@16380 master - 0 1550230100000 3 connected 12288-16383
a5ac7dfedd81f2ecd9dd101ef8d9d4f70f895bbf 192.168.0.36:6380@16380 slave 3641ec8359d5400e5540d77600a2360de8ca367e 0 1550230099000 6 connected
92fd7c2a7b7b8933d1019e72a852f621f6b4faff 192.168.0.31:6380@16380 myself,master - 0 1550230097000 10 connected 1365-54604.2.5 检测节点之间槽的均衡性
使用redis-cli --cluster rebalance检测节点间槽的均衡性
[root@kafka31 data]# redis-cli --cluster rebalance 192.168.0.31:6380
>>> Performing Cluster Check (using node 192.168.0.31:6380)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
*** No rebalancing needed! All nodes are within the 2.00% threshold.可以看出，节点负责的槽数据差异在2%以内，因此槽分配均衡。
4.2.6 添加从节点
将208添加为207的从节点
127.0.0.1:6380> cluster replicate b94828e8816574d66b413c6bfa6de130eb14ee66
OK确认集群状态，208为207的从节点，207负责0-1364 5461-6826 10923-12287这4096个槽，至此使用redis-cli自动迁移槽完成。
127.0.0.1:6380> cluster nodes
3c1b16407c984f33b7c0ff06b8a7bbcc59c1d91b 192.168.0.208:6380@16380 myself,slave b94828e8816574d66b413c6bfa6de130eb14ee66 0 1550230723000 11 connected
...
b94828e8816574d66b413c6bfa6de130eb14ee66 192.168.0.207:6380@16380 master - 0 1550230720727 12 connected 0-1364 5461-6826 10923-12287 集群手动搭建：redis实战第六篇 手动创建redis cluster_我是李超人的博客-CSDN博客
集群自动搭建：redis实战第七篇 使用redis工具（redis-cli）搭建redis cluster_我是李超人的博客-CSDN博客