Fulongのblog

Redis2-知识点

2021/05/28 Database 共 10255 字，约 30 分钟

Redis2-知识点

Redis持久化数据和缓存怎么做扩容？

  • 如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。
  • 如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。
场景推荐扩容方案
缓存为主，QPS 高水平扩展（分片/Cluster）
单机内存不够垂直扩展（升级配置）
读多写少（查询压力大）主从复制（读写分离）
需要持久化（高可靠性）Cluster + AOF/RDB
单机 Redis 迁移到新机器RDB/AOF 迁移

Redis为什么这么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路 I/O 复用模型，非阻塞 IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

Redis的过期键的删除策略

我们都知道，Redis是key-value数据库，我们可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。

过期策略通常有以下三种：

  • 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
  • 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
  • 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 (expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

Redis中同时使用了惰性过期和定期过期两种过期策略。

Redis的内存淘汰策略有哪些

Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

全局的键空间选择性移除

  • noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
  • allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。（这个是最常用的）
  • allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

设置过期时间的键空间选择性移除

  • volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
  • volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
  • volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

4.0 版本后增加以下两种 lfu的。 LFU 通过统计 key 的访问频率，优先淘汰使用频率最低的 key。每次访问 key 时，LFU 计数器都会增加，Redis 在空间不足时会淘汰访问次数最少的 key。

  1. volatile-lfu（least frequently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰。
  2. allkeys-lfu（least frequently used）：从数据集（server.db[i].dict）中移除最不经常使用的数据淘汰。

节点间的内部通信机制

基本通信原理

集群元数据的维护有两种方式：集中式、Gossip 协议。redis cluster 节点间采用 gossip 协议进行通信。

分布式寻址算法

  • hash 算法（大量缓存重建）
  • 一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
  • redis cluster 的 hash slot 算法

redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot

redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot

hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去

  • 移动hash slot的成本是非常低的

  • 客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现

redis为什么使用hash槽。

这个和redis 集群的架构特点有关系

  • 去中心化。 查找节点快，性能。

  • 方便伸缩 （自动伸缩、手动伸缩都可以），扩展简单。

redis cluster 节点间采用gossip协议进行通信

说说Redis哈希槽的概念？

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

Redis集群会有写操作丢失吗？为什么？

Redis并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

Redis集群之间是如何复制的？

异步复制

Redis集群最大节点个数是多少？

16384个

Redis集群如何选择数据库？

Redis集群目前无法做数据库选择，默认在0数据库。

分区

Redis是单线程的，如何提高多核CPU的利用率？

可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个CPU，你可以考虑一下分片（shard）。

为什么要做Redis分区？

分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升，Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。

你知道有哪些Redis分区实现方案？

  • 客户端分区就是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取。大多数客户端已经实现了客户端分区。

  • 代理分区 意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy

  • 查询路由(Query routing) 的意思是客户端随机地请求任意一个redis实例，然后由Redis将请求转发给正确的Redis节点。Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个redis节点转发到另一个redis节点，而是在客户端的帮助下直接redirected到正确的redis节点。

Redis分区有什么缺点？

  • 涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）。
  • 同时操作多个key,则不能使用Redis事务.
  • 分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集（The partitioning granularity is the key, so it is not possible to shard a dataset with a single huge key like a very big sorted set）
  • 当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的Redis实例和主机同时收集RDB / AOF文件。
  • 分区时动态扩容或缩容可能非常复杂。Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。然而，有一种预分片的技术也可以较好的解决这个问题。

热点数据和冷数据

热点数据，缓存才有价值

对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不大。频繁修改的数据，看情况考虑使用缓存

对于热点数据，比如我们的某IM产品，生日祝福模块，当天的寿星列表，缓存以后可能读取数十万次。再举个例子，某导航产品，我们将导航信息，缓存以后可能读取数百万次。

数据更新前至少读取两次，缓存才有意义。这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。

那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的某助手产品的，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到Redis缓存，减少数据库压力。

keys和scan

使用 keys 指令可以扫出指定模式的 key 列表。但是要注意 keys 指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用 scan 指令，scan 指令可以无阻塞的提取出指定模式的 key 列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用 keys 指令长。

线程模型

对于读写命令来说，Redis 一直是单线程模型。不过，在 Redis 4.0 版本之后引入了多线程来执行一些大键值对的异步删除操作， Redis 6.0 版本之后引入了多线程来处理网络请求（提高网络 IO 读写性能）。

Redis 4.0 之后新增了几个异步命令：

  • UNLINK：可以看作是 DEL 命令的异步版本。
  • FLUSHALL ASYNC：用于清空所有数据库的所有键，不限于当前 SELECT 的数据库。
  • FLUSHDB ASYNC：用于清空当前 SELECT 数据库中的所有键。

那 Redis6.0 之前为什么不使用多线程？ 我觉得主要原因有 3 点：

  • 单线程编程容易并且更容易维护；

  • Redis 的性能瓶颈不在 CPU ，主要在内存和网络；

  • 多线程就会存在死锁、线程上下文切换等问题，甚至会影响性能。

Redis6.0 引入多线程主要是为了提高网络 IO 读写性能，因为这个算是 Redis 中的一个性能瓶颈（Redis 的瓶颈主要受限于内存和网络）。单线程模型意味着 Redis 在大量 IO 请求时，无法充分利用多核 CPU 的优势。

虽然，Redis6.0 引入了多线程，但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了，执行命令仍然是单线程顺序执行。因此，你也不需要担心线程安全问题。

我们虽然经常说 Redis 是单线程模型（主要逻辑是单线程完成的），但实际还有一些后台线程用于执行一些比较耗时的操作：

  • 通过 bio_close_file 后台线程来释放 AOF / RDB 等过程中产生的临时文件资源。
  • 通过 bio_aof_fsync 后台线程调用 fsync 函数将系统内核缓冲区还未同步到到磁盘的数据强制刷到磁盘（ AOF 文件）。
  • 通过 bio_lazy_free后台线程释放大对象（已删除）占用的内存空间.

Redis 性能优化

使用批量操作减少网络传输

一个 Redis 命令的执行可以简化为以下 4 步：

  1. 发送命令
  2. 命令排队
  3. 命令执行
  4. 返回结果

其中，第 1 步和第 4 步耗费时间之和称为 Round Trip Time (RTT,往返时间) ，也就是数据在网络上传输的时间。

使用批量操作可以减少网络传输次数，进而有效减小网络开销，大幅减少 RTT。

另外，除了能减少 RTT 之外，发送一次命令的 socket I/O 成本也比较高（涉及上下文切换，存在read()和write()系统调用），批量操作还可以减少 socket I/O 成本。

大量 key 集中过期问题

对于过期 key，Redis 采用的是 定期删除+惰性/懒汉式删除 策略。

如何解决呢？ 下面是两种常见的方法：

  1. 给 key 设置随机过期时间。
  2. 开启 lazy-free（惰性删除/延迟释放） 。lazy-free 特性是 Redis 4.0 开始引入的，指的是让 Redis 采用异步方式延迟释放 key 使用的内存，将该操作交给单独的子线程处理，避免阻塞主线程。

大key

大 key 还会造成阻塞问题。具体来说，主要体现在下面三个方面：

  1. 客户端超时阻塞：由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。
  2. 网络阻塞：每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。
  3. 工作线程阻塞：如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。

大 key 造成的阻塞问题还会进一步影响到主从同步和集群扩容。

如何发现 bigkey？

1、使用 Redis 自带的 --bigkeys 参数来查找。

2、使用 Redis 自带的 SCAN 命令 SCAN 命令可以按照一定的模式和数量返回匹配的 key。获取了 key 之后，可以利用 STRLEN、HLEN、LLEN等命令返回其长度或成员数量。

3、 通过分析 RDB 文件来找出 big key。这种方案的前提是你的 Redis 采用的是 RDB 持久化。

bigkey 的常见处理以及优化办法如下（这些方法可以配合起来使用）：

  • 分割 bigkey：将一个 bigkey 分割为多个小 key。例如，将一个含有上万字段数量的 Hash 按照一定策略（比如二次哈希）拆分为多个 Hash。
  • 手动清理：Redis 4.0+ 可以使用 UNLINK 命令来异步删除一个或多个指定的 key。Redis 4.0 以下可以考虑使用 SCAN 命令结合 DEL 命令来分批次删除。
  • 采用合适的数据结构：例如，文件二进制数据不使用 String 保存、使用 HyperLogLog 统计页面 UV、Bitmap 保存状态信息（0/1）。
  • 开启 lazy-free（惰性删除/延迟释放） ：lazy-free 特性是 Redis 4.0 开始引入的，指的是让 Redis 采用异步方式延迟释放 key 使用的内存，将该操作交给单独的子线程处理，避免阻塞主线程。

热key

例如在 Redis 实例的每秒处理请求达到 5000 次，而其中某个 key 的每秒访问量就高达 2000 次，那这个 key 就可以看作是 hotkey。

hotkey 出现的原因主要是某个热点数据访问量暴增，如重大的热搜事件、参与秒杀的商品。

发现热key

  • 使用 Redis 自带的 --hotkeys 参数来查找。

  • MONITOR 命令是 Redis 提供的一种实时查看 Redis 的所有操作的方式，可以用于临时监控 Redis 实例的操作情况，包括读写、删除等操作。

hotkey 的常见处理以及优化办法如下（这些方法可以配合起来使用）：

  • 读写分离：主节点处理写请求，从节点处理读请求。
  • 使用 Redis Cluster：将热点数据分散存储在多个 Redis 节点上。
  • 二级缓存：hotkey 采用二级缓存的方式进行处理，将 hotkey 存放一份到 JVM 本地内存中（可以用 Caffeine）。

慢查询

找到慢查询。在 redis.conf 文件中，我们可以使用 slowlog-log-slower-than 参数设置耗时命令的阈值，并使用 slowlog-max-len 参数设置耗时命令的最大记录条数。

当 Redis 服务器检测到执行时间超过 slowlog-log-slower-than阈值的命令时，就会将该命令记录在慢查询日志(slow log) 中，这点和 MySQL 记录慢查询语句类似。当慢查询日志超过设定的最大记录条数之后，Redis 会把最早的执行命令依次舍弃。

事务

redis由于单线程，事务支持隔离，redis事务没有回滚，不保证原子性。利用watch可以监听key变化，类似乐观锁的功能，有变化则退出。

Redis事务的三个阶段

  1. 事务开始 MULTI
  2. 命令入队
  3. 事务执行 EXEC

事务执行过程中，如果服务端收到有EXEC、DISCARD、WATCH、MULTI之外的请求，将会把请求放入队列中排队

Redis事务相关命令

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的

Redis会将一个事务中的所有命令序列化，然后按顺序执行。

  1. redis 不支持回滚，“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。
  2. 如果在一个事务中的命令出现错误，那么所有的命令都不会执行；指的是入队时发现错误。
  3. 如果在一个事务中出现运行错误，那么正确的命令会被执行。指的是入队后开始执行时发现错误。
  • WATCH 命令是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为。 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。
  • MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
  • EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。 当操作被打断时，返回空值 nil
  • 通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。
  • UNWATCH命令可以取消watch对所有key的监控。

Redis的事务总是具有ACID中的一致性和隔离性，其他特性是不支持的。当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，事务也具有耐久性。

Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

持久性需要aof一直同步刷盘才有效。

Redis事务支持隔离性吗？

Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。

Redis事务其他实现

  • 基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行， 其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完
  • 基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐

image-20210528141951754

为什么 Redis 不支持回滚（roll back）

如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。

以下是这种做法的优点：

  • Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
  • 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

分布式锁

单机分布式锁的正确实现

总结: set nx 超时特定时间，随机数. 释放锁时试用lua脚本，保证原子性，判断是否为加锁时的随机数。

在实现多机的分布式锁算法之前，需要一个可用的单机分布式锁。

实现还是主要基于 SET 的 NX 和超时要素，针对不验证就 DEL 的不安全问题，可以采用类似签名的方法，即在获取锁时对 Key 对应的 Value 设置一个随机值，释放锁的时候再进行验证。

签名的随机值从简单来说可以使用客户端 ID 加上时间戳，对可靠性要求高的话可以使用经过 RC4 算法生成的随机数流，种子使用 /dev/urandom 产生的随机值即可。

具体的释放锁脚本通过 Lua 编写，以脚本形式执行，由于单个 Redis 实例采用单个 Lua 解释器运行脚本，所以可以认为该脚本的执行过程是原子的：

if redis.call("get",KEYS[1]) == ARGV[1] then
	return redis.call("del",KEYS[1])
else
	return 0

由于需要保证锁的最终释放，还是需要对锁设置时间，SET 中超时的时间即为锁合法的时间，超过该时间锁就可以被其他的客户端获取。

Redlock 算法

什么是 RedLock

Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫 Redlock，此种方式比原先的单节点的方法更安全。它可以保证以下特性：

  1. 安全特性：互斥访问，即永远只有一个 client 能拿到锁
  2. 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
  3. 容错性：只要大部分 Redis 节点存活就可以正常提供服务

单机有个问题是redis会宕机，因此不安全。redlock通过多半实例成功才算成功解决以上问题。

Redlock 使用的 Redis 节点皆为 Master 节点，以 5 个节点为例子，具体的实现如下：

  1. 客户端获取当前的时间戳。
  2. 对 N 个 Redis 实例进行获取锁的操作，具体的操作同单机分布式锁。对 Redis 实例的操作时间需要远小于分布式锁的超时时间，这样可以保证在少数 Redis 节点 Down 掉的时候仍可快速对下一个节点进行操作。
  3. 客户端会记录所有实例返回加锁成功的时间，只有从多半的实例（在这里例子中 >= 3）获取到了锁，且操作的时间远小于分布式锁的超时时间，锁才被人为是正确获取。
  4. 如果锁被成功获取了，当前分布式锁的合法时间为初始设定的合法时间减去上锁所花的时间。
  5. 若分布式锁获取失败，会强制对所有实例进行锁释放的操作，即使这个实例上不存在相应的键值。

可以参考https://www.cnblogs.com/rgcLOVEyaya/p/RGC_LOVE_YAYA_1003days.html

实例下线和上线

redis-cli –cluster reshard 做了什么？

在 Redis Cluster 的 reshard（迁移 slot）过程中，读写请求仍然是允许的，但 Redis 做了很多机制设计来确保数据一致性、不中断访问。这是 Redis Cluster 能支持在线迁移的重要能力之一。

主要步骤如下：

确认迁移的 slot 数量和目标节点（接收者）

你告诉工具：更新 slot 的归属权。用来告知目标节点、源节点“你现在拥有/不再拥有 slot X”。

  • 几个 slot 要迁移（如 4096）
  • 要迁移到哪个节点（目标节点 node ID）
  • 从哪些源节点迁移（一个或多个）

按顺序选择 slot 并迁移

工具会按照 slot 范围，在源节点中选取每个要迁移的 slot，依次：

  1. 通知源节点迁移某个 slot
  2. 在源节点扫描该 slot 的所有 key
  3. 把这些 key 一个个迁移给目标节点
  4. 更新 slot 所属权到目标节点

实现

技术上，它通过 CLUSTER SETSLOT, MIGRATE 等命令完成操作。

CLUSTER SETSLOT

更新 slot 的归属权。用来告知目标节点、源节点“你现在拥有/不再拥有 slot X”。

MIGRATE 命令（核心）

把 key 从一个节点复制到另一个节点（目标节点），同时删除源节点的 key：

--cluster reshard 实际上是调用了 MIGRATE 来逐个搬 key。

注意：

  • 是 Redis 内部使用 TCP 连接，把 key/value 和 TTL 打包后发送过去；
  • MIGRATE 是阻塞的，单次支持最大 key 数限制（默认 10，实际批量）；
  • MIGRATE 在 Redis 内部使用 pipeline 和事务机制，保证 key 在源节点删除之前，已完整写入目标节点；
  • MIGRATE 自带重试和超时机制，失败不会强制终止，但不会完成 slot 迁移；
  • slot 迁移是逐个确认式的，有失败会打断流程；
  • Redis Cluster 会广播 slot 所属关系变化，客户端感知 slot 重定向（ASK 重定向响应）；
  • 重分片期间客户端请求会被重定向，不会导致数据丢失。

当客户端向旧的节点写入该 slot 的 key：

  • 源节点会响应 ASK 重定向，告诉客户端“你该去另一个节点了，但这次我会帮你转过去处理”。
  • 客户端需发送一次 ASKING 命令到目标节点后，再重新执行命令。客户端在 slot 迁移期间 不需要业务暂停写入，只要使用 Redis Cluster 兼容客户端（如 Jedis、lettuce、ioredis 等），都内置支持 ASK 重定向。

Search

    Table of Contents

    Popular Posts