RocketMQ消息队列（一）—— 基本概念和消息类型

  RocketMQ是一个来自阿里巴巴的分布式消息中间件，于2012年开源，并在2017年正式成为Apache顶级项目。据了解，包括阿里云上的消息产品以及收购的子公司在内，阿里集团的消息产品全线都运行在RocketMQ上，并且最近几年的双十一大促中，RocketMQ都有十分优秀的表现。Apache RocketMQ 4.3以后得版本正式支持事务消息，为分布式事务实现提供便利性支持。

一、RocketMQ的基本概念

  RocketMQ是一个分布式的消息中间件架构，其主要角色的关系如下图所示：

角色介绍如下：

• Producer：消息的发送者
• Consumer：消息接收者
• Broker：暂存和传输消息，RocketMQ中实现消息暂存和发送消息的主要单元
• NameServer：管理Broker的模块
• Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic，一个消息的接受者可以接收一个或者多个Topic
• Message Queue：相当与topic的分区；用于并发发送和接收消息。

二、RocketMQ的消息类型

1、按照发送的特点分类

1）同步发送

• 同步发送，现成阻塞，投递completes阻塞结束
• 如果发送失败，会在默认的超时时间3s内进行重试，最多重试2次
• 投递completes不代表投递成功，要check SendResult.sendStatus来判断是否投递成功
• SendResult里面有发送状态的枚举；SendStatus，同步的消息投递有一个状态返回的值

public enum SendStatus {
	SEND_OK,
	FLUSH_DISK_TIMEOUT,
	FLUSH_SLAVE_TIMEOUT,
	SLAVE_NOT_AVAILABLE,
}

• retry的实现原理：只有ack的SendStatus=SEND_OK才会停止retry
• 发送同步消息且Ack为SEND_OK，只代表该消息成功的写入了MQ中，并不代表该消息成功被Consumer消费了

2）异步发送

• 异步调用的话，当前线程一定要等待异步线程回调结束再关闭producer，以为是异步的，不会阻塞，提前关闭producer会导致未回调连接就断开了。
• 异步消息不回retry，投递失败回调onException()方法，只有同步消息才会retry
• 异步发送一般用于链路耗时较长，对RT响应时间较为敏感的业务场景，例如用户视频上传后通知启动转码服务，转码完成后通知推送转码结果等。

3）单向发送

• 消息不可靠，性能高，只负责往服务器发送一条消息，不会重试也不关心是否发送成功
• 此方式发送消息的过程耗时非常短，一般在微妙级

三种发送方式的主要区别

发送方式	发送TPS	发送结果反馈	可靠性
同步发送	快	有	不丢失
异步发送	快	有	不丢失
单向发送	最快	无	可能丢失

2、按照使用功能特点分

1）普通消息（订阅）

  普通消息就是我们业务开发中用到的最多的消息类型，生产者需要关注消息发送成功即可，消费者消费到消息即可，不需要保证消息的顺序，所以消息可以大规模并发的发送和消费，吞吐量很高，适合大部分场景。

2）顺序消息

  顺序消息分为分区顺序消息和全局顺序消息，全局顺序消息比较容易理解，也就是哪条消息先进入，哪条消息就会先被消费，符合我们的FIFO，很多时候全局顺序消息的实现代价太大，所以就出现了分区顺序消息。分区顺序消息就是在一个Broker中有序，其概念概念如下图所示：

我们通过对消息的key进行hash，想通hash的消息会被发送到同一个分区里面，当然如果要做全局顺序消息，我们的分区只需要一个即可，所以全局顺序消息的代价是比较大的，牺牲了扩展性和高并发性。

3）延时消息 —— 适用于订单超时库存归还等等业务

  延迟的机制是在服务端实现的，也就是Broker收到消息后，经过一段时间才发送给消费者，RocketMQ按照1-N定义了如下级别：1s，5s，30s，1m，2m，3m，4m，5m，6m，7m，8m，9m，10m，1h，2h；若要发送定时消息，在应用层初始化Message消息对象之后，调用Message.setDelayTimeLevel(int level)方法来设置延迟级别，按照序列取响应的延迟级别，例如level=2，则延迟为5s，其实现原理如下：

• 1、发送消息的时候如果消息设置了DelayTimeLevel，那么消息就会被丢到ScheduleMessageService.SCHEDULE_TOPIC这个topic里面，
• 2、根据DelayTimeLevel选择对应的queue
• 3、再把真是的topic和queue信息封装起来，set到msg里面
• 4、然后每个SCHEDULE_TOPIC_XXXXX的每个DelayTimeLevelQueue，有定时任务取刷新是否有待投递的消息。
• 每隔10s定时持久化发送进度

