Redis 6.0更新放大招：客户端缓存怎么用好

时间  2020-05-29
标签 redis 6.0 更新 放大 客户端 缓存 怎么 用好 栏目 Redis 繁體版
原文   原文链接

近日 Redis 6.0.0 GA 版本发布，这是 Redis 历史上最大的一次版本更新，包括了客户端缓存 (Client side caching)、ACL、Threaded I/O 和 Redis Cluster Proxy 等诸多更新。redis

咱们今天就依次聊一下客户端缓存的必要性、具体使用、原理分析和实现。数据库

为何须要客户端缓存centos

咱们都知道，使用 Redis 进行数据的缓存主要目的是减小对 MySQL 等数据库的访问，提供更快的访问速度，毕竟 《Redis in Action》中提到的， Redis 的性能大体是普通关系型数据库的 10 ~ 100 倍。缓存

因此，以下图所示，Redis 用来存储热点数据，Redis 未命中，再去访问数据库，这样能够应付大多数状况下的性能要求。bash

image

可是，Redis 也有其性能上限，而且访问 Redis 必然有必定的网络 I/O 以及序列化反序列化损耗。因此，每每会引入进程缓存，将最热的数据存储在本地，进一步加快访问速度。服务器

image

如上图所示(示意图，细节没必要过分在乎，下同)，Guava Cache 等进程缓存做为一级缓存，Redis 做为二级缓存：网络

  • 先去 Guava Cache 中查询数据，若是命中则直接返回。分布式

  • Guava Cache 中未命中，则再去 Redis 中查询，若是命中则返回数据，并在 Guava Cache 中设置此数据。ide

  • Redis 也未命中的话，只有去 MySQL 中查询，而后依次将数据设置到 Redis 和 Guava Cache 中。函数

只使用 Redis 分布式缓存时，遇到数据更新时，应用程序更新完 MySQL 中的数据，能够直接将 Redis 中对应缓存失效掉，保持数据的一致性。

而进程内缓存的数据一致性比分布式的缓存面临更大的挑战。数据更新的时候，如何通知其余进程也更新本身的缓存呢?

若是按照分布式缓存的思路，咱们能够设置极短的缓存失效时间，这样没必要实现复杂的通知机制。

可是不一样进程内的数据依然会面临不一致的问题，而且不一样进程缓存失效时间不统一，同一个请求到了不一样的进程，可能出现反复幻读的状况。

image

Ben 在 RedisConf18 给出了一个方案(视频和 PPT 连接在文末)，经过 Redis 的 Pub/Sub，能够通知其余进程缓存对此缓存进行删除。若是 Redis 挂了或者订阅机制不靠谱，依靠超时设定，依然能够作兜底处理。

Antirez(Redis 的做者)也正是听取 Ben 这个方案后，才决定在 Redis Server 支持客户端缓存的，由于在有服务端参与的状况下能够更好的处理上述这些问题。

功能介绍和演示

下面使用 Docker 安装 Redis 6.0.1，而后使用 telnet 来简单演示一下 Redis 6.0 的客户端缓存功能。全部相关的功能以下图所示，分别是使用RESP3 协议版本的普通模式和广播模式，以及使用 RESP2 协议版本的转发模式。咱们先来看普通模式。

image

普通模式

先使用 redis-cli 设置缓存值 test=111，使用 telnet 链接上 Redis，而后发送 hello 3 开启 RESP3 协议。

1.  `[root@VM_0_3_centos ~]# telnet 127.0.0.1 6379`

2.  `Trying  127.0.0.1...`

3.  `Connected to 127.0.0.1.`

4.  `Escape character is  '^]'.`

5.  `hello 3`

6.  `// telnet 输出结果格式化标准化后以下，不然换行太多而且是 RESP3 格式，不须要了解格式。`

7.  `> HELLO 3`

8.  `1# "server" => "redis"`

9.  `2# "version" => "6.0.1"`

10.  `3# "proto" => (integer) 3`

