Redis入门(5): Redis持久化（RDB与AOF），主从复制，集群操作

Redis持久化

官网介绍：http://www.redis.io
Redis 提供了2个不同形式的持久化方式。

• RDB（Redis DataBase）
• AOF（Append Of File）

1、RDB

定义：在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的 Snapshot 快照，它恢复时是将快照文件直接读到内存里。（每一段固定时间间隔后就会生成一个快照）

RDB持久化流程

• Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，
• 待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
• 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
• 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork

• Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
• 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
• 一般情况 父进程和子进程会共用同一段物理内存 ，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

持久化文件

• 文件名默认为 dump.rdb，在 redis.conf 中进行配置。
  
• 持久化文件位置，rdb文件的保存路径，也可以修改。
  默认为Redis启动时命令行所在的目录下 dir "/myredis/"
  

快照触的策略

• 配置文件中默认的快照配置策略如下：
  
  如果只有一个key发生变化，则一个小时更新一次。
  如果有至少100个key发生变化，则 30 s 内保存一次。
  。。。。

• 命令 save VS bgsave
  save ： 直接使用 save 命令可以进行手动保存， save时只管保存，其它不管，全部阻塞。
  bgsave： Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
  可以通过lastsave 命令获取最后一次成功执行快照的时间

• flushall命令
  执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

• stop-writes-on-bgsave-error
  当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes.
  

• rdbcompression 压缩文件
  

  • 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
  • 如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

• rdbchecksum 检查完整性
  

  • 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，推荐yes.

• 但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

rdb 的备份与恢复

备份：

• 1、先通过 config get dir 查询rdb文件的目录
• 2、将 *.rdb 的文件拷贝到别的地方

恢复

• 关闭Redis
• 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
• 启动Redis, 备份数据会直接加载

优缺点

• 优势（多快省）
  适合大规模的数据恢复
  对数据完整性和一致性要求不高更适合使用
  节省磁盘空间
  恢复速度快

• 劣势（fork 方法本身的问题，以及丢失最后一次快照）
  Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
  虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
  在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

• 总结：
  

• 动态停止RDB： redis-cli config set save "" #save后给空值，表示禁用保存策略

2、AOF

定义

• 以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件
• redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF持久化流程

• 客户端的请求写命令会被 append 追加到AOF缓冲区内；
• AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
• AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
• Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；
  

默认配置

• AOF默认不开启
  可以在 redis.conf 中配置文件名称，默认为 appendonly.aof
  AOF文件的保存路径，同RDB的路径一致。

• AOF 和 RDB 同时开启，redis听谁的？
  AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

• AOF同步频率设置

  • appendfsync always
    始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
  • appendfsync everysec
    每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
  • appendfsync no
    redis不主动进行同步，把同步时机交给操作系统。

AOF启动/修复/恢复

• AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

正常恢复

• 修改默认的appendonly no，改为yes
• 将有数据的 aof 文件复制一份保存到对应目录(查看目录：config get dir)
• 恢复：重启redis然后重新加载

异常恢复

• 修改默认的 appendonly no，改为yes
• 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复
• 备份被写坏的AOF文件
• 恢复：重启redis，然后重新加载

Rewrite压缩

定义：

• AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时
• Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令 bgrewriteaof

重写原理：

• AOF 文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)
• redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。相当于说，把之前的打包成rdb快照，后面的继续用 AOF记录

no-appendfsync-on-rewrite：

• 如果 no-appendfsync-on-rewrite=yes 不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
• 如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写：

• Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发
• 重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
  • 条件一：auto-aof-rewrite-percentage
    文件与原文件的倍数关系。默认为 100%，表示文件是原来重写后文件的2倍时触发。
  • 条件二：auto-aof-rewrite-min-size
    设置重写的基准值，最小文件 64MB。达到这个值开始重写
  • 注意 必须同时满足上面两个条件才行。
  • 例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？那么重写的阈值应该是大于50MB的 100%，即100MB 触发重写
  • 总结： 系统载入时或者上次重写完毕时，Redis 会记录此时 AOF 大小，设为 base_size, 如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

重写流程:

