使用 ChronicleMap 扩展高性能内存缓存

1.扩展内存缓存的挑战

我们用于与各种程序化和需求方平台 (DSP) 集成的应用程序之一是低延迟、高吞吐量的基于 JVM 的应用程序。这是付款凭单（DV）付前前验证解决方案的核心组件。自多年前成功推出此解决方案以来，我们不断添加多项关键功能，同时保持严格的延迟 SLA 并每天处理数千亿个请求。

近年来，用于投标前评估的测量数据（欺诈、品牌安全等）的大小大幅增长。随着数据集的增长，我们的内存缓存的大小也在增长。有一次，我们面临着一个关键挑战，即扩展我们最大的内存缓存以支持可能将我们的缓存大小增加四倍的新功能发布。我们有严格的低延迟响应 SLA、要支持的各种部署选项，以及低于 32GB 的有限 JVM 分配以使用压缩对象指针。在评估了几个选项后，我们决定使用 Chronicle Software 的开源 ChronicleMap 作为我们的解决方案。

在这篇博文中，我将讨论我们评估各种开源和企业解决方案的过程，以及我们最终选择 ChronicleMap 的原因。我还将分享我们的最佳实践和经验教训。

2.当前的问题

由于上述原因，我们现有的缓存解决方案无法处理增加的工作负载，因此我们需要一种可以扩展且仍能满足严格的延迟和部署要求的新解决方案。该应用程序服务于两种主要类型的竞价前集成：— (1) 缓存解决方案，DSP 在其终端缓存我们的响应，因此没有严格的延迟要求；(2) 其他集成，相比之下，它们使用实时竞价流响应，要求端到端延迟小于 10 毫秒。

此应用程序需要在付款凭单（DV）、云端甚至我们一些合作伙伴的本地托管，以使要求更加严格。我们可能拥有多个版本的应用程序，但决定只使用一个版本，以降低部署和维护的复杂性、我们的发布管道和可维护性。因此，我们选择的任何解决方案都需要符合上述要求。我们评估了几个选项，以找到最适合我们需求的选项。

3.评估各种开源和企业解决方案

为了找到满足我们要求的解决方案，我们评估了几种开源和企业选项，包括：

Redis — 一种流行的开源内存键值数据存储。
EhCache — 一种广泛使用的开源 Java 缓存。
Aerospike — 一种支持高吞吐量、低延迟缓存的企业级分布式缓存解决方案。
Hazelcast — 一种用于分布式计算和内存缓存的开源解决方案。
ChronicleMap — 一种专为低延迟和/或多进程应用程序设计的内存键值存储。

4.为什么我们决定使用 ChronicleMap？

我们研究并评估了上述选项的优点和局限性。虽然每种方案都有其优点，但我们需要针对我们独特的需求组合而制定非常具体的方法。

我们排除了需要进行进程外查找的任何解决方案，因为与访问本地 RAM 的速度相比，完成查找需要额外的时间。

这可能会破坏我们 10 毫秒的整体端到端延迟要求。此外，在每个地区为这些解决方案创建服务器集群会给我们增加大量的维护和基础设施成本开销，更重要的是，也会给托管我们应用程序的本地合作伙伴增加成本开销。因此，我们排除了 Redis 和 Aerospike。

虽然 Terracotta 的 EhCache 似乎为较小的缓存提供了良好的性能，但由于其在扩展大型缓存方面的局限性以及开源版本不支持堆外存储，它并不适合我们的需求。Terracotta 的堆外存储解决方案 BigMemory 仅作为商业解决方案提供。

Hazelcast 表现出良好的性能和可扩展性，但需要进行大量配置和调整才能实现最佳性能。此外，Hazelcast 的堆外解决方案高密度存储仅在商业上可用。

相比之下，ChronicleMap 脱颖而出，成为最适合我们需求的解决方案，因为它满足了我们的核心要求。

它针对低垃圾收集进行了优化，并提供高性能数据存储、检索和迭代。
它可以作为我们应用程序的一部分实施，使我们能够保持部署简单，而无需为外部缓存维护单独的服务器集群。
它被实现为内存中的堆外解决方案，可以使用磁盘进一步扩展。由于它是堆外的，- 我们可以扩展内存缓存，同时将应用程序的堆内内存分配保持在 32GB 以下。
开源版本中提供的功能似乎足以满足我们的要求 - 主要是内存、堆外映射和持久化到磁盘，以实现快速应用程序重启。

我们还发现，ChronicleMap 在全球银行和对冲基金的生产中被广泛使用，它们必须处理与付款凭单（DV）类似的规模。我们觉得它很合适。我们实施了概念验证 (POC)，结果令人鼓舞。此时，我们对选择 ChronicleMap 来扩展我们的内存缓存充满信心。

5.经验和最佳实践

随着数据集的增长，我们能够扩展内存缓存，而不会牺牲低延迟响应时间。

以下是我们通过利用 ChronicleMap 提供的一些功能在应用程序中看到的显著改进：

缩放数据集的能力。在我们成功将页面分类类别移至堆外缓存并启动依赖于扩展的功能后，我们开始迁移其他数据集。与原始 HashMap 的查找延迟相比，ChronicleMap 缓存的查找延迟增加了可忽略不计的额外时间（纳秒）。我们最终能够支持在需要时按多个因子扩展每个数据集，这是一个巨大的好处。
改进的垃圾收集。在将许多数据集移至 ChronicleMap 后，我们注意到垃圾收集减少方面取得了显著进步。由于堆上的大部分内存被移至堆外，JVM 内存占用减少导致垃圾收集周期更少且速度更快。
提高代码可维护性。在使用 ChronicleMap 之前，我们必须为每个内存缓存维护两个副本。一个是用于处理 API 请求的“主动”缓存，另一个是用于数据更新的“被动”缓存。由于应用程序使用无锁算法来降低延迟，因此我们需要保留单独的缓存，并在每个数据更新周期后以原子操作交换它们。 ChronicleMap 的优点之一是它能够以高性能处理并发访问，而不会阻塞。这使我们能够保留堆外缓存的单个副本并在保持低延迟的同时处理高吞吐量请求。我们能够重构并删除围绕维护两个副本并在每次数据更新后交换它们的所有冗余代码。
降低代码复杂性。在使用 ChronicleMap 之前，我们被迫采用多种方法来优化内存利用率，即使要付出额外查找的代价。其中一个例子就是页面类别缓存的布局。由于每个分类的 URL 都分配了不同数量的类别，为了节省内存，我们根据 URL 的分布及其分配的类别数量创建了预先分配内存的存储桶，例如，500 万个 URL 的类别少于 10 个，属于一个存储桶。相比之下，少于 100 万的 URL 最多有 50 个类别，属于另一个存储桶。每个存储桶都是一个 HashMap，其中的键是 URL 哈希，值是连续数组的索引，该数组分为固定数量的类别。如果我们为每个 URL 使用单独的数组，则每个存储桶的大型连续数组旨在大幅减少所需的引用数量。如果没有这个，数百万次引用将大大延长任何完整的垃圾收集过程。还有另一个 HashMap 将 URL 映射到特定的存储桶。此外，正如上文所述，我们必须维护两个副本。我们可以使用更简单的 ChronicleMap 消除所有这些代码复杂性，因为我们不再需要担心内存问题。