聊聊缓存世界的扫地僧_全球独家

这篇文章，笔者想聊聊那些在业务系统中较少被使用，但却活跃于中间件或者框架里，强大却又低调的缓存，笔者愿称他们为缓存世界的扫地僧。

一、HashMap/ConcurrentHashMap 配置缓存

HashMap 是一种基于哈希表的集合类，它提供了快速的插入、查找和删除操作。

HashMap 是很多程序员接触的第一种缓存 , 因为现实业务场景里，我们可能需要给缓存添加缓存统计、过期失效、淘汰策略等功能，HashMap 的功能就显得孱弱 ，所以 HashMap 在业务系统中使用得并不算多。

(资料图片仅供参考)

但HashMap 在中间件中却是香饽饽，我们消息中间件 RocketMQ 为例。

上图是 RocketMQ 的集群模式 ，Broker 分为 Master 与 Slave，一个 Master 可以对应多个 Slave，但是一个 Slave 只能对应一个 Master。

每个 Broker 与 Name Server 集群中的所有节点建立长连接，定时每隔 30 秒注册主题的路由信息到所有 Name Server。

消息发送者、消息消费者，在同一时间只会连接 Name Server 集群中的一台服务器，并且会每隔 30s 会定时更新 Topic 的路由信息。

我们可以理解 Name Server 集群的作用就是注册中心，注册中心会保存路由信息（主题的读写队列数、操作权限等），路由信息就是保存在HashMap中 。

路由信息通过几个 HashMap 来保存，当 Broker 向 Nameserver 发送心跳包（路由信息），Nameserver 需要对 HashMap 进行数据更新，但我们都知道 HashMap 并不是线程安全的，高并发场景下，容易出现 CPU 100% 问题，所以更新 HashMap 时需要加锁，RocketMQ 使用了 JDK 的读写锁 ReentrantReadWriteLock 。

下面我们看下路由信息如何更新和读取：

1、写操作：更新路由信息，操作写锁2、读操作：查询主题信息，操作读锁

同时，我们需要注意 Name Server 维护路由信息还需要定时任务的支撑。

每个 Broker 定时每隔 30 秒注册主题的路由信息到所有 Name ServerName Server 定时任务每隔10 秒清除已宕机的 Broker

我们做一个小小的总结，Name Server 维护路由的模式是：HashMap + 读写锁 + 定时任务更新。

HashMap 作为存储容器读写锁控制锁的颗粒度定时任务定时更新缓存

写到这里，我们不禁想到 ConcurrentHashMap 。

ConcurrentHashMap 可以保证线程安全，JDK1.7 之前使用分段锁机制实现，JDK1.8 则使用数组+链表+红黑树数据结构和CAS原子操作实现。

Broker 使用不同的 ConcurrentHashMap 分别用来存储消费组、消费进度、消息过滤信息等。

那么名字服务为什么不使用 ConcurrentHashMap 作为存储容器呢 ？

最核心的原因在于：路由信息由多个 HashMap 组成，通过每次写操作可能要操作多个对象 ，为了保证其一致性，所以才需要加读写锁。

二、LinkedHashMap 最近最少使用缓存

LinkedHashMap 是 HashMap 的子类，但是内部还有一个双向链表维护键值对的顺序，每个键值对既位于哈希表中，也位于双向链表中。

LinkedHashMap 支持两种顺序插入顺序 、 访问顺序。

插入顺序：先添加的在前面，后添加的在后面，修改操作并不影响顺序访问顺序：问指的是 get/put 操作，对一个键执行 get/put 操作后，其对应的键值对会移动到链表末尾，所以最末尾的是最近访问的，最开始的是最久没有被访问的，这就是访问顺序。

LinkedHashMap 经典的用法是作为 LruCache (最近最少使用缓存) ，而 MyBatis 的二级缓存的淘汰机制就是使用的 LinkedHashMap 。

MyBatis 的二级缓存是使用责任链+装饰器的设计模式实现的。

上图中，装饰器包目录下 Cache 接口有不同的实现类，比如过期淘汰、日志记录等。

