4.3.2.创建新的redis实例
创建一个文件夹：
mkdir 7004 • 1
拷贝配置文件：
cp redis.conf /7004
修改配置文件：
sed /s/6379/7004/g 7004/redis.conf • 1
启动
redis-server 7004/redis.conf
4.3.3.添加新节点到redis
添加节点的语法如下：
执行命令：
redis-cli --cluster add-node 192.168.150.101:7004 192.168.150.101:7001
过命令查看集群状态：
redis-cli -p 7001 cluster nodes • 1
如图，7004加入了集群，并且默认是一个master节点：
但是，可以看到7004节点的插槽数量为0，因此没有任何数据可以存储到7004上
4.3.4.转移插槽
我们要将num存储到7004节点，因此需要先看看num的插槽是多少：
如上图所示，num的插槽为2765.
我们可以将0~3000的插槽从7001转移到7004，命令格式如下：
具体命令如下：
建立连接：
得到下面的反馈：
询问要移动多少个插槽，我们计划是3000个：
新的问题来了：
那个node来接收这些插槽？？
显然是7004，那么7004节点的id是多少呢？
复制这个id，然后拷贝到刚才的控制台后：
这里询问，你的插槽是从哪里移动过来的？
- all：代表全部，也就是三个节点各转移一部分
- 具体的id：目标节点的id
- done：没有了
这里我们要从7001获取，因此填写7001的id：
填完后，点击done，这样插槽转移就准备好了：
确认要转移吗？输入yes：
然后，通过命令查看结果：
可以看到：
目的达成。
4.4.故障转移
集群初识状态是这样的：
其中7001、7002、7003都是master，我们计划让7002宕机。
.4.1.自动故障转移
当集群中有一个master宕机会发生什么呢？
直接停止一个redis实例，例如7002：
redis-cli -p 7002 shutdown
1）首先是该实例与其它实例失去连接
2）然后是疑似宕机：
3）最后是确定下线，自动提升一个slave为新的master：
4）当7002再次启动，就会变为一个slave节点了：
4.4.2.手动故障转移
利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。其流程如下：
这种failover命令可以指定三种模式：
缺省：默认的流程，如图1~6歩
force：省略了对offset的一致性校验
takeover：直接执行第5歩，忽略数据一致性、忽略master状态和其它master的意见
案例需求：在7002这个slave节点执行手动故障转移，重新夺回master地位
步骤如下：
1）利用redis-cli连接7002这个节点
2）执行cluster failover命令
如图：
效果：
4.5.RedisTemplate访问分片集群
RedisTemplate底层同样基于lettuce实现了分片集群的支持，而使用的步骤与哨兵模式基本一致：
1）引入redis的starter依赖
2）配置分片集群地址
3）配置读写分离
与哨兵模式相比，其中只有分片集群的配置方式略有差异，如下：
spring: redis: cluster: nodes: - 192.168.150.101:7001 - 192.168.150.101:7002 - 192.168.150.101:7003 - 192.168.150.101:8001 - 192.168.150.101:8002 - 192.168.150.101:8003
4.6 Redis分片集群优缺点及使用场景
优点：
提高系统性能和吞吐量：通过将数据分布到多个节点并行处理，可以显著提高系统的读写性能和吞吐量。
提高可用性和容错性：当某个节点宕机或出现故障时，其他节点仍可以正常工作，避免了单点故障对整个系统造成的影响，并保证了数据的安全性和可靠性。
扩展性好：通过增加节点的数量，可以方便地扩展系统的处理能力和存储能力，有良好的水平扩展性。
缺点：
需要额外的配置和管理：需要对分片规则、节点运行状态等进行配置和管理，相比于单节点，分片集群的部署和维护要复杂得多。
数据迁移成本较高：当需要调整节点数量或进行系统升级时，需要大量的数据迁移和重新平衡，其中包括数据备份、恢复、重定向和再平衡操作等，因此数据迁移的成本很高。
事务处理限制：由于Redis的分布式事务功能受到限制，导致在进行事务处理时，可能会因为跨多节点而存在很多限制，而且在某些场景下，可能需要使用到分布式锁等相关技术，进行事务处理的控制。
使用场景：
数据量较大或读写频繁：当单个Redis节点无法满足系统的性能要求时，可以考虑将数据分片到多个节点上，提高系统的处理能力和吞吐量。
业务需求分区：当业务数据可以按照某种规则进行划分并处理，比如按照用户ID进行划分，可以将不同用户的数据存储在不同的节点上，减少数据之间的交叉影响，同时提高系统的可维护性和可扩展性。
高可用性和容错性：当业务对于服务的可用性和数据安全性有严格要求时，可以采用Redis分片集群，保证系统的可用性和数据的安全性。
ter:
nodes:
- 192.168.150.101:7001
- 192.168.150.101:7002
- 192.168.150.101:7003
- 192.168.150.101:8001
- 192.168.150.101:8002- 192.168.150.101:8002
- 192.168.150.101:8003
## 4.6 Redis分片集群优缺点及使用场景 优点： 1. 提高系统性能和吞吐量：通过将数据分布到多个节点并行处理，可以显著提高系统的读写性能和吞吐量。 2. 提高可用性和容错性：当某个节点宕机或出现故障时，其他节点仍可以正常工作，避免了单点故障对整个系统造成的影响，并保证了数据的安全性和可靠性。 3. 扩展性好：通过增加节点的数量，可以方便地扩展系统的处理能力和存储能力，有良好的水平扩展性。 缺点： 1. 需要额外的配置和管理：需要对分片规则、节点运行状态等进行配置和管理，相比于单节点，分片集群的部署和维护要复杂得多。 2. 数据迁移成本较高：当需要调整节点数量或进行系统升级时，需要大量的数据迁移和重新平衡，其中包括数据备份、恢复、重定向和再平衡操作等，因此数据迁移的成本很高。 3. 事务处理限制：由于Redis的分布式事务功能受到限制，导致在进行事务处理时，可能会因为跨多节点而存在很多限制，而且在某些场景下，可能需要使用到分布式锁等相关技术，进行事务处理的控制。 使用场景： 1. 数据量较大或读写频繁：当单个Redis节点无法满足系统的性能要求时，可以考虑将数据分片到多个节点上，提高系统的处理能力和吞吐量。 2. 业务需求分区：当业务数据可以按照某种规则进行划分并处理，比如按照用户ID进行划分，可以将不同用户的数据存储在不同的节点上，减少数据之间的交叉影响，同时提高系统的可维护性和可扩展性。 3. 高可用性和容错性：当业务对于服务的可用性和数据安全性有严格要求时，可以采用Redis分片集群，保证系统的可用性和数据的安全性。
