用Redis来搞Guava缓存那些数据结构，感觉像在模拟Guava的功能一样

好，我们来直接聊聊用Redis来模拟Guava缓存这回事儿，这事儿听起来有点像是用一台挖掘机去开一个啤酒瓶盖，不是说完全不行，而是你得琢磨一下，是不是真的有必要,以及怎么操作才不至于把瓶盖给撬飞了。

首先得明白Guava缓存是个啥玩意儿，根据一些开发者的讨论，比如在知乎上能看到的相关话题，Guava Cache是Google的Guava库提供的一个本地缓存工具，它的主要特点就是简单、轻量，跟你应用程序跑在同一个进程里，你把它想象成你电脑桌面上一个特别顺手的小记事本，随手记点东西，查起来飞快，而且可以设置一些规则，比如某个笔记超过一天没看就自动扔掉，或者只保留最近常用的10条笔记，它核心的功能就是缓存过期策略（比如按时间过期、按访问次数刷新）、缓存淘汰策略（比如内存不够了踢掉一些不常用的）、以及加载缓存的机制（当缓存里没有你要的东西时，它能自动调用你预设的方法去数据库查，然后塞进缓存再返回给你）。

那Redis呢？它是一个独立的内存数据存储，通常得单独启动一个服务，你的程序通过网络跟它打交道，它功能强大，能存各种数据结构，持久化，还能搞集群，简单说，它像个专业的、超大的中央文件柜，所有应用程序都能来存取，数据能长期保存,容量也大得多。

为什么会有人想用Redis去“模拟”Guava的功能呢？根据一些技术博客和社区讨论，常见的原因有几个： 第一，分布式需求，如果你的应用不是单机运行，而是有好几个实例（比如用Docker拉了多个容器），你用Guava缓存，每个实例都有自己的小记事本，这下麻烦了，实例A更新了数据，它的记事本改了，但实例B和C的记事本还是老黄历，数据就不一致了，这时候，大家就需要一个共用的“中央文件柜”，也就是Redis，来保证所有实例看到的缓存数据是一样的。 第二，缓存数据需要持久化或共享，Guava缓存是进程内的，程序一重启，缓存就全没了，而Redis可以把数据存在磁盘上，重启后还能加载回来，或者，可能有两个完全不同的应用系统，都需要用到同一份缓存数据，那放在Redis里共享是最合适的。 第三，缓存容量巨大，Guava缓存再怎么说也受限于单机内存，而Redis可以搭建集群,理论上容量可以非常大。

想法是好的，但真动手用Redis去模仿Guava那些细碎的功能，你就会发现像是在用螺丝刀当筷子使，处处不得劲,我们来一项项看：

过期和淘汰策略的“模拟” Guava的过期策略非常细腻，可以分访问后过期、写入后过期，还能搞个定时刷新，Redis本身也支持过期时间（TTL），但它是针对单个key设置的，而且过期机制相对简单，主要是设置一个绝对过期时间，你想实现“超过10分钟没被访问就失效”这种效果，在Redis里就需要动点脑筋了，一个常见的土办法是：每次读取缓存时，都顺手把这个key的过期时间重新设置为10分钟后，但这需要客户端在每次读操作时都额外执行一个EXPIRE命令，很麻烦，而且不是原子操作，容易出岔子，虽然可以用Lua脚本保证原子性，但复杂度一下就上来了，而Guava这个功能是内置的、自动的,你完全无感。

至于淘汰策略，Guava有基于容量的LRU（最近最少使用）等，Redis也内置了好几种淘汰策略（如allkeys-lru, volatile-lru等），当内存不足时会自动触发，在这方面，Redis本身的能力甚至更强更全局，但问题在于，Guava的淘汰是发生在你的应用进程内部的，你可以监听被移除的缓存项，做一些善后工作（Guava的RemovalListener），在Redis里，一个key因为内存满了被LRU掉，你的应用程序是不知道的，除非你去监听一些特定的Redis事件,但那又是非常重的操作了。

加载缓存机制的“模拟”（CacheLoader） 这是Guava的一个王牌功能，也叫“读穿透”缓存，你调用cache.get(key)，如果缓存没有，Guava会自动调用你实现的CacheLoader里的load方法去数据库查，查到后放入缓存，最后返回给你，整个过程对调用方是透明的，一句if (cache.contains(key)) ... else ...都不用写。

用Redis来搞这个，可就费老劲了，Redis本身没这功能，你得在客户端代码里自己手动实现这个逻辑,伪代码大概是：

value = redis.get(key)
if (value == null) {
    value = database.load(key) // 去数据库查
    if (value != null) {
        redis.set(key, value, TTL) // 塞回Redis
    }
}

这看起来不难，但在高并发环境下，这会引出经典的缓存击穿问题：如果某个热点key刚好过期，瞬间有大量请求同时发现缓存为空，然后全都冲到数据库去查，数据库可能就扛不住了，Guava的CacheLoader在设计上能很好地规避这个问题，因为它能保证对同一个key，即使很多线程同时get，也只有一个线程会真的去执行load方法，其他线程会等待结果，而在Redis这边，要实现同样的“单线程加载”效果，你就得用Redis的分布式锁（比如SETNX命令）来包装上面那段逻辑，代码复杂度指数级上升,而且稍有不慎就会出bug或者性能瓶颈。

性能和复杂度的权衡 这是最核心的一点，Guava缓存是本地内存访问，速度是纳秒级或微秒级的，快得飞起，而Redis虽然也快，但毕竟是网络IO，一次简单的读取可能就要毫秒级，延迟高出几个数量级，你用Redis模拟Guava，相当于放弃了本地缓存最大的速度优势。 你的代码从原来简单调用Guava API，变成了要写一大堆处理Redis连接、序列化/反序列化、以及上面提到的各种策略模拟的胶水代码，虽然可以用Spring Cache这类框架来简化，配置一个Redis版的CacheManager，但其底层依然无法完美复刻Guava的所有语义,你可能需要写很多自定义代码来填补功能缺口。

结论是什么呢？根据很多工程师的经验分享，更常见的、理性的做法不是“用Redis模拟Guava”，而是分层缓存，也就是“Guava + Redis”一起用，把最热点的、每个实例自己独享的数据放在Guava里（一级缓存），速度极致快；把共享的、需要一致性的、或者更大的数据放在Redis里（二级缓存），这样既享受了本地缓存的速度，又拥有了分布式缓存的共享能力，这带来了数据一致性的新挑战（如何及时通知各个实例清除本地过期的缓存）,但这是另一个需要权衡和解决的话题了。

用Redis去硬搞Guada的功能，有点像是为了喝一杯牛奶而养了一头奶牛，不是绝对不行，但成本和收益需要你仔细掂量，大多数情况下，可能有更优雅、更合适的解决方案。