事务性消息传递

Transactional Messaging 

 

 

A service command usually needs to create/update/delete aggregations in the database and send messages/events to a message broker. For example, a service participating in an epic needs to update business entities and send messages/events. Similarly, a service that publishes a domain event needs to update a total and publish an event.To avoid data inconsistencies and errors, the command must atomically update the database and send messages. However, using a traditional distributed transaction (2PC) involving the database and the message broker is not feasible. The database and/or message broker may not support 2PC. And even if they do, connecting the service to both the database and the message broker is often undesirable.However, sending messages in the middle of a transaction is unreliable without using 2PC. There is no guarantee that the transaction will occur. Similarly, if a service sends a message after committing the operation, there is no guarantee that it will not crash before sending the message.Additionally, messages must be sent to the message broker in the order they were sent by the service. They generally need to be delivered to each consumer in the same order, although this is beyond the scope of the model. For example, a total can be a set of T1 transactions, etc. Let’s assume it was updated by. T2These operations can be performed by the same service instance or by different service instances. Each process broadcasts a corresponding event: T1 -> E1, T2 -> E2, etc. Since T1 is before T2, the event E1 must be published before E2.

事务性消息传递

服务命令通常需要在数据库中创建/更新/删除聚合，并将消息/事件发送到消息代理。例如，参与长篇故事的服务需要更新业务实体并发送消息/事件。同样，发布域事件的服务需要更新总数并发布事件。为了避免数据不一致和错误，该命令必须以原子方式更新数据库并发送消息。但是，使用涉及数据库和消息代理的传统分布式事务 （2PC） 是不可行的。数据库和/或消息代理可能不支持 2PC。即使他们这样做了，将服务连接到数据库和消息代理通常也是不可取的。但是，如果不使用 2PC，在交易过程中发送消息是不可靠的。不保证交易会发生。同样，如果服务在提交操作后发送消息，则不能保证在发送消息之前不会崩溃。此外，消息必须按照服务发送的顺序发送到消息代理。它们通常需要以相同的顺序交付给每个消费者，尽管这超出了模型的范围。例如，总计可以是一组 T1 事务等。让我们假设它是由更新的。T2这些操作可以由同一服务实例执行，也可以由不同的服务实例执行。每个进程广播相应的事件：T1 -> E1、T2 -> E2 等。由于 T1 位于 T2 之前，因此事件 E1 必须在 E2 之前发布。