世界要闻：聊聊本地缓存和分布式缓存

缓存，消息队列，分库分表是高并发解决方案三剑客。

缓存之所以能够让系统“更快”，本质上做到了如下两点：

对于应用系统来讲，我们经常将缓存划分为本地缓存和分布式缓存。

本地缓存：应用中的缓存组件，缓存组件和应用在同一进程中，缓存的读写非常快，没有网络开销。但各应用或集群的各节点都需要维护自己的单独缓存，无法共享缓存。

分布式缓存：和应用分离的缓存组件或服务，与本地应用隔离，多个应用可直接共享缓存。

这篇文章，聊聊本地缓存和分布式缓存，希望大家读完之后，在面对不同的业务场景时，能够做出合理的缓存选型。

JDK Map 经常用于缓存实现：

笔者曾经负责艺龙红包系统，红包活动就是存储在ConcurrentHashMap中 ，通过定时任务刷新缓存。

核心流程：

1、红包系统启动后，初始化一个 ConcurrentHashMap 作为红包活动缓存 ；

2、数据库查询所有的红包活动 , 并将活动信息存储在 Map 中 ;

3、定时任务每隔 30 秒 ，执行缓存加载方法，刷新缓存。

为什么红包系统会将红包活动信息存储在本地内存 ConcurrentHashMap 呢 ？

笔者见过很多单体应用都使用这种方案，该方案的特点是简洁易用，工程实现也容易 。

虽然使用 JDK Map 能快捷构建缓存，但缓存的功能还是比较孱弱的。

因为现实场景里，我们可能需要给缓存添加缓存统计、过期失效、淘汰策略等功能。

于是，本地缓存框架应运而生。

流行的 Java 缓存框架包括：Ehcache , Google Guava , Caffeine Cache 。

下图展示了 Caffeine 框架的使用示例。

虽然本地缓存框架的功能很强大，但是本地缓存的缺陷依然明显。

1、高并发的场景，应用重启之后，本地缓存就失效了，系统的负载就比较大，需要花较长的时间才能恢复；

2、每个应用节点都会维护自己的单独缓存，缓存同步比较头疼。

分布式缓存是指将缓存数据分布在多台机器上，以提高缓存容量和并发读写能力的缓存系统。分布式缓存通常由多台机器组成一个集群，每台机器上都运行着相同的缓存服务进程，缓存数据被均匀地分布在集群中的各个节点上。

Redis 是分布式缓存的首选，甚至我们一提到缓存，很多后端工程师首先想到的就它。

下图是神州专车订单的 Redis 集群架构 。将 Redis 集群拆分成四个分片，每个分片包含一主一从，主从可以切换。应用 A 根据不同的缓存 key 访问不同的分片。

与本地缓存相比，分布式缓存具有以下优点：

1、容量和性能可扩展

通过增加集群中的机器数量，可以扩展缓存的容量和并发读写能力。同时，缓存数据对于应用来讲都是共享的。

2、高可用性

由于数据被分布在多台机器上，即使其中一台机器故障，缓存服务也能继续提供服务。

但是分布式缓存的缺点同样不容忽视。

1、网络延迟

分布式缓存通常需要通过网络通信来进行数据读写，可能会出现网络延迟等问题，相对于本地缓存而言，响应时间更长。

2、复杂性

分布式缓存需要考虑序列化、数据分片、缓存大小等问题，相对于本地缓存而言更加复杂。

举一个真实的案例，这次案例让笔者对于分布式缓存的认知提上了另一个台阶。

2014年，同事开发了比分直播的系统，所有的请求都是从分布式缓存 Memcached 中获取后直接响应。常规情况下，从缓存中查询数据非常快，但在线用户稍微多一点，整个系统就会特别卡。

通过 jstat 命令发现 GC 频率极高，几次请求就将新生代占满了，而且 CPU 的消耗都在 GC 线程上。初步判断是缓存值过大导致的，果不其然，缓存大小在 300k 到 500k 左右。

