Question about distribution transaction

[liugt34]

源码示例 Sample.RabbitMQ.SqlServer 中，将 ValuesController.cs 中的订阅方法 修改如下

[NonAction]
[CapSubscribe("sample.rabbitmq.sqlserver")]
public void Subscriber(Person p)
{
    Console.WriteLine($@"{DateTime.Now} Subscriber invoked, Info: {p}");
    throw new Exception("Test")l
}

但是在 EntityFrameworkWithTransaction 方法中创建的实体仍然入库了，请教下这里的事务要如何才会起作用呢？

[yang-xiaodong]

https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

https://www.cnblogs.com/savorboard/p/cap-auto-transaction.html

[liugt34]

@yang-xiaodong 感谢大佬回复， 是不是可以这么理解：就是这里的事务只是保 当前数据和消息队列数据持久化的事务，并不是不同微服务之间的事务？
不同微服务之间的数据一致性还是需要通过文中提到的补偿机制来维护？

[yang-xiaodong]

在微服务架构中，由于服务间是松耦合的，保证跨服务的事务数据一致性是一个挑战。发件箱模式（Outbox Pattern）是一种解决这一问题的设计模式，它主要用于处理分布式事务，确保数据的最终一致性，而不是强一致性。这种模式特别适用于那些需要在不同微服务之间进行事件驱动通信的场景。

发件箱模式的工作流程

1. 本地事务写入：当一个服务需要执行操作（例如，更新数据库中的数据）并通知其他服务时，它首先在本地数据库中更新业务数据。同时，它还会在同一数据库事务中向一个特殊的“发件箱”表中插入一条记录，这条记录包含了需要传达给其他服务的事件或消息的内容。

2. 事件发布：更新和事件插入操作在同一个数据库事务中完成，这保证了数据的一致性。事务提交后，一个独立的发布者（可以是一个轮询机制、数据库触发器或者日志扫描进程）定期扫描发件箱表，捕获新的事件记录。

3. 事件传播：发布者读取发件箱中的事件，并将其发布到事件总线或消息队列（如Kafka, RabbitMQ等）上。其他微服务订阅这些事件或消息，根据需要进行处理，实现跨服务的业务逻辑。

4. 确认与清理：一旦事件被成功发布到事件总线，相应的发件箱表中的记录可以被标记为已处理或直接删除，以避免重复发送相同的事件。

发件箱模式的优点

• 数据一致性：通过在同一个数据库事务中同时更新业务数据和插入发件箱事件，确保了业务操作和事件通知的一致性。
• 解耦合：服务间通过事件（而非直接调用）进行通信，降低了服务间的耦合度。
• 可靠性：如果事件发布失败，可以重新尝试，直到成功为止，增强了系统的容错能力。
• 顺序保证：通过适当的设计，可以保证事件的顺序性，尤其是对于单一源服务的事件。

发件箱模式是一种有效的策略，用于在保持微服务架构的灵活性和可扩展性的同时，解决跨服务事务数据一致性的问题。正确实施时，它可以大大增强分布式系统的可靠性和维护性。