elasticsearch - 最终一致性——如何避免幻影

Question

我是这个话题的新手。看了一些文章，问了几个人，还是不明白你们在一个问题上是怎么做的。

有 UI 客户端向多个后端实例发出请求(目前 session 是否具有粘性无关紧要)，并且这些实例连接到一些高度可用的数据库集群(可能是 Cassandra 或 Elasticsearch 的其他东西)。假设后端实例没有专门绑定(bind)到一个或集群的机器，而是它对数据库的每个请求都可能由不同的机器提供服务。一个客户端创建一些记录，它被同步或异步存储到集群的一台机器上，然后最终被复制到其余的数据库机器上。然后另一个客户端请求列表或记录，该请求最终由尚未收到复制更改的远程机器提供服务，因此客户端看不到记录。嗯，这很糟糕，但还不算丑陋。

但是请考虑第二个客户端访问有记录的机器，将其显示在列表中，然后刷新列表，这一次访问远程机器并且再次看不到记录。这是非常奇怪的行为，不是吗？它甚至可能变得更糟:客户端成功请求记录，开始对其进行一些编辑，然后尝试将更新存储到数据库，这一次命中远程机器说“我对您要更新的记录一无所知”。这是用户在做完全合法的事情时会看到的错误。

那么防止这种情况的常见做法是什么？到目前为止，我只看到三种解决方案。

1) 实际上不是一个解决方案而是一个政策:忽略这个问题，而是尽可能地加速集群以保证 99.999% 的更改将在整个集群上复制，例如 0.5 秒(很难想象一些用户会尝试在这段时间内对一条记录发出多个连续请求；他当然可以发出多个读取请求，但在那种情况下他可能不会注意到结果之间的不一致)。即使有时出现问题并且用户面临问题，好吧，我们也接受它。如果失败者不高兴并向我们投诉(可能每周一次或每小时一次)，我们只会道歉并继续。

2) 在用户 session 和特定数据库机器之间引入亲缘关系。这有帮助，但需要 DB 的明确支持，并且还会损害负载平衡，并在 DB 机器出现故障并且 session 需要重新绑定(bind)到另一台机器时引发并发症(但是在 DB 的适当支持下我认为这是可能的; 说 Elasticsearch 可以接受路由 key ，我相信如果目标分片出现故障，它只会将亲和性链接切换到另一个分片 - 尽管我不完全确定；但即使发生重新绑定(bind)，另一台机器也可能包含旧数据:)).

3) 依靠单调一致性，即某种方法可以确保来自客户端的下一个请求将获得不早于前一个请求的结果。但是，据我所知，这种方法还需要 DB 的明确支持，比如能够将一些“全局版本时间戳”传递给集群的平衡器，它将与所有机器时间戳上的最新数据进行比较，以确定哪些机器可以服务请求。

还有其他好的选择吗？还是这三个被认为足够好用？

附言我现在的具体问题是 Elasticsearch； AFAIK 那里不支持单调读取，但看起来选项 #2 可能可用。

Answer 1

Apache Ignite 具有用于 key 的主分区和备份分区。除非您设置了 readFromBackup 选项，否则您将始终从其内容被认为是可靠的主分区读取数据。

如果一个节点消失，事务(或操作)应该由剩余节点传播或回滚。

请注意，Apache Ignite 不执行最终一致性，而是执行强一致性。这意味着您可以观察到节点丢失期间的延迟，但不会观察到不一致的数据。