Redis 客户端缓存

目录

Redis 客户端缓存

Abstract

之前存在问题

How

三种缓存模式：

Demo

默认模式

广播模式

转发模式（不要使用）

---

Abstract

这是redis6.0 的新特性

Redis 有其性能上限，并且访问 Redis 必然有一定的网络 I/O 以及序列化反序列化损耗。所以，往往会引入本地缓存，将最热的数据存储在本地，进一步加快访问速度。

客户端缓存是一种用于创建高性能服务的技术。它利用应用服务器(与数据库节点相比，应用服务器通常是不同的计算机)中的可用内存，以便将数据库信息的某些子集直接存储在应用程序端。

《Client side caching in Redis 6》中提到redis 接下来的一个重点是配合客户端，因为客户端缓存显而易见的可以减轻 redis 的压力，速度也快很多。大公司或多或少都有实现这种应用端缓存的机制，antirez 想通过 server 端的一些设计来减少客户端缓存实现的复杂度和成本，甚至不惜在 redis 协议上做修改。

之前存在问题

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

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

如果按照分布式缓存的思路，我们可以设置极短的缓存失效时间，这样不必实现复杂的通知机制。

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

How

Ben 在 RedisConf18 给出了一个方案(视频和 PPT 链接在文末)，通过 Redis 的 Pub/Sub，可以通知其他进程缓存对此缓存进行删除。如果 Redis 挂了或者订阅机制不靠谱，依靠超时设定，依然可以做兜底处理。

Antirez(Redis 的作者) 也正是听取 Ben 这个方案后，才决定在 Redis Server 支持客户端缓存的，因为在有服务端参与的情况下可以更好的处理上述这些问题。

三种缓存模式：

在客户端缓存，redis 本身不提供在应用服务端缓存数据的功能，这个功能要由访问 redis 的业务端自己去实现。也就是说，redis 服务端只负责通知你，你缓存在应用服务本地的这个 key 已经作废了，至于你本地如何缓存的这些数据，redis 并不关心，也不可能去关心。

Demo

默认模式

前提：redis 6.x 版本+开启 RESP3 协议+开启 tracking 机制

1. 客户端 A 采用 telnet 模式连接上 redis，命令：telnet 127.0.0.1 6379

2. 开启 resp3 协议，命令：hello 3

3. 开启 tracking 机制，命令：client tracking on

4. 接下来，我们在客户端 A 中先执行 get key1，然后在客户端 B 中执行 set key1 newval，然后我们发现客户端 A 中收到了作废信息

广播模式

前提：redis 6.x 版本+开启 RESP3 协议+开启 tracking 机制

接下来，我们在客户端 B 中执行 set 任意 key 的值，然后我们发现客户端 A 中均能收到作废信息

转发模式（不要使用）

前提：redis 6.x 版本+开启 tracking 机制

1. 客户端 A 采用 telnet 模式连接上 redis，并订阅_redis_:invalidate 事件，命令：telnet 127.0.0.1 6379，subscribe _redis_:invalidate

2. 客户 B 上开启转发模式，命令：client tracking on bcast redirect 49

 

3. 这时候我们发现，在其它客户端修改的消息均能出现在客户端 A