LruCache 使用了装饰器模式 ，使用 LinkedHashMap 默认保存 1024 个缓存 key ，当 key 最久未被访问，并且 keyMap 的大小超过 1024 时 ，记录最老的 key ，当下次添加缓存对象时，删除最老的 key。

使用 LinkedHashMap 重点需要做到使用访问顺序模式和重写 removeEldestEntry 方法。因为 LinkedHashMap 并不是线程安全的，Mybatis 二级缓存责任链中 SynchronizedCache 对象可以实现线程安全的对缓存读写。

三、TreeMap 排序对象缓存

TreeMap 是一种基于红黑树的有序 Map，它可以按照键的顺序进行遍历。

TreeMap 有两种应用场景让笔者印象极为深刻 ，他们分别是一致性哈希算法和 RocketMQ 消费快照 。

本文重点介绍 TreeMap 在一致性哈希算法中的应用。

一致性哈希（Consistent Hashing）算法被广泛应用于缓存系统、分布式数据库、负载均衡器等分布式系统中，以实现高性能和高可用性。它解决了传统哈希算法在动态环境下扩展性和负载均衡性能的问题。

一致性哈希的主要优点是在节点增减时，只有少量的数据需要重新映射，因为只有那些直接或间接与新增或删除节点相邻的数据项需要迁移。这大大减少了系统的迁移开销和影响，使得系统更具扩展性和可伸缩性。

TreeMap 在一致性哈希中可以用作节点/虚拟节点的存储结构，用来维护节点在哈希环上的位置和键的有序性。

1、我们定义一个 TreeMap 存储节点/虚拟节点 。2、初始化节点

构造函数包含三个部分：物理节点集合、每个物理节点对应的虚拟节点个数、哈希函数 。

我们重点看下添加节点逻辑：

3、按照 key 查询节点

添加完节点之后，节点分布类似下图：

当需要定位某个 key 属于哪个节点时，先通过哈希函数计算 key 的哈希值，并在环上顺时针方向找到第一个大于等于该哈希值的节点位置。该节点即为数据的归属节点 。

我们添加一个新的节点 node5 , 从下图中，我们可以看到，影响的范围（深黄色）并不大 ，这也就是一致性哈希算法的优势。

四、ByteBuffer 网络编程缓冲池

ByteBuffer 是字节缓冲区，主要用于用户读取和缓存字节数据，多用于网络编程、文件 IO 处理等。

笔者第一次接触 ByteBuffer 是在分库分表中间件 Cobar 中 。在网络编程里，经常需要分配内存，在高并发场景下，性能压力比较大。

Cobar 抽象了一个 NIOProcessor 类用来处理网络请求，每个处理器初始化的时候都会创建一个缓冲池 BufferPool 。BufferPool 用于池化 ByteBuffer ，这和我们平常使用的数据库连接池的思路是一致的。

下图展示了缓冲池 BufferPool 的源码：

缓冲池 BufferPool 的核心功能是分配缓存和回收缓存，通过将缓存池化，可以大大提升系统的性能。

如今 ，Netty 内置了更为强大的内存池化工具 ByteBuf ，我们会在后面的文章里详聊。

五、写到最后

这篇文章，笔者总结了四种强大且低调的缓存。

1、HashMap/ConcurrentHashMap 经常用于配置缓存，对于 HashMap 来讲，HashMap + 读写锁 + 定时任务更新是常用的模式。而 ConcurrentHashMap 广泛存在于各种中间件，线程安全且灵活易用。

2、LinkedHashMap 经常被用于创建最近最少使用缓存 LruCache 。推荐学习 Mybatis 二级缓存的设计，它使用责任链+装饰器的设计模式，内置 LruCache 的实现就是使用 LinkedHashMap 。

3、TreeMap 是一种基于红黑树的有序 Map 。TreeMap 在一致性哈希中可以用作节点/虚拟节点的存储结构，用来维护节点在哈希环上的位置和键的有序性。

4、ByteBuffer 是字节缓冲区，主要用于用户读取和缓存字节数据，多用于网络编程、文件 IO 处理等。分库分表中间件 Cobar 在网络请求处理中，创建了缓冲池 BufferPool 用于池化 ByteBuffer ，从而大大提升系统的性能。

关键词：