追求性能极致：Redis 客户端缓存带来的革命
背景
2020 年 5 月份，Redis 官方推出了令人瞩目的 Redis 6.0，提出很多新特性，包括了客户端缓存 (Client side caching)、ACL、Threaded I/O 和 Redis Cluster Proxy 等诸多新特性。如下：
我们也专门对 Redis 6.0 的 Threaded I/O（多线程网络 I/O 模式）做了很详细的说明，有兴趣的翻到前面一篇。这一篇咱们就来聊下这个 Client side caching（客户端缓存），看看 Redis 为什么需要客户端缓存、是基于什么原理实现的，以及具体应该怎么使用。
1 为什么需要客户端缓存
1.1 缓存服务的目的
Redis 的读写操作都是在内存中实现了，相对其他的持久化存储（如 MySQL、File 等，数据持久化在磁盘上），性能会高很多。因为我们在操作数据的时候，需要通过 IO 操作先将数据读取到内存里，增加工作成本。
上面那张图来源于网络，可以看看他的金字塔模型，越往上执行效率越高，价格也就越贵。下面给出每一层的执行耗时对比：
寄存器：0.3 ns
L1 高速缓存：0.9 ns
L2 高速缓存：2.8 ns
L3 高速缓存：12.9 ns
主存：120 ns
本地二级存储（SSD）：50~150 us
远程二级存储：30 ms
我们举个 L1 和 SSD 的直观对比，如果 L1 耗时 1s 的话，SSD 中差不多要 15~45 小时，所以内存层面的访问效率远远比磁盘层面的访问效率高很多。
总之，缓存的目的是基于对持久化在磁盘的数据（比如 MySQL 数据、文件数据等）的高效访问，为了提升效率而实现的。《Redis in Action》中也提到， Redis 能够提升普通关系型数据库的 10 ~ 100 倍的性能。
数据访问过程如下图，Redis 存储了热点数据，当天我们请求一个数据时，先去访问缓存层，如果不存在再去访问数据库，这样可以解决大部分高效读取数据的业务场景，性能是缓存最重要的价值之一。
1.2 存在的问题
虽然我们使用 Redis 提升了数据的访问效率，但是依然存在一些问题。基于分布式访问的缓存服务是一个独立的服务存在，一般情况下访问它需要经过这几个步骤：
连接缓存服务（一般不会跟计算服务在一个实例上）
查找并读取数据（I/O 操作）
网络传输
数据序列化反序列化
这些操作一样的是对性能有影响的，随着互联网的发展，流量不断的膨胀，很容易达到 Redis 的性能上限。
所以，我们经常会使用进程缓存（本地缓存），来辅助处理，将一些高频读低频写的数据暂存在本地，读取数据的时候，先检查本地缓存是否存在，不存在再访问远端缓存服务的数据，进一步提高访问效率。
如果 Redis 也不存在，就只能去 数据库 中查询，查到的数据再设置到 Redis 和 本地缓存中，这样后续的请求就不用再走到数据库中了。
一般我们会使用 Memcachced、Guava Cache 等来做第一级别缓存（本地缓存），使用 Redis 作为第二级缓存（缓存服务），本地内存避免了 连接、查询、网络传输、序列化等操作，性能比缓存服务快很多，这种模式大大减少数据延迟。
2 客户端缓存实现原理
Redis 自己实现了一个客户端缓存，用以协助服务端 Redis 的操作，叫做tracking。我们可以通过命令来配置它：
客户端缓存最核心的问题就是当 Redis 中的缓存变更或者失效了之后，如果能够及时有效的通知到客户端缓存，来保证数据的一致性。Redis 6.0 实现 Tracking 功能，这个功能提供了两种方案来实现数据的一致性保证：
RESP2 协议版本的转发模式
RESP3 协议版本的普通模式和广播模式
接下来我们一个个来分析。
2.1 普通模式
Redis 使用 TrackingTable 来存储普通模式的客户端数据，它的数据类型是基数树 ( radix tree)。radix tree 是针对稀疏的长整型数据查找的多叉搜索树，能快速且节省空间的完映射，想深入了解的可以看这篇介绍。
如图中，客户端 ID 列表与 Redis 存储键的指针具有映射关系。而 Redis 键对象的指针对应的就是内存地址，数据结构是 Long。当开启了 track 功能之后，操作具有以下特性：
当 Redis 获取一个键值信息时，radix tree 会调用 enableTracking 方法记录 key 和 clientId 的映射关系，记录到 TrackingTable 中。
当 Redis 删除或者修改一个键值信息时 radix tree 根据 key 调用 trackingInvalidateKey 方法查找对应的 Clinet ID 调用 sendTrackingMessage 方法把失效的键值信息（invalidate 消息） 发送给这些 Clinet ID。发送完成之后从 TrackingTable 中删除映射关系。
Client 关闭 track 功能后，遇到大量删除操的时候，一般是懒删除，只将 CLIENT_TRACKING 标志位删除。
默认 track 模式是不开启，需要通过命令开启，参考如下：
2.2 广播模式(BCAST)
广播模式与普通模式类似，也是采用映射关系来对照，但实现过程还是有区别的：
存储的内容不一样：如图，采用 Prefix Table 来存储客户端数据，存储的是 前缀字符串指针 和 客户端数据（客户端 ID 列表 + 需通知的 key 值列表） 的映射关系。
删除键值的时机不一样：radix tree 根据 key 调用 trackingInvalidateKey 方法查找 PrefixTable。判断是否为空，不为空则 调用 trackingRememberKeyToBroadcast 对键列表进行进行遍历，找到符合前缀匹配规则的，并记录位置。在事件处理周期函数 beforeSleep 中 调用 trackingBroadcastInvalidationMessages 函数来发送消息。发送完成之后从 PrefixTable 中删除映射关系。
2.3 转发模式
RESP 3 协议 是 Redis 6.0 新启用的协议，使用普通模式或者广播模式需要依赖这种协议，这样对于 RESP 2 协议的客户端来说就会有问题。所以衍生除了另一种模式：重定向（redirect）。
RESP 2 无法直接 PUSH 失效消息，所以不能直接获取到失效数据（Redis Client 2）。
支持 RESP 3 协议的客户端（Redis Clinet 1） 告诉 Server 将失效消息通过 Pus/Sub 通知给 RESP 2 客户端。
而 Redis Client 2 （RESP 2 ）是通过订阅命令 SUBSCRIBE，专门订阅用于发送失效消息的频道 redis:invalidate。
如下所示：
3 总结
3.1 默认模式（普通模式）
服务端记录客户端操作过的 key，key 对应的值发生变化时，会发送 Invalidation Messages 给 Redis 客户端。
服务端记录 key 信息会消耗一些内存，但是发送失效消息的范围，限制在存储的 key 范围内，计算和网络传输变的轻量。
优点是节省 CPU 以及流量带宽，但是会占用一些内存。
3.2 广播模式
服务端不记录 key，而是订阅 key 的特定前缀，当匹配前缀的 key 的值改变时，发送 Invalidation Messages 给 Redis 客户端。
优点是服务端的内存消耗少，但是会损耗更多的 CPU 去做前缀匹配的计算。
3.3 转发模式
为了兼容 resp2 协议的一种过渡模式
优点是占用内存少，CPU 占用多
客户端的缓存
客户端缓存，需要业务侧自己实现，Redis 服务端只负责通知你 key 的变动（删除、新增）。
如果感觉本文对你有帮助，点赞关注支持一下，想要了解更多 Java 后端，大数据，算法领域最新资讯可以关注我公众号【架构师老毕】私信 666 还可获取更多 Java 后端，大数据，算法 PDF+大厂最新面试题整理+视频精讲
领取资料添加小助理vx：bjmsb2020 2020-12-19 加入
Java领域;架构知识;面试心得;互联网行业最新资讯
评论