11.  `4# "id" => (integer) 10`

12.  `5# "mode" => "standalone"`

13.  `6# "role" => "master"`

14.  `7# "modules" => (empty array)`
复制代码

这里须要注意，Redis 服务端只会 track 客户端在一个链接生命周期内的获取的只读命令的 key值。Redis 客户端默认不开启 track 模式，须要使用命令开启，而后必需要先获取一次 test 的值，这样 Redis 服务器才会记录它。

1.  `client tracking on`

2.  `+OK`

3.  `get test`

4.  `$3`

5.  `111`
复制代码

**当键被修改，或者由于失效时间(expire time)和内存上限 maxmemory 策略被驱除时，Redis 服务端会通知这些客户端。**咱们这里简单地更新 test 的值，telnet 则会收到以下通知：

1.  `>2  // RESP3 中的 PUSH 类型，标志为 > 符号`

2.  `$10`

3.  `invalidate`

4.  `*1`

5.  `$4`

6.  `test`
复制代码

若是你再一次更新 test 值，此次 telnet 就不会再收到失效(invalidate)消息。除非 telnet 再进行一次 get 操做，从新 tracking 对应的键值。

也就是说 Redis 服务端记录的客户端 track 信息只生效一次，发送过失效消息后就会删除，只有下次客户端再次执行只读命令被 track，才会进行下一次消息通知 。

取消 tracking 的命令以下所示：

1.  `client tracking off`

2.  `+OK`
复制代码

广播模式

Redis 还提供了一种广播模式(BCAST)，它是另一种客户端缓存的实现方式。这种方式下Redis 服务端再也不消耗过多内存存储信息，而是发送更多的失效消息给客户端。

这是服务端存储过多数据，消耗内存和客户端收到过多消息，消耗网络带宽之间的权衡(tradeoff)。

1.  `// 已经 hello 3 开启 RESP3 协议，否则没法收到失效消息，下同`

2.  `client tracking on bcast`

3.  `+OK`

4.  `// 此时设置 key 为 a 的键值，收到以下消息。`

5.  `>2`

6.  `$10`

7.  `invalidate`

8.  `*1`

9.  `$1`

10.  `a`
复制代码

若是你不想全部的键值的失效消息都收到，则能够限制 key 的前缀，以下命令则表示只关注前缀为 test 的键值的消息。通常来讲，业务的缓存 key 都是根据业务拥有统一的前缀，因此这一特性十分方便。

1.  `client tracking on bcast prefix test`
复制代码

与普通模式必须获取一次键的规则不一样，广播模式下，只要键被修改或删除，符合规则的客户端都会收到失效消息，并且是能够屡次获取的。

与普通模式相比，虽然少存储了一些数据，可是因为须要对前缀规则进行匹配，会消耗必定的 CPU 资源，因此注意别使用过长的前缀。

转发模式

上述操做时客户端都须要先开启 RESP3，Redis 为了兼容 RESP2 协议提供了转发(Redirect)模式，再也不使用 RESP3 原生支持 PUSH 消息，而是将消息经过 Pub/Sub 通知给另一个客户端，具体流程以下图所示：

image

这里须要两个 telnet，其中一个 telnet 须要订阅 redis:invalidate 信道。而后另外一个 telnet 开启 Redirect 模式，并制定将失效消息经过订阅信道发送给第一个 telnet。

1.  `# telent B`

2.  `client id`

3.  `:368`

4.  `subscribe _redis_:invalidate`

6.  `# telnet A，开启 track 并指定转发给 B`

7.  `client tracking on bcast redirect 368`

9.  `# telent B 此时有键值被修改，收到 __redis__:invalidate 信道的消息`

10.  `message`

11.  `$20`

12.  `__redis__:invalidate`

13.  `*1`

14.  `$1`

15.  `a`

复制代码

你会发现，转发模式和文章开始提到的多级缓存中的更新机制很相似了，只不过那个方案中是业务系统修改完 key 后发送消息通知，而这里是 Redis 服务端代替业务系统发送消息通知。

