本文讨论处理最终一致性的三种模式，并通过实际例子进行说明。
假设您有两个服务：
- 订单
- 发票
当客户下订单时，您必须生成相关发票。
1. 后台同步模式
- 您保存订单，然后在后台更新/创建发票。
- 计划调度中的工作者worker检查新的或更改的订单并创建或更新发票。
这种方法解耦了服务并减少了面向用户的服务（订单服务）的延迟。
您可以获得最终一致性，但由于后台作业按照特定的时间表运行，因此速度会比较慢。
2. 基于请求的编排模式
- 您保存订单并将其发送到发票服务以立即生成发票。
- 它需要一些 Orchestrator 服务，可以是单独的服务，也可以是现有的服务。
与之前的模式不同，该模式尝试处理整个分布式事务。
但是，一旦我们参与任何类型的分布式事务，我们就需要讨论补偿事务。如果出现故障，将执行补偿事务来恢复更改。
3.基于事件的模式
基于事件的更为先进，需要更多的基础设施，当然，还有更多的可观察性。
- 服务发出事件，其他服务监听这些事件以更新其数据。
- 在这种情况下，您保存订单并发出“订单创建”事件。
- 发票服务监听这些事件并根据订单创建新的发票。
这些服务不需要互相了解，并且可以独立扩展。
总结
- 后台同步提供了简单性并使服务解耦，但引入了数据一致性的延迟。
- 精心策划的请求-响应提供了可靠的受控流程，但增加了响应时间。
- 基于事件带来松散的耦合和可扩展性，并允许服务以复杂性为代价对变化做出反应。
最终一致性是获得更好的性能、可扩展性和可用性的代价。