烛衡 阿里云开发者

利用缓存做性能优化的案例非常多,从基础的操作系统到数据库、分布式缓存、本地缓存等。它们表现形式各异,却有着共同的朴素的本质:弥补CPU的高算力和IO的慢读写之间巨大的鸿沟。

和架构选型类似,每引入一个组件,都会导致复杂度的上升。以缓存为例,它带来性能提升的同时,也带来一些问题,需要开发者设计和权衡。

本文的思维脉络如下:

一 缓存和多级缓存

1 缓存的引入

在初期业务量小的时候,数据库能承担读写压力,应用可以直接和DB交互,架构简单且强壮。

经过一段时间发展后,业务量迎来了大规模增长,此时DB查询压力和耗时都在增长。此时引入分布式缓存,在减少DB压力的同时,还提供了更高的QPS。

再往后发展,分布式缓存也成为了瓶颈,高频的QPS是一笔负担;另外缓存驱逐以及网络抖动会影响系统的稳定性,此时引入本地缓存,可以减轻分布式缓存的压力,并减少网络以及序列化开销。

2 读写的性能提升

缓存通过减少IO操作来获得读写的性能提升。有一个表格,可以看见磁盘、网络的IO操作耗时,远高于内存存取。

  • 读优化:当请求命中缓存后,可直接返回,从而略过IO读取,减小读的成本。
  • 写优化:将写操作在缓冲中合并,让IO设备可以批量处理,减小写的成本。

缓存带来的QPS、RT提升比较直观,不补充介绍。

3 缓存Miss

缓存Miss是必然会面对的问题,缓存需保证在有限的容量下,将热点的数据维护在缓存中,从而达到性能、成本的平衡。

缓存通常使用LRU算法淘汰近期不常用的Key。

近似LRU

可以先试想严格LRU的实现。假设Redis当前有50W规模的key,先通过Keys 遍历获得所有Key,然后比对出空闲时间最长的某个key,最后执行淘汰。这样的流程下来,是非常昂贵的,Keys命令是一笔不小的开销,其次大规模执行比对也很昂贵。

当然严格LRU实现的优化空间还是有的,YY一下,可以通过活跃度分离出活跃Key和待回收Key, 淘汰时只关注待回收key即可;回收算法引入链表或者树的结构,使Key按空闲时间有序,淘汰时直接获取。然而这些优化不可避免的是,在缓存读写时,这些辅助的数据结构需要同步更新,带来的存储以及计算的成本很高。

在Redis中它采用了近似LRU的实现,它随机采样5个Key,淘汰掉其中空闲时间最长的那个。近似LRU实现起来更简单、成本更低,在效果上接近严格LRU。它的缺点是存在一定的几率淘汰掉最近被访问的Key,即在TTL到期前也可能被淘汰。

避免短期大量失效

在一些场景中,程序是批量加载数据到缓存的, 比如通过Excel上传数据,系统解析后,批量写入DB和缓存。此时若不经设计,这批数据的超时时间往往是一致的。缓存到期后,本该缓存承担的流量将打到DB上,从而降低接口甚至系统的性能和稳定性。

可以利用随机数打散缓存失效时间,例如设置TTL=8hr+random(8000)ms。

4 缓存一致性

系统应尽量保证DB、缓存的数据一致性,较常使用的是cache aside设计模式。

避免使用非常规的缓存设计模式:先更新缓存、后更新DB;先更新DB、后更新缓存(cache aside是直接失效缓存)。这些模式的不一致风险较高。

缓存设计模式

业务系统通常使用cache aside 模式,操作系统、数据库、分布式缓存等会使用write throgh、write back。

cache aside的缓存不一致

Cache aside模式大部分时间运行良好,在一些极端场景下,仍可能出现不一致风险。主要来自两方面:

  1. 由于中间件或者网络等问题,缓存失效失败。
  2. 出现意外的缓存失效、读取的时序。

缓存失效失败很容易理解,不做补充。主要介绍时序引起的不一致问题。

考虑这样的时间轴,A线程发现cache miss后重新加载缓存,此时读的数据还是老的, 另一个线程B更新数据并失效缓存。若B线程失效缓存的操作完成时间早于A线程,A线程会写入老的数据。

缓存不一致有一些缓解方法,例如延迟双删、CDC同步。这些方案都提升了系统复杂度,需综合考虑业务的容忍度,方案的复杂度等。

  • 延迟双删:主线程失效缓存后,将失效指令放入延时队列,另一个线程轮询队列获取指令并执行。
  • CDC同步:通过canal订阅MySQL binlog的变更,上报给Kafka,系统监听Kafka消息触发缓存失效。

二 从堆内存到直接内存

1 直接内存的引入

Java本地缓存分两类,基于堆内存的、基于直接内存的。

采用堆内存做缓存的主要问题是GC,由于缓存对象的生命周期往往较长,需要通过Major GC进行回收。若缓存的规模很大,那么GC会非常耗时。

采用直接内存做缓存的主要问题是内存管理。程序需自主控制内存的分配和回收,存在OOM或者Memory Leak的风险。另外直接内存不能存取对象,在操作时需进行序列化。

直接内存能减少GC压力,因为它只需要保存直接内存的引用,而对象本身是存储在直接内存中。引用晋升到老年代后占用的空间很小,对GC的负担可忽略。

直接内存的回收依赖System。gc的调用,但这个调用JVM不保证执行、也不保证何时执行,它的行为是不可控的。程序一般需要自行管理,成对去调用malloc、free,依托于这种“手工、类C”的内存管理,可以增加内存回收的可控性和灵活性。

2 直接内存管理

由于直接内存的分配和回收比较昂贵,需要通过内核操作物理内存。申请的时候一般是申请大的内存快,然后再根据需求分配小块给线程。回收的时候不直接释放,而是放入内存池来重用。

如何快速找到一个空闲块、如何减少内存碎片、如何快速回收等等,它是一个系统性的问题,也有很多专门的算法。

Jemalloc是综合能力较好的算法,free BSD、Redis默认采用了该算法,OHC缓存也建议服务器配置该算法。Netty的作者实现了Java版本,感兴趣的可以阅读。

三 CPU缓存

利用上分布式缓存、本地缓存之后,还可以继续提升的就是CPU缓存了。它虽不易察觉,但在高并发下对性能存在一定的影响。

CPU缓存分为L1、L2、L3 三级,越靠近CPU的,容量越小,命中率越高。当L3等级的缓存都取不到数据的时候,需从主存中获取。

1 CPU cache line

CPU缓存由cache line组成,每一个cache line为64字节,能容纳8个long值。在CPU从主存获取数据时,以cache line为单位加载,于是相邻的数据会一并加载到缓存中。很容易想到,数组的顺序遍历、相邻数据的计算是非常高效的。

2 伪共享 false sharing

CPU缓存也存在一致性问题,它通过MESI协议、MESIF