1.RocketMQ的原理与架构：
一.作为消息中间件的架构图：(摘自RocketMQ官网)
官网地址：http://rocketmq.apache.org/docs/quick-start/
架构原理：
说明：NameServer类似于注册中心概念(相当于kafka的zk)，但是这个跟zk有点 不同的是:zk是中心化的，而nameserver是去去中心化
1.启动nameserver之后，会去监听端口,等待broker、consumer、producer进行连接
2.broker启动之后，会跟所有的nameserver建立长连接,并定时的发送心跳，心跳包中包含着broker的ip、端口以及topic消息（检测当前broker是否可用）,注册成功之后，nameserver包含了broker与topic的映射关系。
3.消息发送：producer启动时，跟某一台的nameserver保持长连接，并从nameserver中获取当前topic存在的与之对应的broker信息，然后跟broker建立长连接，发送消息（topic可以事先创建，或者发送时如果当前topic不存在，则会自动创建）
4.消息消费：消息消费过程其实跟发送过程类似,都是通过跟nameserver建立连接,然后通过topic找到相对应的broker建立长连接,然后开始消费消息.
二、RocketMQ作为解决分布式事务的架构与原理图：
1.架构图：
2.RocketMQ实现事务消息主要分为两个阶段：正常事务的发送及提交、事务信息的补偿流程 整体流程为：
1）正常事务的发送及提交：
①.发送方首先户发送一个半消息发送到broker当中，标识该消息是不能够被消费的，同时需要实现RocketMQLocalTransactionListener接口
②.broker接收到消息之后，然后发送方会执行一个Listener方法中的本地事物方法(executeLocalTransaction),根据本地事物的执行状态执行commit、rollback
③.broker收到本地提交的状态值之后，将消息标识成可以消费，然后消息者进行消费
2).如果broker长时间未收到本地事务状态（事务的一个补偿）--解决生产者在发送Commit或者Rollback操作时发生超时或失败的情况。
①.如果broker未收到，broker会向发送一个确定回查的接口checkLocalTransaction确定回查的操作请求
②.生产者接收到回查消息之后，检查本地事务的一个状态；
③.根据本地事务的检查接口执行Commit、rollback、unknow。