标签：接收   分布式事务   订单状态   edit   自己的   不同   本地事务   uem   更改   

架构模式: Saga

上下文

您已应用每服务数据库模式。每个服务都有自己的数据库。但是，某些业务事务跨越多个服务，因此您需要一种机制来确保服务之间的数据一致性。例如，假设您正在建立一个客户有信用额度的电子商务商店。申请必须确保新订单不会超过客户的信用额度。由于订单和客户位于不同的数据库中，因此应用程序不能简单地使用本地ACID事务。

问题

如何跨服务维护数据一致性？

要点

• 可以不选择2PC

结论

实现跨越多个服务的每个业务事务作为传奇。传奇是一系列本地交易。每个本地事务都更新数据库并发布消息或事件以触发saga中的下一个本地事务。如果本地事务因违反业务规则而失败，则saga会执行一系列补偿事务，以撤消先前本地事务所做的更改。

?

协调sage有两种方式：

• Choreography - 每个本地事务发布触发其他服务中的本地事务的域事件
• Orchestration - 一个orchestrator（上帝对象）告诉参与者要执行的本地事务

例子: Choreography-based saga

?
使用此方法的电子商务应用程序将使用基于 Choreography-based saga创建订单，包含以下步骤：

1. Order Service创建处于挂起状态的订单并发布OrderCreated事件
2. Customer Service收到事件尝试为该订单保留信用。它发布Credit Reserved事件或CreditLimitExceeded事件。
3. Order Service接收事件并将订单状态更改为已批准或已取消

例子: Orchestration-based saga

?
使用此方法的电子商务应用程序将使用基于Choreography-based saga创建订单，包含以下步骤：

1. Order Service创建处于暂挂状态的订单并创建CreateOrderSaga
2. CreateOrderSaga向Customer Service 发送ReserveCredit命令
3. Customer Service尝试为该订单保留信用额并发回回复
4. CreateOrderSaga接收回复并向Order Service发送ApproveOrder或RejectOrder命令
5. Order Service将订单状态更改为已批准或已取消

结论上下文

这种模式具有以下好处：

• 它使应用程序能够跨多个服务维护数据一致性，而无需使用分布式事务

该解决方案具有以下缺点：

• 编程模型更复杂。例如，开发人员必须设计补偿事务，以明确撤消先前在saga中所做的更改。

还有以下问题需要解决：

• 为了可靠，服务必须以原子方式更新其数据库并发布消息/事件。它不能使用跨越数据库和消息代理的分布式事务的传统机制。相反，它必须使用下面列出的模式之一。

关联模式

• 每个服务独立数据库模式创建了对此模式的需求
• 以下模式是以原子方式更新状态和发布消息/事件的方法：
  • 事件溯源
  • 交易发件箱
• 基于Choreography可以使用聚合和域事件发布事件

架构模式: Saga

标签：接收   分布式事务   订单状态   edit   自己的   不同   本地事务   uem   更改   

原文地址：https://www.cnblogs.com/paxlyf/p/11290604.html