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 消除所有这些代码复杂性，因为我们不再需要担心内存问题。

6.优点

6.1.更快的启动速度

ChronicleMap 支持将内存缓存持久化到文件中。这样，数据就可以在创建过程结束后继续存在 — 例如，支持热应用程序重新部署。我们利用此功能快速重启应用程序，而无需对我们的缓存层进行 API 调用来加载初始数据。

6.2.共享缓存

在我们当前的设计中，每个 API 后端服务器都维护自己的 ChronicleMap 缓存。ChronicleMap 支持在不同的 JVM 进程之间共享相同的缓存。创建外部服务以将源数据移动到可在多个后端服务器之间共享的单个共置 ChronicleMap 缓存中将有助于我们降低网络利用率。

6.3.自动调整大小

可以自动调整 ChronicleMap 缓存的大小。

7.不足

7.1.根据估算进行预分配

我们评估的版本没有动态调整缓存大小的功能。我们需要预测数据集的增长并预先分配适当的内存量。对于上面提到的页面类别缓存，我们还需要估计每页的平均类别数并使用该数来分配内存。我们必须持续监控这一点以确保我们的假设成立。如果页面类别的分布发生剧烈变化，则需要重新配置和重新部署应用程序。

7.2.基准

当 ChronicleMap 保存的数据可以装入 RAM 中时，其性能最佳。但是，使用磁盘可以保存比 RAM 更大的数据。当数据无法装入 RAM 中时，查找速度会变慢。对各种配置进行基准测试对我们来说并不容易，我们必须构建一个自定义测试应用程序来针对不同场景运行多个测试。

7.3.文档

公开的产品文档并未涵盖所有细节。我们在源代码中发现了多个有用的配置设置，而 Javadoc 文档正是从这些设置中自动生成的。源代码还被划分为许多模块和项目，这让我们发现很难浏览。

7.4.处理自定义值

我们的要求之一是支持多映射，这是一种关联容器，其中可以关联多个值并返回给定键的值。我们必须编写代码来支持这一点。这还需要一个自定义序列化器代码，这是我们自己实现的。后来，我们在代码中发现了另一个可以扩展的类，于是我们改用这个类。不知道它的存在以及如何使用它，这延迟了我们的实现。