Design patterns 与一个数据库的最终一致性

最终一致性是否仅包括数据复制（相同数据的副本）：

举一个没有相同数据副本的例子：

• 我只有一个数据库
• 我有一个执行动作的微服务。比如说我把钱存入我的银行账户。本例中的微服务只处理存储您的存款和取款，而与您的帐户无关
• 当微服务A完成时，它会与微服务B进行通信，告知需要更新帐户上的余额
• Microservice B更新帐户余额

在本例中，存款与账户更新余额之间有一段时间，余额将“不正确”

---

这是一个最终一致性的例子吗？尽管只有一个数据库，但我的数据不会立即反映全部情况……但它最终会……：）

您可以轻松实现与单个数据库的最终一致性。让我们省去涉及金钱交易的例子，因为这似乎会引起许多感觉和意见

相反，考虑一个跟踪在线游戏的数据库。无论何时赢得比赛，数据库都会立即存储比赛结果。它还会在异步发布/订阅总线上发布包含结果信息的事件

一个订阅者获取信息，并可能使用它来更新排行榜

这是一种常见的性能优化，因为您不想同时写入排行榜表格，从而减慢游戏状态的更新速度。而且，您可能也不希望将排行榜建立在对所有匹配结果的直接查询上，因为这可能需要一个完整的表扫描（除非结果表是按分数排序的）

在发送异步消息的过程中，系统中可能存在不一致的情况，其中排行榜没有反映最新的结果

事实上，如果你想象有足够的竞争，当排行榜更新时，一个新的高分可能会通过消息总线出现。想象一下，这种情况一直在发生。这样的系统可能永远不会达到一致状态，但我们仍然称之为最终一致，因为如果您设想停止所有外部活动并让系统排出所有异步队列，它最终将进入一致状态

---

上面的示例基于异步和一些非规范化，但在这种情况下，即使在单个数据库上，您也可以轻松设计最终一致的系统。

尤其是在处理金钱时，您的数据库需要具有事务一致性。一个微服务应该进行存款、取款和维持余额，以便数据库更新可以同时成功或失败。我认为你不会找到这个问题的权威答案。对于那些致力于解决非常棘手的分布式存储问题的读者来说，这几乎肯定不是“最终一致性”。但在其他更慷慨地使用这些词汇的社区，为什么不呢？非常好的例子，谢谢。