例如amazon.com；他们依赖于微服务架构，订单和付款可能是单独的微服务，但是当您在 amazon.com 上结帐订单时，您最终可以看到订单 ID 和详细信息。如果不是最终一致性方法，那是什么？也许2PC？
我正在概括我的问题；如果最终的一致性不是
适用于商业交易(最终用户应该看到交易结束的结果)但单独的微服务是有意义的(如订单和支付)
如何处理即时一致性？
最佳答案
有几种技术可以提供跨服务事务(原子性):2PC、Percolator 的事务和 Sagas。
Percolator's transactions具有可序列化的隔离级别。他们在业内享有盛誉，参见:亚马逊的DynamoDB transaction library , CockroachDB database ，以及 Google 的 Pecolator 系统本身。 A step-by-step visualization Percolator 的交易记录可能会帮助您了解它们的工作原理。
传奇模式在 80 年代后期的 Sagas 中有所描述。论文，但随着微服务的兴起变得更加相关。请查看 Applying the Saga Pattern谈论灵感。
但是，既然您提到了最终一致性，请务必注意所有技术都需要单个服务可线性化(强一致性)并支持比较和设置。
关于microservices - 如何在微服务架构中实现即时一致性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46696171/