码老湿，上次你解说了 Redis 多线程模型，这次我想晓得客户端缓存（Client side caching）技术，他的英文名叫：Redis server-assisted client side caching，能够说说么？
我不是嫖客，看完我会点赞、再看、分享的。

别装逼了，还整英文，咋不入地，做人要说话算数哟，不然中午尿裤子。在说这个之前，码哥先给读者送一段寄语作为开篇。

开篇寄语

不要悭吝你的赞美，如果他人做的很好，就给他正反馈，这也是一种利他。

另外，少关注用「赞美」投票的事物，而多关注用「交易」投票的事物。

判断一个人是否牛逼，不是看网上有多少人赞美他，而是看有多少人违心跟他产生交易、赞叹、领取、下单。

因为赞美太便宜，而违心与他产生交易，才是真正的信赖。

为啥须要客户端缓存

Redis 的Tracking Feature 的实现代码在: https://github.com/antirez/redis/blob/unstable/src/tracking.c。

很多公司应用 Redis 做缓存零碎，并且很好的进步了数据拜访的性能，为了进一步应答热点数据，还是会在 Redis 的 Client 端缓存一部分热点数据，用来应答「吃瓜事件」。

比方，「这该死的 996 福报」、「吴亦凡之慷慨牢房」、「工夫治理巨匠」、「思聪舔我不得就锤我」、「吴秀波之谈恋爱么，能坐牢的那种」……

除了应用 Redis 缓存防止间接拜访数据库以外，还会加更多的 cache 层，比方采纳 Memcachced 作为热点数据的本地缓存：

1. 先去 Memcachced 中查问数据，命中间接返回。
2. Memcachced 未命中，则再从 Redis 查问，命中则返回数据，并在 Memcachced 保留这个数据。
3. Redis 未命中，则去 MySQL中查问，并顺次设置到 Redis 和 Memcachced中。

拜访本地内存的的性能必然比通过网络拜访 Redis 快，所以这种模式能够极大地缩小获取数据的提早，并且能够缩小 Redis 的负载，进步性能。

1. 拜访 Redis 获取数据，服务器响应。

2. 应用客户端缓存，应用程序将获取的热门的数据存储在用用程序中，无需再次通过网络拜访 Redis。

应该缓存什么

• 咱们不应该缓存一直变动的键。
• 咱们不该缓存很少申请的键。
• 咱们心愿缓存常常申请并以正当速率更改的键。对于没有稳固变动速度的例子，比方一直被 INCR 批改的全局计数器，就不应该缓存。

客户端缓存实现原理

码老湿，Redis 中的数据批改或者生效了，如何及时同步告知客户端生效了呢？本人实现也太简单了。

Redis 实现的是一个服务端帮助的客户端缓存，叫做tracking。客户端缓存的命令是:

CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN] [OPTOUT] [NOLOOP]

Redis 6.0 实现 Tracking 性能提供了两种模式解决这个问题，别离是应用 RESP3 协定版本的 一般模式和播送模式 ，以及应用 RESP2 协定版本的转发 模式。

*

一般模式

当 tracking 开启时，Redis 会「记住」每个客户端申请的 key，当 key 的值发现变动时会发送生效信息给客户端 (invalidation message)。

生效信息能够通过 RESP3 协定发送给申请的客户端，或者转发给一个不同的连贯 (反对 RESP2 + Pub/Sub) 的客户端。

• Server 端将 Client 拜访的 key 以及该 key 对应的客户端 ID 列表信息存储在全局惟一的表（TrackingTable），当表满了，回移除最老的记录，同时触发该记录已过期的告诉给客户端。
• 每个 Redis 客户端又有一个惟一的数字 ID，TrackingTable 存储着每一个 Client ID，当连贯断开后，革除该 ID 对应的记录。
• TrackingTable 表 中记录的 Key 信息不思考是哪个 database 的，尽管拜访的是 db1 的 key，db2 同名 key 批改时会客户端收到过期提醒，但这样做会缩小零碎的复杂性，以及表的存储数据量。

码老湿，能够说下这个 TrackingTable 原理么？

Redis 服务端应用 TrackingTable 存储一般模式的客户端数据，它的数据类型是基数树 (radix tree)。

基数树是针对稠密的长整型数据查找的多叉搜寻树，能疾速且节俭空间的完映射。

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

留神

服务端对于记录的 key 只会报告一次 invalidate 音讯，也就是说，服务端在给客户端发送过一次 invalidate 音讯后，如果 key 再被批改，此时，服务端就不会再次给客户端发送 invalidate 音讯。

只有下次客户端再次执行只读命令被 track，才会进行下一次音讯告诉。

客户端默认不开启 track 模式，咱们须要在获取执行指令之前执行开启命令：

CLIENT TRACKING ON|OFF
+OK
GET user:211
$3
公众号: 码哥字节

播送模式(BCAST)

当播送模式 (broadcasting) 开启时，服务器不会记住给定客户端拜访了哪些键，因而这种模式在服务器端基本不耗费任何内存。

在这个模式下，服务端会给客户端播送所有 key 的生效状况，如果 key 被频繁批改，服务端会发送大量的生效播送音讯，这就会耗费大量的网络带宽资源。

所以，在理论利用中，咱们设置让客户端注册只跟踪指定前缀的 key，当注册跟踪的 key 前缀匹配被批改，服务端就会把生效音讯播送给所有关注这个 key 前缀的客户端。

client tracking on bcast prefix user

这种监测带有前缀的 key 的播送模式，和咱们对 key 的命名标准十分匹配。咱们在理论利用时，会给同一业务下的 key 设置雷同的业务名前缀，所以，咱们就能够十分不便地应用播送模式。

播送模式与一般模式相似，Redis 应用 PrefixTable 存储播送模式下的客户端数据，它存储 前缀字符串指针和 (须要告诉的 key 和客户端 ID) 的映射关系。

转发模式

一般模式与播送模式，须要客户端应用 RESP 3 协定，他是 Redis 6.0 新启用的协定。

对于应用 RESP 2 协定的客户端来说，实现客户端缓存则须要另一种模式：重定向模式（redirect）。

RESP 2 无奈间接 PUSH 生效音讯，所以 须要另一个反对 RESP 3 协定的客户端 通知 Server 将生效音讯通过 Pus/Sub 告诉给 RESP 2 客户端。

在重定向模式下，想要取得生效音讯告诉的客户端，就须要执行订阅命令 SUBSCRIBE，专门订阅用于发送生效音讯的频道 _redis_:invalidate。

同时，再应用另外一个客户端，执行 CLIENT TRACKING 命令，设置服务端将生效音讯转发给应用 RESP 2 协定的客户端。

假如客户端 B 想要获取生效音讯，然而客户端 B 只反对 RESP 2 协定，客户端 A 反对 RESP 3 协定。咱们能够别离在客户端 B 和 A 上执行 SUBSCRIBE 和 CLIENT TRACKING，如下所示：

// 客户端 B 执行，客户端 B 的 ID 号是 606
SUBSCRIBE _redis_:invalidate

// 客户端 A 执行
CLIENT TRACKING ON BCAST REDIRECT 606

B 客户端就能够通过 _redis_:invalidate 频道获取生效音讯了。

热门举荐

Redis 新个性篇：多线程模型解读

Redis 实战篇：通过 Geo 类型实现左近的人邂逅女神

Redis 面霸篇：从高频问题透视外围原理