RocketMQ分布式事务原理介绍

RocketMQ实现分布式事务原理

1.知识准备
在系统架构从单体到分布式、SOA、微服务的发展过程中，因为流量的增多出现了大量消息堆积问题的需求，在这种背景下，阿里开发出rocketmq来解决该问题，并且经过双十一的考验，在低延迟和高可靠性方面优于kafka,很好的应用在海量消息系统中。

异步解耦：一个大的交易系统中会有一些核心业务系统和非核心业务系统，每笔交易会与上下游交易系统进行交互，比如在下单的过程中会有物流/积分/优惠券等，整个业务系统庞大复杂，rocketmq通过异步通信和应用解耦，目的就是为了不让非核心的业务系统影响核心的业务系统运行而失去用户。

削峰填谷：比如某应用的处理能力是每秒 10 个请求。在某一秒，突然到来了 30 个请求，而接下来两秒，都没有请求到达。在这种情况下，如果直接拒绝 20 个请求，应用在接下来的两秒就会空闲。所以，需要把请求突刺均摊到一段时间内，让系统负载保持在请求处理水位之内，同时尽可能地处理更多请求，从而起到“削峰填谷”的效果。Rocketmq可提供这种削峰填谷的服务来解决这种问题。

分布式事务一致性：比如在分布式系统的交易过程中，下单的用户有红包、优惠券等优惠，多个数据源事务，这种场景引入rocketmq既可以实现系统之间的解耦还可以保证最终的数据一致性。

Name Server 可集群部署，节点之间无任何信息同步。提供服务发现和路由 ； Broker(消息中转角色，负责存储消息，转发消息) 部署相对复杂，Broker 分为Master 与Slave，一 个Master 可以对应多个Slave，但是一个Slave 只能对应一个Master，Master 与Slave 的对应关系通过 指定相同的BrokerName，不同的BrokerId来定 义，BrokerId为0 表示Master，非0 表示Slave。 Producer，生产者，拥有相同 Producer Group 的 Producer 组成一个集群， 与Name Server 集群 中的其中一个节点（随机选择）建立长连接，定期从Name Server 取Topic 路由信息，并向提供Topic 服务的Master 建立长连接，且定时向Master 发送心跳。Producer 完全无状态，可集群部署； Consumer，消费者，接收消息进行消费的实例，拥有相同 Consumer Group 的 Consumer 组成 一个集群，与Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从Name Server 取 Topic 路由信息，并向提供Topic 服务的Master、Slave 建立长连接，且定时向Master、Slave 发送心 跳。Consumer既可以从Master 订阅消息，也可以从Slave 订阅消息，订阅规则由Broker 配置决定。

长链接：C、S建立连接，不断开，报文发送、接收通讯连接一直存在； 短链接：C、S每进行一次报文收发交易时才建立链接，交易完后立即断开。

首先来看本地通讯的情况，应用程序A和应用程序B运行于同一系统1，它们之间可以借助消息队列技术进行彼此的通讯：应用程序A向队列1发送一条信息，而当应用程序B需要时就可以得到该信息。 其次是远程通讯的情况，如果信息传输的目标改为在系统2上的应用程序C，这种变化不会对应用程序A产生影响，应用程序A向队列2发送一条信息，系统1的MQ发现Q2所指向的目的队列实际上位于系统2，它将信息放到本地的一个特殊队列——传输队列(Transmission Queue)。建立一条从系统1到系统2的消息通道，消息通道代理将从传输队列中读取消息，并传递这条信息到系统2，然后等待确认。只有MQ接到系统2成功收到信息的确认之后，它才从传输队列中真正将该信息删除。如果通讯线路不通，或系统2不在运行，信息会留在传输队列中，直到被成功地传送到目的地。这是MQ最基本而最重要的技术–确保信息传输，并且是一