• bgrewriteaof触发重写，判断是否当前有 bgsave 或bgrewriteaof 在运行，如果有，则等待该命令结束后再继续执行。如果之前也有写操作，那么排队等待
• 主进程 fork 出子进程执行重写操作，保证主进程不会阻塞。
• 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf 重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
• 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
• 主进程把 aof_rewrite_buf 中的数据写入到新的AOF文件。
• 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。
  

优势 与 劣势

优势

• 备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能。

总结

3、RDB 与 AOF 的比较

官方推荐两个都启用。

• 如果对数据不敏感，可以选单独用RDB。
• 不建议单独用 AOF，因为可能会出现Bug。
• 如果只是做纯内存缓存，可以都不用。

官网建议

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
• Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
• 只做缓存： 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
• 同时开启两种持久化方式
  在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
  建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
• 性能建议
  因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

主从复制

主从复制的概念讲解，请查看这里：

定义： 主机数据更新后根据配置和策略， 自动同步到备机的 master/slaver 机制，Master以写为主，Slave以读为主

• 读写分离，性能扩展
• 容灾快速恢复
  

一、主从复制的 redis 模拟

创建 三个 redis 服务器

• 1、为了方便，专门创建一个文件夹 /masteredis 用来专门做主从复制

• 2、将 redis 中的配置文件复制到该文件夹下：

   cp /myredis/redis.conf /masteredis/
  

• 3、因为需要创建一主两从的三个配置文件，因此需要使用三个不同的端口。可以创建文件名如下：

  • redis6379.conf
  • redis6380.conf
  • redis6381.conf

• 4、由于现在每个配置文件都需要独立的进行持久化且使用RDB，那么此时我们需要关闭原来的AOF操作。进入/masteredis/redis.conf 关闭AOF ，即appendonly=no：
  

• 5、在三个配置文件中写入内容
  redis6379.conf

  # 引入公共部分
  include /masteredis/redis.conf
  # pid 的文件位置
  pidfile /var/run/redis_6379.pid
  # 端口号
  port 6379
  # rdb 文件名称
  dbfilename dump6379.rdb
  

  同理 redis_6380

  include /masteredis/redis.conf
  pidfile /var/run/redis_6380.pid
  port 6380
  dbfilename dump6380.rdb
  

  同理 redis_6381

  include /masteredis/redis.conf
  pidfile /var/run/redis_6381.pid
  port 6381
  dbfilename dump6381.rdb
  

• 6、将中三个redis服务器进行启动：
  

• 7、打开三个客户端，根据端口启动不同的服务器：
  

主从分配

• 1、 在进行分配之前，由于主服务器开启了密码验证，因此需要在 3980 和 3981 的配置文件中设置 masterauth：

  # 如果开启了 requirepass 假设为 requirepass 123456
  # 需要设置主服务器验证属性
  masterauth 123456
  

• 2、通过 slaveof <ip><port> 设置主仆关系，slaveof 将该客户端设置为某个实例的从服务器。
  在 6380 和 6381 中运行 slaveof 127.0.0.1 6379

• 3、 使用 info replication 进行查看当前服务器时主机还是从机。从下面的信息可以看到，我们配置的6380 和 6381的角色为从机，主机为6379。
  
  

测试

• 1、 测试数据同步： 我们可以尝试在主机中写数据，然后观察从机是否存在：
  
  
• 2、测试从机写操作： 可以看到从机不能写操作，会报错
  
• 3、恢复重启： 主机挂掉，重启就行，一切如初
• 4、从机重启，会变成主服务器，只有重设：slaveof 127.0.0.1 6379 才能又变回从服务器。

二、主从复制的三个问题

1、一主二仆

切入点问题？ ：slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的k1,k2,k3是否也可以复制？

• 答：当从机挂掉之后，如果重新将从服务器加到主服务器中，那么此时从服务器会从头复制主服务器的所有数据到从机中。
• 当主服务器挂掉了，此时从服务器的角色不会变，还是从服务器，不过它会存一个主服务器的状态码，表示主服务器已经挂掉了。此时重新启动主服务器，主服务器与从服务器的关系依然存在。

2、薪火相传

