与AWS兼容的复制缓存解决方案

Question

我的用例如下：

我们在自动扩展EC2集群中运行大约500台服务器，需要每秒数百万次访问相同的配置数据（以键/值方式布局）。

配置数据不是很大（1或2 GB）并且不会发生太大变化（在高峰时段每分钟会有几十次更新/删除/插入）。

延迟对我们至关重要，因此需要复制数据并将其保存在运行应用程序的每个实例的内存中。

最终的一致性很好。但是，我们需要确保每次更新都会在某个时刻传播。 （知道服务器可以随时关闭） 跨服务器的更新传播应该是可靠且易于设置的（我们的服务器不能拥有静态IP，或者我们不想在AWS上伪装＆＃34;伪装＃34;多播等...）

以下是我们过去探索过的解决方案：

• 使用常规Java映射并使用我们的自定义构建系统在集群中传播更新。 （显然，它没有那么好地扩展）
• 使用EhCache及其复制功能。但是在EC2上设置它是非常痛苦的，并且在某种程度上是不可靠的。

以下是我们考虑尝试的解决方案：

• Apache Ignite（https://ignite.apache.org/），带有REPLICATED策略。
• Hazelcast的复制地图功能。 （http://docs.hazelcast.org/docs/latest/manual/html-single/index.html#replicated-map）
• 每个应用程序节点上的Apache Geode。 （http://geode.apache.org/）

我想知道这些解决方案是否适用于我们的用例。最终，我可能会遇到哪些问题。

这是我到目前为止所发现的：

• Hazelcast的复制地图在某种程度上是最近的，但仍然有点不可靠（如果缩小，异步更新可能会丢失）
• 好像Geode变得稳定＆＃34;最近（即使它自2000年代初以来一直处于开发阶段）
• Ignite看起来很合适，但如果我们不断定期添加/删除节点，我不太清楚他们的基于S3发现的系统将如何运作。

谢谢！

Answer 1

Geode应该适用于您的用例。您应该能够在每个节点上使用Geode Replicated区域。您可以选择执行同步或异步复制。如果出现故障，复制区域将从系统中的现有成员获取数据的初始副本，同时确保不会丢失正在进行的操作。

在配置方面，您必须启动几个/几个成员发现过程（Geode定位器）并将每个成员指向这些定位器。 （我们建议您启动一个定位器/ AZ并使用3个AZ来防止网络分区。）

Geode / GemFire已经稳定了一段时间;在很长一段时间内为印度和中国铁路的预订系统提供低延迟，高可扩展性要求。

披露：我是Geode的提交者。

Answer 2

Ignite为S3存储上的发现提供本机AWS集成：https://apacheignite-mix.readme.io/docs/amazon-aws。它解决了主要问题 - 您不需要在重新启动实例时更改配置。简而言之，任何成功连接拓扑的节点都会将其坐标写入存储桶（并在发生故障或离开时将其删除）。当您启动一个新节点时，它会读取此存储桶并连接到列出的地址之一。

Answer 3

Hazelcast的复制地图不适用于您的用例。请注意，它是一个映射，它复制在不在客户端节点/服务器上的所有节点上。另外，正如你所说，它还不完全可靠 以下是Hazelcast解决方案：

1. 根据数据大小创建一个包含一组节点的Hazelcast集群。
2. 创建分布式地图（IMap）并调整计数＆amp;基于键/值对的大小/数量的驱逐配置。数据在所有节点之间进行分区。
3. 设置备份计数基于数据的重要程度以及从实际源（DB /文件）中提取数据所需的时间。默认情况下，分布式地图有1个备份。
4. 在客户端，设置NearCache并将其附加到分布式地图。此NearCache将保留本地/客户端本身的键/值对。因此，get操作将以毫秒结束。

NearCache解决方案需要考虑的事项：

• 第一次获取操作会变慢，因为它必须通过网络才能从群集中获取数据。
• 缓存失效不完全可靠，因为与群集同步会有延迟，并且可能会结束读取陈旧数据。同样，所有缓存解决方案都是如此。
• 设置Nearcache条目的超时和失效是客户的责任。因此，未来的拉动将从集群中获取新数据。这取决于数据刷新的频率或替换密钥的值。