4）事务消息

  云消息队列 RocketMQ 版提供的分布式事务消息适用于所有对数据最终一致性有强需求的场景，详细的原理可以参考《分布式事务（五）——基于本地消息和可靠消息的解决方案》中的基于可靠消息的一致性的部分，这里我们主要介绍事务消息的相关内容。

（1）概念介绍

• 事务消息：云消息队列 RocketMQ 版提供类似XA或Open XA的分布式事务功能，通过云消息队列 RocketMQ 版事务消息能达到分布式事务的最终一致。
• 半事务消息：暂不能投递的消息，生产者已经成功地将消息发送到了云消息队列 RocketMQ 版服务端，但是云消息队列 RocketMQ 版服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。
• 消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，云消息队列 RocketMQ 版服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit或是Rollback），该询问过程即消息回查。

（2）分布式事务消息的优势

  云消息队列 RocketMQ 版分布式事务消息不仅可以实现应用之间的解耦，又能保证数据的最终一致性。同时，传统的大事务可以被拆分为小事务，不仅能提升效率，还不会因为某一个关联应用的不可用导致整体回滚，从而最大限度保证核心系统的可用性。在极端情况下，如果关联的某一个应用始终无法处理成功，也只需对当前应用进行补偿或数据订正处理，而无需对整体业务进行回滚。

（3）典型场景

  在淘宝购物车下单时，涉及到购物车系统和交易系统，这两个系统之间的数据最终一致性可以通过分布式事务消息的异步处理实现。在这种场景下，交易系统是最为核心的系统，需要最大限度地保证下单成功。而购物车系统只需要订阅云消息队列 RocketMQ 版的交易订单消息，做相应的业务处理，即可保证最终的数据一致性。

（4）交互流程

事务消息交互流程如下图所示。

事务消息发送步骤如下：

1. 生产者将半事务消息发送至云消息队列 RocketMQ 版服务端。
2. 云消息队列 RocketMQ 版服务端将消息持久化成功之后，向生产者返回Ack确认消息已经发送成功，此时消息为半事务消息。
3. 生产者开始执行本地事务逻辑。
4. 生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），服务端收到确认结果后处理逻辑如下：
   • 二次确认结果为Commit：服务端将半事务消息标记为可投递，并投递给消费者。
   • 二次确认结果为Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。
5. 在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。

事务消息回查步骤如下：

1. 生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
2. 生产者根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行处理。

（5）使用规则

生产消息的规则

• 事务消息发送完成本地事务后，可在execute方法中返回以下三种状态：
  • TransactionStatus.CommitTransaction：提交事务，允许消费者消费该消息。
  • TransactionStatus.RollbackTransaction：回滚事务，消息将被丢弃不允许消费。
  • TransactionStatus.Unknow：暂时无法判断状态，等待固定时间以后云消息队列 RocketMQ 版服务端根据回查规则向生产者进行消息回查。
• 通过ONSFactory.createTransactionProducer创建事务消息的Producer时必须指定LocalTransactionChecker的实现类，处理异常情况下事务消息的回查。
• 回查规则：本地事务执行完成后，若云消息队列 RocketMQ 版服务端收到的本地事务返回状态为TransactionStatus.Unknow，或生产者应用退出导致本地事务未提交任何状态。则云消息队列 RocketMQ 版服务端会向消息生产者发起事务回查，第一次回查后仍未获取到事务状态，则之后每隔一段时间会再次回查。
  • 回查间隔时间：系统默认每隔30秒发起一次定时任务，对未提交的半事务消息进行回查，共持续12小时。
  • 第一次消息回查最快时间：该参数支持自定义设置。若指定消息未达到设置的最快回查时间前，系统默认每隔30秒一次的回查任务不会检查该消息。
    以Java为例，以下设置表示：第一次回查的最快时间为60秒。

Message message = new Message();
message.putUserProperties(PropertyKeyConst.CheckImmunityTimeInSeconds,"60");

消费消息的规则

• 事务消息的Group ID不能与其他类型消息的Group ID共用。与其他类型的消息不同，事务消息有回查机制，回查时云消息队列 RocketMQ 版服务端会根据Group ID去查询生产者客户端。

---

后记
  个人总结，欢迎转载、评论、批评指正