Open normalcc01 opened 2 years ago
直接集成即可,里面直接搬了seata的事务传播,会启用dubbo的filter spi,自动传递 顺序是,发起事务的client执行完毕后,会进行发布一条广播消息给参与的client,参与的client会判断自己内部是否保持了该事务的连接,如果有就提交 目前有缺陷,第一用的lcn的方式,留住了连接,有可能会突然宕机,数据不一致 目前一致在贡献seata,没时间维护这个项目,对后续的设想就是搬seata-xa的代码,去掉对seata tc的依赖相关代码,直接用xa协议,这样不怕宕机 设计如下 发起方会先发一个延时消息给rocketmq(通知事务rollback(也就是事务超时)),这个延迟消息如果再广播消息到达之后发送,对事务不会有影响,所以没任何问题 然后正常的事务传播,发起方接口结束,发一个提交的广播给其他的参与方,此时根据这个广播内容进行对xa事务的回滚或提交
欢迎随时留言继续探讨
感谢回复!我是一名在校大学生,最近才接触分布式事务,可能有些分布式相关知识不太了解,望包容。
您说参考了LCN的实现逻辑;我如下的理解不知道对不对,请指教。
1、该项目是用XID
作为一次全局事务的标识,使用RootContext.bind()
方法将所有发起者,参与者绑定到同一事务中;对应LCN中创建和加入事务组的动作;
2、发起者发送一条广播消息到MQ;对应发起者通知事务组TxManger
。只有@GlobalTransaction
标注的发起者才会发送消息,而且只会发送一次?
3、订阅该主题的MQ的消费者(也就是全局事务的参与者)在收到广播消息后,会执行真正的事务提交动作;对应TxManger
通知事务单元。那事务单元响应的信息返回给TxManger
的逻辑因为使用RocketMq来保证消息被消费的可靠性不需要去实现是吗?
感谢回复!我是一名在校大学生,最近才接触分布式事务,可能有些分布式相关知识不太了解,望包容。 您说参考了LCN的实现逻辑;我如下的理解不知道对不对,请指教。
1、该项目是用
XID
作为一次全局事务的标识,使用RootContext.bind()
方法将所有发起者,参与者绑定到同一事务中;对应LCN中创建和加入事务组的动作; 2、发起者发送一条广播消息到MQ;对应发起者通知事务组TxManger
。只有@GlobalTransaction
标注的发起者才会发送消息,而且只会发送一次? 3、订阅该主题的MQ的消费者(也就是全局事务的参与者)在收到广播消息后,会执行真正的事务提交动作;对应TxManger
通知事务单元。那事务单元响应的信息返回给TxManger
的逻辑因为使用RocketMq来保证消息被消费的可靠性不需要去实现是吗?
可以这么说,但是广播消息不一定可靠,后续有空的话,思路是改造成队列,而不是走广播,每个参与方都是一个单独的group,所以可以保证一条消息被多个group消费,保证了事务的提交,把可靠消息的保证交给了用户搭建的mq系统,理论上只要提交报错,这个消息的offset是不会提交,也就会重试消费,消息只要没过期就可以保证后续能继续受到消息,进行提交 目前这个设计模型就是允许最终一致性(mq消息会重试), 还是属于base的一个理论,因为消息发出后,事务的提交存在异步化,导致了虽然tm响应给了请求方,但是请求方此时查看的数据可能还没实际提交