请教一些问题

[normalcc01]

• 怎么使用dubbo进行测试
• 项目的时序图是怎样的

[funky-eyes]

直接集成即可，里面直接搬了seata的事务传播，会启用dubbo的filter spi，自动传递 顺序是，发起事务的client执行完毕后，会进行发布一条广播消息给参与的client，参与的client会判断自己内部是否保持了该事务的连接，如果有就提交 目前有缺陷，第一用的lcn的方式，留住了连接，有可能会突然宕机，数据不一致 目前一致在贡献seata，没时间维护这个项目，对后续的设想就是搬seata-xa的代码，去掉对seata tc的依赖相关代码，直接用xa协议，这样不怕宕机 设计如下 发起方会先发一个延时消息给rocketmq（通知事务rollback（也就是事务超时）），这个延迟消息如果再广播消息到达之后发送，对事务不会有影响，所以没任何问题 然后正常的事务传播，发起方接口结束，发一个提交的广播给其他的参与方，此时根据这个广播内容进行对xa事务的回滚或提交

[funky-eyes]

欢迎随时留言继续探讨

[normalcc01]

感谢回复！我是一名在校大学生，最近才接触分布式事务，可能有些分布式相关知识不太了解，望包容。 您说参考了LCN的实现逻辑；我如下的理解不知道对不对，请指教。

1、该项目是用XID作为一次全局事务的标识，使用RootContext.bind()方法将所有发起者，参与者绑定到同一事务中；对应LCN中创建和加入事务组的动作； 2、发起者发送一条广播消息到MQ；对应发起者通知事务组TxManger。只有@GlobalTransaction标注的发起者才会发送消息，而且只会发送一次？ 3、订阅该主题的MQ的消费者（也就是全局事务的参与者）在收到广播消息后，会执行真正的事务提交动作；对应TxManger通知事务单元。那事务单元响应的信息返回给TxManger的逻辑因为使用RocketMq来保证消息被消费的可靠性不需要去实现是吗？

[funky-eyes]

感谢回复！我是一名在校大学生，最近才接触分布式事务，可能有些分布式相关知识不太了解，望包容。 您说参考了LCN的实现逻辑；我如下的理解不知道对不对，请指教。

1、该项目是用XID作为一次全局事务的标识，使用RootContext.bind()方法将所有发起者，参与者绑定到同一事务中；对应LCN中创建和加入事务组的动作； 2、发起者发送一条广播消息到MQ；对应发起者通知事务组TxManger。只有@GlobalTransaction标注的发起者才会发送消息，而且只会发送一次？ 3、订阅该主题的MQ的消费者（也就是全局事务的参与者）在收到广播消息后，会执行真正的事务提交动作；对应TxManger通知事务单元。那事务单元响应的信息返回给TxManger的逻辑因为使用RocketMq来保证消息被消费的可靠性不需要去实现是吗？

可以这么说，但是广播消息不一定可靠，后续有空的话，思路是改造成队列，而不是走广播，每个参与方都是一个单独的group，所以可以保证一条消息被多个group消费，保证了事务的提交，把可靠消息的保证交给了用户搭建的mq系统，理论上只要提交报错，这个消息的offset是不会提交，也就会重试消费，消息只要没过期就可以保证后续能继续受到消息，进行提交 目前这个设计模型就是允许最终一致性（mq消息会重试）， 还是属于base的一个理论，因为消息发出后，事务的提交存在异步化，导致了虽然tm响应给了请求方，但是请求方此时查看的数据可能还没实际提交