1

我的用例如下：

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

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

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

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

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

  • 使用常规的 java 映射并使用我们定制的系统在集群中传播更新。（显然，它不能很好地扩展）
  • 使用 EhCache 及其复制功能。但是在 EC2 上设置它非常痛苦，而且不知何故不可靠。

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

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

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

  • Hazelcast 的复制地图在某种程度上是最近的，但仍然有点不可靠（如果缩小，异步更新可能会丢失）
  • 似乎 Geode 最近变得“稳定”了（尽管据说它自 2000 年代初就在开发中）
  • Ignite 看起来很合适，但我不太确定如果我们继续定期添加/删除节点，他们基于 S3 发现的系统将如何工作。

谢谢！

4

3 回答 3

3

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

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

Geode/GemFire 已经稳定了一段时间；长期以来，为印度和中国铁路以及其他用户的预订系统提供低延迟高可扩展性要求。

披露：我是 Geode 的提交者。

于 2017-02-15T00:36:12.187 回答
1

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

于 2017-02-15T00:44:49.563 回答
1

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

  1. 根据数据大小创建具有一组节点的 Hazelcast 集群。
  2. 创建一个分布式映射（IMap）并根据键/值对的大小/数量调整计数和驱逐配置。数据在所有节点上进行分区。
  3. 根据数据的重要性以及从实际源（数据库/文件）中提取数据所需的时间设置备份计数。分布式地图默认有 1 个备份。
  4. 在客户端，设置 NearCache 并将其附加到分布式地图。这个 NearCache 将在本地/客户端本身中保存键/值对。因此，get 操作将在几毫秒内结束。

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

  • 第一次获取操作会比较慢，因为它必须通过网络从集群中获取数据。
  • 缓存失效并不完全可靠，因为与集群同步会有延迟，并且可能会结束读取陈旧数据。同样，所有缓存解决方案都是相同的情况。
  • 设置 Nearcache 条目的超时和失效是客户的责任。这样未来的 pull 就会从集群中获得新的数据。这取决于数据刷新的频率或键值被替换的频率。
于 2017-02-17T07:38:21.057 回答