解决过程还比较波折，分为两个步骤：

经过这次优化，笔者理解到：缓存虽然可以提升整体速度，但是在高并发场景下，缓存对象大小依然是需要关注的点，稍不留神就会产生事故。另外我们也需要合理地控制读取策略，最大程度减少 GC 的频率 , 从而提升整体性能。

开源中国网站最开始完全是用本地缓存框架 Ehcache 。后来随着访问量的激增，出现了一个可怕的问题：“因为 Java 程序更新很频繁，每次更新的时候都要重启。一旦重启后，整个 Ehcache 缓存里的数据都被清掉。重启后若大量访问进来的话，开源中国的数据库基本上很快就会崩掉”。

于是，开源中国开发了多级缓存框架 J2Cache，使用了多级缓存 Ehcache + Redis。

多级缓存有如下优势：

本地缓存做为一级缓存，分布式缓存做为二级缓存，首先从一级缓存中查询，若能查询到数据则直接返回，否则从二级缓存中查询，若二级缓存中可以查询到数据，则回填到一级缓存中，并返回数据。若二级缓存也查询不到，则从数据源中查询，将结果分别回填到一级缓存，二级缓存中。

2018年，笔者服务的一家电商公司需要进行 app 首页接口的性能优化。笔者花了大概两天的时间完成了整个方案，采取的是两级缓存模式，同时利用了 Guava 的惰性加载机制，整体架构如下图所示：

缓存读取流程如下：

1、业务网关刚启动时，本地缓存没有数据，读取 Redis 缓存，如果 Redis 缓存也没数据，则通过 RPC 调用导购服务读取数据，然后再将数据写入本地缓存和 Redis 中；若 Redis 缓存不为空，则将缓存数据写入本地缓存中。

2、由于步骤1已经对本地缓存预热，后续请求直接读取本地缓存，返回给用户端。

3、Guava 配置了 refresh 机制，每隔一段时间会调用自定义 LoadingCache 线程池（5个最大线程，5个核心线程）去导购服务同步数据到本地缓存和 Redis 中。

优化后，性能表现很好，平均耗时在 5ms 左右。最开始我以为出现问题的几率很小，可是有一天晚上，突然发现 app 端首页显示的数据时而相同，时而不同。

也就是说：虽然 LoadingCache 线程一直在调用接口更新缓存信息，但是各个 服务器本地缓存中的数据并非完成一致。说明了两个很重要的点：

1、惰性加载仍然可能造成多台机器的数据不一致

2、LoadingCache 线程池数量配置的不太合理, 导致了线程堆积

最终，我们的解决方案是：

1、惰性加载结合消息机制来更新缓存数据，也就是：当导购服务的配置发生变化时，通知业务网关重新拉取数据，更新缓存。

2、适当调大 LoadigCache 的线程池参数，并在线程池埋点，监控线程池的使用情况，当线程繁忙时能发出告警，然后动态修改线程池参数。

Fred Brooks 在 1987 年所发表的一篇关于软件工程的经典论文《没有银弹：软件工程的本质性与附属性工作》。

论文强调真正的银弹并不存在，而所谓的银弹则是指没有任何一项技术或方法可以能让软件工程的生产力在十年内提高十倍。

通俗来讲：在技术领域中没有一种通用的解决方案可以解决所有问题。技术本质上是为了解决问题而存在的，每个问题都有其独特的环境和限制条件，没有一种通用的技术或工具可以完美地解决所有问题。

缓存是把双刃剑，一方面我们享受缓存带来的系统性能提升，另一方面引入缓存会提高系统复杂度，因为你要考虑缓存的失效、更新、一致性等问题。

在面临缓存选型时，一定要结合业务场景，研发效率，运维成本，人力模型，技术储备等因素，做出合理的选择。

最后，欢迎学编程的朋友们加入鱼皮的，和上万名学编程的同学共享知识、交流进步，学习原创项目并享有答疑指导服务。