OPTIN和OPTOUT选项

使用 OPTIN 能够选择性的开启 tracking。只有你发送 client caching yes (Redis 文档中是 CACHING 命令，可是实验时发现无效)以后的下一条的只读命令的 key 才会 tracking，不然其余的只读命令的 key 不会被 tracking。

1.  `client tracking on optin`

2.  `client caching yes`

3.  `get a`

4.  `get b`

5.  `// 此时修改 a 和 b 的值，发现只收到 a 的失效消息`

6.  `>2`

7.  `$10`

8.  `invalidate`

9.  `*1`

10.  `$1`

11.  `a`
复制代码

而 OPTOUT 参数与之相反，你能够有选择的退出 tracking。发送 client caching off 以后的下一条只读命令的 key 不会被 tracking，其余只读命令都会被 tracking。

OPTIN 和 OPTOUT 是针对非 BCAST 模式，也就是只有发送了某个 key 的只读命令后，才会追踪相应的 key。而 BCAST 模式是不管你是否发送某个 key 的只读命令，只有 Redis 修改了 key，都会发送相应的 key 的失效消息(前缀匹配的)。

NOLOOP选项

默认状况下，失效消息会发送给全部须要的 Redis 客户端，可是有些状况下触发失效消息也就是更新 key 的客户端不须要收到该消息。

设置 NOLOOP，能够避免这种状况，更新 Key 的客户端将再也不收到消息，该选项在普通模式和广播模式下都适用。

trackingtablemax_keys

最大 tracking 上限 trackingtablemax_keys。

由上文能够知道，普通模式下须要存储大量的被 tracking 的 key 和客户端信息(具体存储的数据下文中会讲解)，因此当 10k 客户端使用该模式处理百万个键时，会消耗大量的内存空间，因此 Redis 引入了 trackingtablemax_keys 配置，默认为无，不限制。

当有一个新的键被 tracking 时，若是当前 tracking 的 key 的数量大于 trackingtablemax_keys，则会随机删除以前 tracking 的 key，而且向对应的客户端发送失效消息。

原理和源码实现普通模式原理

咱们也先讲解普通模式的原理，Redis 服务端使用 TrackingTable 存储普通模式的客户端数据，它的数据类型是基数树(radix tree)。

基数树是针对稀疏的长整型数据查找的多叉搜索树，能快速且节省空间的完映射，通常用于解决 Hash冲突和 Hash表大小的设计问题，Linux 的内存管理就使用了它。

image

Redis 用它存储键的指针和客户端 ID 的映射关系。由于键对象的指针就是内存地址，也就是长整型数据。客户端缓存的相关操做就是对该数据的增删改查：

  • 当开启 track 功能的客户端获取某一个键值时，Redis 会调用 enableTracking 方法使用基数树记录下该 key 和 clientId 的映射关系。

  • 当某一个 key 被修改或删除时，Redis 会调用 trackingInvalidateKey 方法根据 key 从 TrackingTable 中查找全部对应的客户端ID，而后调用 sendTrackingMessage 方法发送失效消息给这些客户端(会检查 CLIENT_TRACKING 相关标志位是否开启和是否开启了 NOLOOP)。

  • 发送完失效消息后，根据键的指针值将映射关系从 TrackingTable中删除。

  • 客户端关闭 track 功能后，由于删除须要进行大量操做，因此 Redis 使用懒删除方式，只是将该客户端的 CLIENT_TRACKING 相关标志位删除掉。

广播模式原理

image

广播模式与普通模式相似，Redis 一样使用 PrefixTable 存储广播模式下的客户端数据，它存储前缀字符串指针和(须要通知的key和客户端ID)的映射关系。它和广播模式最大的区别就是真正发送失效消息的时机不一样：

  • 当客户端开启广播模式时，会在 PrefixTable的前缀对应的客户端列表中加入该客户端ID。

  • 当某一个 key 被修改或删除时，Redis 会调用 trackingInvalidateKey 方法， trackingInvalidateKey 方法中若是发现 PrefixTable 不为空，则调用 trackingRememberKeyToBroadcast 依次遍历全部前缀，若是key 符合前缀规则，则记录到 PrefixTable 对应的位置。

  • 在 Redis 的事件处理周期函数 beforeSleep 函数里会调用 trackingBroadcastInvalidationMessages 函数来真正发送消息。

