聊聊本地缓存和分布式缓存？

缓存消息队列分库分表是高并发解决方案三剑客。缓存之所以能够让系统“更快”本质上做到了如下两点减小 CPU 消耗将原来需要实时计算的内容提前算好、把一些公用的数据进行复用这可以减少 CPU 消耗从而提升响应性能。减小 I/O 消耗将原来对网络、磁盘等较慢介质的读写访问变为对内存等较快介质的访问从而提升响应性能。对于应用系统来讲我们经常将缓存划分为本地缓存和分布式缓存。本地缓存应用中的缓存组件缓存组件和应用在同一进程中缓存的读写非常快没有网络开销。但各应用或集群的各节点都需要维护自己的单独缓存无法共享缓存。分布式缓存和应用分离的缓存组件或服务与本地应用隔离多个应用可直接共享缓存。这篇文章聊聊本地缓存和分布式缓存希望大家读完之后在面对不同的业务场景时能够做出合理的缓存选型。1 本地缓存 JDK MapJDK Map 经常用于缓存实现HashMapHashMap 是一种基于哈希表的集合类它提供了快速的插入、查找和删除操作。可以将键值对作为缓存项的存储方式将键作为缓存项的唯一标识符值作为缓存项的内容。ConcurrentHashMapConcurrentHashMap 是线程安全的 HashMap它在多线程环境下可以保证高效的并发读写操作。LinkedHashMapLinkedHashMap 是一种有序的 HashMap 它保留了元素插入的顺序可以按照插入顺序或者访问顺序进行遍历。TreeMapTreeMap 是一种基于红黑树的有序 Map它可以按照键的顺序进行遍历。笔者曾经负责艺龙红包系统红包活动就是存储在ConcurrentHashMap中 通过定时任务刷新缓存。核心流程1、红包系统启动后初始化一个 ConcurrentHashMap 作为红包活动缓存 2、数据库查询所有的红包活动 , 并将活动信息存储在 Map 中 ;3、定时任务每隔 30 秒 执行缓存加载方法刷新缓存。为什么红包系统会将红包活动信息存储在本地内存 ConcurrentHashMap 呢 红包系统是高并发应用快速将请求结果响应给前端大大提升用户体验红包活动数量并不多就算全部放入到 Map 里也不会产生内存溢出的问题定时任务刷新缓存并不会影响红包系统的业务。笔者见过很多单体应用都使用这种方案该方案的特点是简洁易用工程实现也容易 。2 本地缓存框架虽然使用 JDK Map 能快捷构建缓存但缓存的功能还是比较孱弱的。因为现实场景里我们可能需要给缓存添加缓存统计、过期失效、淘汰策略等功能。于是本地缓存框架应运而生。流行的 Java 缓存框架包括Ehcache , Google Guava , Caffeine Cache 。下图展示了 Caffeine 框架的使用示例。虽然本地缓存框架的功能很强大但是本地缓存的缺陷依然明显。1、高并发的场景应用重启之后本地缓存就失效了系统的负载就比较大需要花较长的时间才能恢复2、每个应用节点都会维护自己的单独缓存缓存同步比较头疼。3 分布式缓存分布式缓存是指将缓存数据分布在多台机器上以提高缓存容量和并发读写能力的缓存系统。分布式缓存通常由多台机器组成一个集群每台机器上都运行着相同的缓存服务进程缓存数据被均匀地分布在集群中的各个节点上。Redis 是分布式缓存的首选甚至我们一提到缓存很多后端工程师首先想到的就它。下图是神州专车订单的 Redis 集群架构 。将 Redis 集群拆分成四个分片每个分片包含一主一从主从可以切换。应用 A 根据不同的缓存 key 访问不同的分片。与本地缓存相比分布式缓存具有以下优点1、容量和性能可扩展通过增加集群中的机器数量可以扩展缓存的容量和并发读写能力。同时缓存数据对于应用来讲都是共享的。2、高可用性由于数据被分布在多台机器上即使其中一台机器故障缓存服务也能继续提供服务。但是分布式缓存的缺点同样不容忽视。1、网络延迟分布式缓存通常需要通过网络通信来进行数据读写可能会出现网络延迟等问题相对于本地缓存而言响应时间更长。2、复杂性分布式缓存需要考虑序列化、数据分片、缓存大小等问题相对于本地缓存而言更加复杂。举一个真实的案例这次案例让笔者对于分布式缓存的认知提上了另一个台阶。2014年同事开发了比分直播的系统所有的请求都是从分布式缓存 Memcached 中获取后直接响应。常规情况下从缓存中查询数据非常快但在线用户稍微多一点整个系统就会特别卡。通过 jstat 命令发现 GC 频率极高几次请求就将新生代占满了而且 CPU 的消耗都在 GC 线程上。初步判断是缓存值过大导致的果不其然缓存大小在 300k 到 500k 左右。解决过程还比较波折分为两个步骤修改新生代大小从原来的 2G 修改成 4G并精简缓存数据大小 (从平均 300k 左右降为 80k 左右)把缓存拆成两个部分第一部分是全量数据第二部分是增量数据数据量很小。页面第一次请求拉取全量数据当比分有变化的时候通过 websocket 推送增量数据。经过这次优化笔者理解到缓存虽然可以提升整体速度但是在高并发场景下缓存对象大小依然是需要关注的点稍不留神就会产生事故。另外我们也需要合理地控制读取策略最大程度减少 GC 的频率 , 从而提升整体性能。4 多级缓存开源中国网站最开始完全是用本地缓存框架 Ehcache 。后来随着访问量的激增出现了一个可怕的问题“因为 Java 程序更新很频繁每次更新的时候都要重启。一旦重启后整个 Ehcache 缓存里的数据都被清掉。重启后若大量访问进来的话开源中国的数据库基本上很快就会崩掉”。于是开源中国开发了多级缓存框架J2Cache使用了多级缓存Ehcache Redis。多级缓存有如下优势离用户越近速度越快减少分布式缓存查询频率降低序列化和反序列化的 CPU 消耗大幅度减少网络 IO 以及带宽消耗。本地缓存做为一级缓存分布式缓存做为二级缓存首先从一级缓存中查询若能查询到数据则直接返回否则从二级缓存中查询若二级缓存中可以查询到数据则回填到一级缓存中并返回数据。若二级缓存也查询不到则从数据源中查询将结果分别回填到一级缓存二级缓存中。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 的线程池参数并在线程池埋点监控线程池的使用情况当线程繁忙时能发出告警然后动态修改线程池参数。5 总结Fred Brooks 在 1987 年所发表的一篇关于软件工程的经典论文《没有银弹软件工程的本质性与附属性工作》。论文强调真正的银弹并不存在而所谓的银弹则是指没有任何一项技术或方法可以能让软件工程的生产力在十年内提高十倍。通俗来讲在技术领域中没有一种通用的解决方案可以解决所有问题。技术本质上是为了解决问题而存在的每个问题都有其独特的环境和限制条件没有一种通用的技术或工具可以完美地解决所有问题。缓存是把双刃剑一方面我们享受缓存带来的系统性能提升另一方面引入缓存会提高系统复杂度因为你要考虑缓存的失效、更新、一致性等问题。在面临缓存选型时一定要结合业务场景研发效率运维成本人力模型技术储备等因素做出合理的选择。