使用内存做关键信息的缓存来提升 QPS和减少开销

背景

当前业务需要使用 授权的 调用第三方系统获取用户资料。这里简化说明完成和第三方系统的对接需要两个接口。

通过 获取 。 2 小时过期，接口有 限制。

使用 获取用户信息，这个 是通用的，只要是当前 下面的用户都可以使用。

设计

考虑到有 限制问题，所以一定要有缓存机制，不然获取用户信息的接口请求量大的时候 就不够用。

有两个小时过期问题，所有缓存要有失效机制。

一个 有且只有一个 ，并且不常变，可以考虑直接使用内存缓存。如果使用 Redis等分布式缓存系统，也会因为频繁网络请求。

下面的表格来源于 Jeff Dean的一个PPT，里面罗列了不同级别的IO时间，这正是我们评估如何设计系统的必要因素。

由上面表格，我们可以清楚的看出从网络上面获取1M数据和从内存中读取1M数据的差别。为什么说到这里呢，因为随着我们的用户的增加，集群的扩展，很少的情况下是把缓存数据库或者其他缓存中间件和应用程序放在一台服务器上，大部分情况都是分布式的应用系统和缓存系统，所以避免不了的我们需要考虑网络而的开销。

回到当前话题，对于一个 占用内存足够小，即便是分布式系统每一个系统中都存储一个也不为过，只是能解决过期更新问题就好了。

实现

正好 就提供了这个功能， 缓存类似于 ，但不完全相同。 最根本的区别是， 会持续添加到其中的所有元素，如果你不手动删除它们会一直存在。然而 可以通过缓存的大小，过期时间，或者其他策略自动地移除元素，来限制其内存占用。

引入依赖

编写实现类

简单对上面逻辑进行讲解

是模拟远程获取 token

是先从 cache 中获取，如果没有获取到，从远程获取。

是3秒过期，这是为了测试。

监听过期。

，sleep 3秒看一下更新情况。

由下面日志可见执行情况

我们使用的还只是 的冰山一角，它可以支容量和时间多种策略配置回收策略，同时它是良好的 实现。如上场景比较简单，如果你考虑缓存其他需求，需要考虑 和 等配合使用，避免缓存击穿和性能问题。

原理

的设计和 非常类似，使用多个 segments 方式的细粒度锁,在保证线程安全的同时,支持高并发场景需求。看过 实现原理的朋友跟进代码一看了然。当然它的设计更复杂一些，跟进代码的话也比较简单，在 的时候他会根据不同的策略进行比对是否过期，如果过期再进行相应的通知操作。同时他巧妙的使用的 ，这样可以利用 来做删除数据的通知。