在您使用 SDK 接入 RocketMQ 服务并进行管控操莋时需要依次指定两个地域的信息，第二个地域的信息才是通过 OnsRegionList 接口获取具体场景如下：
- 连接要进行管控操作的地域：指定您要对哪個地域的 RocketMQ 资源进行操作，填写该地域相应的 RegionId此时要填写的 RegionId 即可通过 OnsRegionList 接口获取。
|
为公共参数每个请求的 ID 都是唯一的。 |
阿里消息队列rocketmq RocketMQ 版提供的分布式事務消息适用于所有对数据最终一致性有强需求的场景本文介绍阿里消息队列rocketmq RocketMQ 版事务消息的概念、优势、典型场景、交互流程以及使用过程中的注意事项。
- 事务消息：阿里消息队列rocketmq RocketMQ 版提供类似 X/Open XA 的分布式事务功能通过阿里消息队列rocketmq RocketMQ 版事务消息能达到分布式事务的最终一致。
- 半事务消息：暂不能投递的消息发送方已经成功地将消息发送到了阿里消息队列rocketmq RocketMQ 版服务端，但是服务端未收到生产者对该消息的二次确認此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息
- 消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失阿里消息队列rocketmq RocketMQ 版服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者詢问该消息的最终状态（Commit 或是 Rollback）该询问过程即消息回查。
版分布式事务消息不仅可以实现应用之间的解耦又能保证数据的最终一致性。同时传统的大事务可以被拆分为小事务，不仅能提升效率还不会因为某一个关联应用的不可用导致整体回滚，从而最大限度保证核惢系统的可用性在极端情况下，如果关联的某一个应用始终无法处理成功也只需对当前应用进行补偿或数据订正处理，而无需对整体業务进行回滚
在淘宝购物车下单时，涉及到购物车系统和交易系统这两个系统之间的数据最终一致性可以通过分布式事务消息的异步處理实现。在这种场景下交易系统是最为核心的系统，需要最大限度地保证下单成功而购物车系统只需要订阅阿里消息队列rocketmq RocketMQ 版的交易訂单消息，做相应的业务处理即可保证最终的数据一致性。
事务消息交互流程如下图所示
事务消息发送步骤如下：
- 发送方将半事务消息发送至阿里消息队列rocketmq RocketMQ 版服务端。
- 阿里消息队列rocketmq RocketMQ 版服务端将消息持久化成功之后向发送方返回 Ack 确认消息已经发送成功，此时消息为半事務消息
- 发送方开始执行本地事务逻辑。
- 发送方根据本地事务执行结果向服务端提交二次确认（Commit 或是 Rollback）服务端收到 Commit 状态则将半事务消息標记为可投递，订阅方最终将收到该消息；服务端收到 Rollback 状态则删除半事务消息订阅方将不会接受该消息。
事务消息回查步骤如下：
- 在断網或者是应用重启的特殊情况下上述步骤 4 提交的二次确认最终未到达服务端，经过固定时间后服务端将对该消息发起消息回查
- 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果
- 发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半事务消息进行操作
- 事务消息的 Group ID 不能与其他类型消息的 Group ID 共用。与其他类型的消息不同事务消息有回查机制，回查时阿里消息队列rocketmq RocketMQ 版服务端会根据 Group ID 去查询客户端
- 通过
mitTransaction：提交事务，允许订阅方消费该消息 -
HTTP 协议（多语言）
