Bughue opened a new pull request, #6230: URL: https://github.com/apache/incubator-seata/pull/6230
<!-- Please make sure you have read and understood the contributing guidelines --> - [ ] I have registered the PR [changes](../changes). ### Ⅰ. Describe what this PR did 集成rocketmq到seata。 #### 关于总体解决思路： 请注意，这个pr的思路和summer-code已有pr稍有不同：之前的pr是代理producer的所有方法（利用rocketmq的事务特性+seataTCC），我觉这样不妥，有3个重要原因 1.用户有可能在全局事务内依然希望发送普通的消息（也就是消息本身不受事务管理，直接发送并等待消费） 2.rocketmq的producer代码在后续版本可能有更新，我们硬编码代理所有方法，并跟随他做改变并不是明智选择。 3.把rocketmq的消息的发送动作作为seata的一阶段，把事务消息的executeLocalTransaction作为一阶段似乎更为合理 为此我提议只代理TransactionMQProducer类型的两个sendMessageInTransaction方法即可，这样用户如果在seata全局事务内使用了消息事务，这个过程在本地执行成功后会进入seata的全局事务托管。 #### 关于具体实现方案及时序： 利用已有的InterfaceParser代理机制去代理TransactionMQProducer类型的bean，重写sendMessageInTransaction。 程序流程： 1.rocketmq按发送半消息（和rocketmq原有逻辑一样） 2.执行本地事务executeLocalTransaction/executeLocalTransactionBranch（和rocketmq原有逻辑一样） 3.如果state=成功，强行改回unknown，等待seata-TC调用rm决定二阶段。否则都将直接rollback这个消息（因为seata目前无法支持rm一阶段回查能力） #### 细节讨论（包括summer-code-pr原有的讨论） 1.关于TCCRocketMQ的applicationData是否应该带有message：应该要带上，否则二阶段时无法回传给broker（这是rocketmq要求的） 2.关于半消息发送后宕机的一致性问题：和之前的pr问题是一样的，我建议是直接配置一个超时时间解决，在发送消息的时候加入发送时间戳，这样在broker回查的时候就可以判断是否超时了。 Integrating rocketmq into seata. #### About the general solution idea: Note that the idea of this pr is slightly different from summer-code's existing pr: the previous pr proxied all the methods of the producer (utilizing the transactional nature of rocketmq + seataTCC), which I feel is inappropriate for 3 important reasons 1. it is possible for a user to still want to send a normal message within a global transaction (i.e. the message itself is not managed by the transaction, it is sent directly and waits to be consumed) 2. rocketmq's producer code may be updated in subsequent versions, and it's not wise to hard-code all the methods of the proxy and follow the changes. 3. It seems more reasonable to consider the send action of a rocketmq message as a stage of seata, and the executeLocalTransaction of a transactional message as a stage. For this reason I propose to proxy only the two sendMessageInTransaction methods of the TransactionMQProducer type, so that if the user uses a message transaction within the seata global transaction, the process will enter the global transaction hosting of the seata after successful local execution. #### On the specific realization of the program and the time sequence: Utilize the existing InterfaceParser proxy mechanism to proxy the bean of type TransactionMQProducer and rewrite sendMessageInTransaction. Program flow: 1. rocketmq press send half a message (and rocketmq original logic is the same) 2. Execute local transaction executeLocalTransaction/executeLocalTransactionBranch (and rocketmq original logic is the same) 3. If state=success, force change back to unknown, wait for seata-TC to call rm to decide the second stage. Otherwise all will directly rollback this message (because seata currently can not support rm one-phase checkback ability) #### Detailed discussion (including the original discussion of summer-code-pr) 1. about TCCRocketMQ applicationData should be with message or not: it should be with message, otherwise it can not be passed back to the broker in the second stage (which is required by rocketmq) 2. on the consistency of the half-message sent after the downtime problem: and the previous pr problem is the same, my suggestion is to directly configure a timeout time to solve the problem, in the message sent to send a message to add the send timestamp, so that in the broker back to check the time to determine whether the timeout. ### Ⅱ. Does this pull request fix one issue? <!-- If that, add "fixes #xxx" below in the next line, for example, fixes #97. --> fixes https://github.com/apache/incubator-seata/issues/3752 ### Ⅲ. Why don't you add test cases (unit test/integration test)? ### Ⅳ. Describe how to verify it ### Ⅴ. Special notes for reviews -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