• 上一个 Slave 可以是下一个 slave 的 Master，Slave 同样可以接收其他 slaves 的连接和同步请求，
• 那么该 slave 作为了链条中下一个的 master, 可以有效减轻master 的写压力,去中心化降低风险。
• 还是使用 slaveof <ip><port> 指定主服务器。
• 中途变更转向，会清除之前的数据，重新建立拷贝最新的
• 风险是一旦某个slave宕机，后面的slave都没法备份
• 从机还是从机，无法写数据了
  
  

3、反客为主

• 当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不用做任何修改。
• 当master 已经宕机时，升级其他salve为master的语句为：slaveof no one
  

三、主从复制基本原理

• Slave启动成功连接到 master 后会发送一个sync命令（请求同步命令）
• Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
• 全量复制：而 slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量复制：Master 继续将新的所有收集到的修改命令依次传给slave,完成同步
• 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
  

四、哨兵模式

定义： 反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

哨兵模式的配置

• 1、 调整为一主二仆模式，6379带着6380、6381

• 2、自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错

• 3、在新建的文件中指定要监控的对象服务器：

  sentinel monitor mymaster 127.0.0.1 6379 1
  

  • 其中 mymaster 为监控对象起的服务器名称
  • 1 为至少有多少个哨兵同意迁移的数量。 ====

• 4、启动哨兵
  使用 redis-sentinel /myredis/sentinel.conf 来启动哨兵
  
  红框处即为监视的哨兵。

• 5、 当主机挂掉，从机选举中产生新的主机
  此时如果我们先，利用 shutdown 关闭主机，观察哨兵服务器中的控制台中，可以看到，此时重新找了 6380 作为 master。
  
  注意： 原主机重启后会变为从机。
  哪个从机会被选举为主机呢？根据优先级别：slave-priority

• 6、选举新服务器的规则
  

  • 服务器的优先级的默认值存在配置文件 redis.conf 中：slave-priority 100，值越小优先级越高。
  • 偏移量 是指获得原主机数据最全的
  • 每个redis实例启动后都会随机生成一个40位的runid

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

五、主从复制的java方法(带哨兵的连接池)

private static JedisSentinelPool jedisSentinelPool=null;

public static  Jedis getJedisFromSentinel(){
    
    
if(jedisSentinelPool==null){
    
    
            Set<String> sentinelSet=new HashSet<>();
            sentinelSet.add("192.168.11.103:26379");

            JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
            jedisPoolConfig.setMaxTotal(10); //最大可用连接数
			jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
			jedisPoolConfig.setMinIdle(5); //最小闲置连接数
			jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
			jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
			jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong

			jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
			return jedisSentinelPool.getResource();
        }else{
    
    
			return jedisSentinelPool.getResource();
        }
}

Redis集群

一、 背景

• 容量不够，redis如何进行扩容？
• 并发写操作， redis如何分摊？
• 另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。
• 之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。

  • 代理主机方式： 拿电商举例，用户模块，订单模块，商品模块都放在不同的服务器中。此时在这三个模块之外，外加一个代理服务器。代理服务器根据请求，将具体请求传到不同的服务器。缺点：每个服务器都有可能挂掉，因此不仅需要给三个模块的服务器分别加从服务器，还需要给代理主机加从服务器。
    

  • 无中心化服务： 还是拿刚才的电商案例距离。任何一台服务器都可以作为请求的入口。如果需要进行用户操作的请求发送给了订单模块服务器，那么测试订单模块服务器会进行一次转发，将该请求转发到用户模块服务器。

二、特点

• Redis 集群实现了对 Redis 的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
• Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

三、部署一个三主三从的服务器集群。（用户，订单，商品）

1、环境的搭建

• 首先删除原来的持久化数据，防止实验产生影响。
  将rdb,aof文件都删除掉。

• 制作6个实例，6379,6380,6381,6389,6390,6391。以 6379 为例，需要在 redis6379.conf 中添加的信息如下：

  include /masteredis/redis.conf
  port 6379
  pidfile "/var/run/redis_6379.pid"
  dbfilename "dump6379.rdb"
  # 打开集群模式
  cluster-enabled yes
  # 设置节点配置文件名
  cluster-config-file nodes-6379.conf
  # 设置失联时间，如果超过时间就会进行主从的切换
  cluster-node-timeout 15000
  
  

  技巧： 先创建 6379，其他的直接复制，然后利用 :%s/6379/6380 直接对一个vim中的所有字符进行替换。
  