处理最大tracking上限

Redis 会在每次执行过命令后(processCommand方法)调用 trackingLimitUsedSlots 来判断是否须要进行清理：

  • 判断 TrackingTable 中键的数量是否大于 trackingtablemax_keys；

  • 在必定时间段内(不能太长，阻塞主流程)，随机从 TrackingTable 中选出一个键删除，直到数量小于或者时间用完为止。

具体源码

关于源码，在 tracking.c 文件下，咱们这里只看一下最为关键的 trackingInvalidateKey 函数和 sendTrackingMessage 函数，理解了这两个函数，广播模式和处理最大 tracking 上限等相关函数都与之相似。

1.  `void trackingInvalidateKey(client *c, robj *keyobj)  {`

2.  `if  (TrackingTable  == NULL)  return;`

3.  `sds sdskey = keyobj->ptr;`

4.  `// 省略，若是广播模式的记录基数树不为空，则先处理广播模式`

5.  `// 1 根据键的指针去 TrackingTable 查找`

6.  `rax *ids = raxFind(TrackingTable,(unsigned  char*)sdskey,sdslen(sdskey));`

7.  `if  (ids == raxNotFound)  return;`

8.  `// 2 使用迭代器遍历`

9.  `raxIterator ri;raxStart(&ri,ids);raxSeek(&ri,"^",NULL,0);`

10.  `while(raxNext(&ri))  {`

11.  `// 3 根据 clientId 查找 client 实例`

12.  `client *target = lookupClientByID(id);`

13.  `// 4 若是未开启 track 或者是广播模式则跳过。`

14.  `if  (target == NULL ||`

15.  `!(target->flags & CLIENT_TRACKING)||`

16.  `target->flags & CLIENT_TRACKING_BCAST)`

17.  `{  continue;  }`

18.  `// 5 若是开启了 NOLOOP 而且是致使key发生变化的client则跳过。`

19.  `if  (target->flags & CLIENT_TRACKING_NOLOOP &&`

20.  `target == c)`

21.  `{  continue;  }`

22.  `// 6 发送失效消息`

23.  `sendTrackingMessage(target,sdskey,sdslen(sdskey),0);`

24.  `}`

25.  `// 7 减小数据统计，根据sdskey删除对应的记录`

26.  `TrackingTableTotalItems  -= raxSize(ids);`

27.  `raxFree(ids);`

28.  `raxRemove(TrackingTable,(unsigned  char*)sdskey,sdslen(sdskey),NULL);`

29.  `}`
复制代码

源码如上所示，trackingInvalidateKey 方法主要作了 7 件事情：

  • 根据键的指针去 TrackingTable 查找客户端ID列表；

  • 使用迭代器遍历列表；

  • 根据 clientId 查找 client 实例；

  • 若是 client 实例未开启 track 或者是广播模式则跳过；

  • 若是 client 实例开启了 NOLOOP 而且是致使key发生变化的client则跳过；

  • 调用 sendTrackingMessage 方法发送失效消息；

  • 减小数据统计，根据sdskey删除对应的记录

下面来看真正发送消息的 sendTrackingMessage 函数，它主要作了6件事：

  • 若是 clienttrackingredirection 不为空，则开启了转发模式；

  • 找到转发的客户端实例；

  • 若是转发客户端关闭了，则必须通知原客户端；

  • 若是是客户端使用 RESP3 则发 PUSH 消息；

  • 若是是转发模式，往 TrackingChannelName 也就是 redis:invalidate 信道中发送失效消息的头部信息；

  • 发送键等信息。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程