本地缓存和分布式缓存
高并发解决方案
缓存,消息队列,分库分表是高并发解决方案三剑客。
缓存之所以能够让系统“更快”,本质上做到了如下两点:
-
减小 CPU 消耗。将原来需要实时计算的内容提前算好、把一些公用的数据进行复用,这可以减少 CPU 消耗,从而提升响应性能。
-
减小 I/O 消耗 。将原来对网络、磁盘等较慢介质的读写访问变为对内存等较快介质的访问,从而提升响应性能。
对于应用系统来讲,我们经常将缓存划分为本地缓存和分布式缓存。
本地缓存 :应用中的缓存组件,缓存组件和应用在同一进程中,缓存的读写非常快,没有网络开销。但各应用或集群的各节点都需要维护自己的单独缓存,无法共享缓存。
分布式缓存:和应用分离的缓存组件或服务,与本地应用隔离,多个应用可直接共享缓存。
这篇文章,聊聊本地缓存和分布式缓存,希望大家读完之后,在面对不同的业务场景时,能够做出合理的缓存选型。
1 本地缓存 JDK Map
JDK Map 经常用于缓存实现:
- HashMap
HashMap 是一种基于哈希表的集合类,它提供了快速的插入、查找和删除操作。可以将键值对作为缓存项的存储方式,将键作为缓存项的唯一标识符,值作为缓存项的内容。
- ConcurrentHashMap
ConcurrentHashMap 是线程安全的 HashMap,它在多线程环境下可以保证高效的并发读写操作。
- LinkedHashMap
LinkedHashMap 是一种有序的 HashMap ,它保留了元素插入的顺序,可以按照插入顺序或者访问顺序进行遍历。
- TreeMap
TreeMap 是一种基于红黑树的有序 Map,它可以按照键的顺序进行遍历。
某红包系统,红包活动就是存储在 ConcurrentHashMap 中 ,通过定时任务刷新缓存 。
核心流程:
1、红包系统启动后,初始化一个 ConcurrentHashMap 作为红包活动缓存 ;
2、数据库查询所有的红包活动 , 并将活动信息存储在 Map 中 ;
3、定时任务每隔 30 秒 ,执行缓存加载方法,刷新缓存。
为什么红包系统会将红包活动信息存储在本地内存 ConcurrentHashMap 呢 ?
-
红包系统是高并发应用,快速将请求结果响应给前端,大大提升用户体验;
-
红包活动数量并不多,就算全部放入到 Map 里也不会产生内存溢出的问题;
-
定时任务刷新缓存并不会影响红包系统的业务。
很多单体应用都使用这种方案,该方案的特点是简洁易用,工程实现也容易 。
2 本地缓存框架
虽然使用 JDK Map 能快捷构建缓存,但缓存的功能还是比较孱弱的。
因为现实场景里,我们可能需要给缓存添加缓存统计、过期失效、淘汰策略等功能。
于是,本地缓存框架应运而生。
流行的 Java 缓存框架包括:Ehcache , Google Guava , Caffeine Cache 。
下面展示了 Caffeine 框架的使用示例。
import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;
import java.util.concurrent.TimeUnit;
public class CaffeineExample {
public static void main(String[] args) {
// 创建一个基于 Caffeine 的缓存实例
Cache<String, String> cache = Caffeine.newBuilder()
.maximumSize(100) // 最大缓存条目数
.expireAfterWrite(10, TimeUnit.MINUTES) // 写后过期时间,10分钟
.build();
// 向缓存中放入数据
cache.put("key1", "value1");
cache.put("key2", "value2");
// 从缓存中获取数据
String value1 = cache.getIfPresent("key1");
String value2 = cache.getIfPresent("key2");
System.out.println("Value1: " + value1);
System.out.println("Value2: " + value2);
// 移除缓存中的数据
cache.invalidate("key1");
// 清空缓存
cache.invalidateAll();
// 缓存统计信息
long cacheSize = cache.estimatedSize();
System.out.println("Cache size: " + cacheSize);
}
}
虽然本地缓存框架的功能很强大,但是本地缓存的缺陷依然明显。
1、高并发的场景,应用重启之后,本地缓存就失效了,系统的负载就比较大,需要花较长的时间才能恢复;
2、每个应用节点都会维护自己的单独缓存,缓存同步比较头疼。
3 分布式缓存
分布式缓存是指将缓存数据分布在多台机器上,以提高缓存容量和并发读写能力的缓存系统。分布式缓存通常由多台机器组成一个集群,每台机器上都运行着相同的缓存服务进程,缓存数据被均匀地分布在集群中的各个节点上。
Redis 是分布式缓存的首选,甚至我们一提到缓存,很多后端工程师首先想到的就它。
下图是神州专车订单的 Redis 集群架构 。将 Redis 集群拆分成四个分片,每个分片包含一主一从,主从可以切换。应用 A 根据不同的缓存 key 访问不同的分片。
与本地缓存相比,分布式缓存具有以下优点:
1、容量和性能可扩展
通过增加集群中的机器数量,可以扩展缓存的容量和并发读写能力。同时,缓存数据对于应用来讲都是共享的。
2、高可用性
由于数据被分布在多台机器上,即使其中一台机器故障,缓存服务也能继续提供服务。
但是分布式缓存的缺点同样不容忽视。
1、网络延迟
分布式缓存通常需要通过网络通信来进行数据读写,可能会出现网络延迟等问题,相对于本地缓存而言,响应时间更长。
2、复杂性
分布式缓存需要考虑序列化、数据分片、缓存大小等问题,相对于本地缓存而言更加复杂。
某了比分直播的系统,所有的请求都是从分布式缓存 Memcached 中获取后直接响应。常规情况下,从缓存中查询数据非常快,但在线用户稍微多一点,整个系统就会特别卡。
通过 jstat 命令发现 GC 频率极高,几次请求就将新生代占满了,而且 CPU 的消耗都在 GC 线程上。初步判断是缓存值过大导致的,果不其然,缓存大小在 300k 到 500k 左右。
解决过程还比较波折,分为两个步骤:
- 1、修改新生代大小,从原来的 2G 修改成 4G,并精简缓存数据大小 (从平均 300k 左右降为 80k 左右);
- 2、把缓存拆成两个部分,第一部分是全量数据,第二部分是增量数据(数据量很小)。页面第一次请求拉取全量数据,当比分有变化的时候,通过 websocket 推送增量数据。
经过这次优化,理解到:缓存虽然可以提升整体速度,但是在高并发场景下,缓存对象大小依然是需要关注的点,稍不留神就会产生事故。另外我们也需要合理地控制读取策略,最大程度减少 GC 的频率 , 从而提升整体性能。
4 多级缓存
开源中国网站最开始完全是用本地缓存框架 Ehcache 。后来随着访问量的激增,出现了一个可怕的问题:“因为 Java 程序更新很频繁,每次更新的时候都要重启。一旦重启后,整个 Ehcache 缓存里的数据都被清掉。重启后若大量访问进来的话,数据库基本上很快就会崩掉”。
于是,开源中国开发了多级缓存框架 J2Cache,使用了多级缓存 Ehcache + Redis 。
多级缓存有如下优势:
- 1、离用户越近,速度越快;
- 2、减少分布式缓存查询频率,降低序列化和反序列化的 CPU 消耗;
- 3、大幅度减少网络 IO 以及带宽消耗。
本地缓存做为一级缓存,分布式缓存做为二级缓存,首先从一级缓存中查询,若能查询到数据则直接返回,否则从二级缓存中查询,若二级缓存中可以查询到数据,则回填到一级缓存中,并返回数据。若二级缓存也查询不到,则从数据源中查询,将结果分别回填到一级缓存,二级缓存中。
一家电商公司需要进行 app 首页接口的性能优化。采取的是两级缓存模式,同时利用了 Guava 的惰性加载机制,整体架构如下图所示:
缓存读取流程如下:
-
1、业务网关刚启动时,本地缓存没有数据,读取 Redis 缓存,如果 Redis 缓存也没数据,则通过 RPC 调用导购服务读取数据,然后再将数据写入本地缓存和 Redis 中;若 Redis 缓存不为空,则将缓存数据写入本地缓存中。
-
2、由于步骤1已经对本地缓存预热,后续请求直接读取本地缓存,返回给用户端。
-
3、Guava 配置了 refresh 机制,每隔一段时间会调用自定义 LoadingCache 线程池(5个最大线程,5个核心线程)去导购服务同步数据到本地缓存和 Redis 中。
优化后,性能表现很好,平均耗时在 5ms 左右。最开始我以为出现问题的几率很小,可是有一天晚上,突然发现 app 端首页显示的数据时而相同,时而不同。
最开始我以为出现问题的几率很小,可是有一天晚上,突然发现 app 端首页显示的数据时而相同,时而不同。
也就是说:虽然 LoadingCache 线程一直在调用接口更新缓存信息,但是各个 服务器本地缓存中的数据并非完成一致。说明了两个很重要的点:
-
1、惰性加载仍然可能造成多台机器的数据不一致
-
2、LoadingCache 线程池数量配置的不太合理, 导致了线程堆积
最终,我们的解决方案是:
-
1、惰性加载结合消息机制来更新缓存数据,也就是:当导购服务的配置发生变化时,通知业务网关重新拉取数据,更新缓存。
-
2、适当调大 LoadigCache 的线程池参数,并在线程池埋点,监控线程池的使用情况,当线程繁忙时能发出告警,然后动态修改线程池参数。