• 启动六个服务：
  

• 注意：在公共的 conf 中，记得设置 dir，这样才能够让生成文件在该路径下。 下图为生成的六个节点配置。
  

2、集群的创建

在启动完所有的服务器之后，使用下面代码进行集群的创建：

redis-cli --cluster create --cluster-replicas 1 192.168.11.101:6379 192.168.11.101:6380 192.168.11.101:6381 192.168.11.101:6389 192.168.11.101:6390 192.168.11.101:6391

• 此处不要用127.0.0.1，使用的是真实IP，因为实际情况下这些是不同的服务器。

• -replicas 1 replicas 表示集群配置方式。1 表示采用最简单的方式配置集群，一台主机，一台从机，正好三组。
  

• 如果选择yes，则表示接收它默认安排的主从关系。这里我们直接接收
  
  注意： 云服务器需要打开 10000-20000的所有端口，已经上面涉及到的端口

3、如果以普通方式登录

可能直接进入读主机，存储数据时，会出现 MOVED 重定向操作。所以，应该以集群方式登录。

4、-c 采用集群策略连接

在登录是添加 参数 -c，设置数据会自动切换到相应的写主机：这样就能就不会出现上面的 MOVE 错误了

• 如上图，写操作会自动转发给相应的服务器中。

5、使用cluster node 查看所有节点

6、redis cluster 的分配策略

一个集群至少要有三个主节点。

• 选项--cluster-replicas 1表示我们希望为集群中的每个主节点创建一个从节点。
• 分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。

四、slots

在上面的 第 2 步集群创建中，集群创建成功会显示如下的配置信息：

[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...

• 一个 Redis 集群包含 16384 个插槽（hash slot）， 数据库中的每个键都属于这 16384 个插槽的其中一个，
• 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
• 集群中的每个节点负责处理一部分插槽。
  举个例子， 如果一个集群可以有主节点（A,B,C）， 其中：
  • 节点 A 负责处理 0 号至 5460 号插槽。
  • 节点 B 负责处理 5461 号至 10922 号插槽。
  • 节点 C 负责处理 10923 号至 16383 号插槽。

五、在集群中录入值

• 在 redis-cli 每次录入、查询键值，redis 都会计算出该 key 应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。普通登录报错的原因
• redis-cli 客户端提供了–c 参数实现自动重定向。
  如 redis-cli -c –p 6379登入后，再录入、查询键值对可以自动重定向。
• 不在一个slot下的键值，是不能使用mget,mset等多键操作。
• 可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去。
  该命令表示将 k1,k2,k3 都放入到 cust 的槽中。

六、查询集群中的值

• CLUSTER GETKEYSINSLOT <slot><count> 返回 count 个 slot 槽中的键。
  

七、故障恢复

如果主机挂掉，从机晋升：

• 首先我们将 6379 停掉，然后观察 cluster nodes 的情况如下:
  
  可以看到 6379 已将挂掉，6389已升为 master
• 重启6379，那么此时6379会恢复成 6389 的从机。

当某一段插槽的主机和从机都挂掉了：
看情况，根据 配置中的参数 cluster-require-full-coverage 来决定：

• cluster-require-full-coverage 为 yes ，那么 ，整个集群都挂掉
• cluster-require-full-coverage为 no ，那么，该插槽数据全都不能使用，也无法存储。

八、集群的 Jedis 开发

• 即使连接的不是主机，集群会自动切换主机存储。主机写，从机读。

• 无中心化主从集群。无论从哪台主机写的数据，其他主机上都能读到数据。

  public class JedisClusterTest {
        
        
    public static void main(String[] args) {
        
         
       Set<HostAndPort>set =new HashSet<HostAndPort>();
       set.add(new HostAndPort("192.168.31.211",6379));
       JedisCluster jedisCluster=new JedisCluster(set);
       jedisCluster.set("k1", "v1");
       System.out.println(jedisCluster.get("k1"));
    }
  }
  
  

九、优缺点

优点：

• 实现扩容
• 分摊压力
• 无中心配置相对简单

缺点：

• 多键操作是不被支持的
• 多键的 Redis 事务是不被支持的。lua 脚本不被支持
• 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至 redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。