redis 清空缓存_FreeRedis 实现：Redis 6.0 客户端缓存技术

文 | 叶老板(略有修改)

Redis 6.0 是一个可期的版本，增加了 RESP3.0 协议，ACL 权限控制，从原有的单线程改为多线程(性能提升2-3倍)等诸多更新。今天向大家介绍他的另一个重要特性：客户端缓存技术，讲解如何落设计在 .NET 中。

为什么需要客户端缓存？

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

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

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

如上图所示，Guava Cache 等进程缓存作为一级缓存，Redis 作为二级缓存：

• 先去 Guava Cache 中查询数据，如果命中则直接返回。
• Guava Cache 中未命中，则再去 Redis 中查询，如果命中则返回数据，并在 Guava Cache 中设置此数据。
• Redis 也未命中的话，只有去 MySQL 中查询，然后依次将数据设置到 Redis 和 Guava Cache 中。

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

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

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

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

落地分析

如上当 key 失效的时候，Redis 6.0 提供了三种模