RocketMQ初探

一、MQ的应用场景

　　1.1 异步解偶

　　 在订单系统中同步调用支付系统，库存系统，物流系统。当其中任意一个系统异常，则影响整个业务流程。引入MQ后，订单系统将消息发往MQ，由MQ将消息推送到下游系统。订单系统不需要关心后续的执行情况，整个下单流程已完成。倘下游系统异常，则由MQ负责重试。

　　1.2 削峰填谷

　　上游系统尽可能多的接收订单，将数据发往MQ，由于整个系统的处理能力有限，MQ中的消息将分批次的交由下游系统处理，虽然整个流程较平时会有延迟，但胜在用户依然能正常下单，而不是返回失败

　　1.3 数据分发

　　将一份数据分发给多个下游系统

　　1.4 异步回调

　　1.5其他

　　　　1.5.1 顺序收发：保证消息的先进先出

　　　　1.5.2 分布式事务一致性：MQ事务消息 　

二、MQ的优缺点

　　优点：解偶、数据分发、削峰

　　缺点：

　　　　1. 可用性降低（外部依赖越多稳定性越差，如何保证高可用？）

　　　　2. 复杂度提高（需要处理重复消费问题，消息丢失问题，消息传递的顺序性）

　　　　3. 一致性问题

三、消息类型

　　3.1 普通消息

　　　　同步发送（发送并等待MQ返回发送结果），异步发送（发送者提供异步回调接口由MQ调用），单向发送（发送者不关心发送结果）　　

　　3.2 顺序消息

　　　　对于同一个Topic，发布者按照什么顺序发布消息，消费者会按照同样的顺序收到消息。

　　　　顺序消息分为全局顺序消息和分区顺序消息

　　　　全局顺序：同一个Topic，所有消息先进先出

　　　　分区顺序：同一个Topic，根据Sharding Key进行区块分区，同一个分区内（同一个消息队列）消息先进先出

　　3.3 广播消息

　　　　集群消费模式：每条消息只被集群下的某台机器消费。MQ重试时不保证路由到同一台机器

　　　　广播消费模式：每条消息被集群下所有消费者处理。

　　　　1. 广播模式不支持顺序消息

　　　　2. 广播模式不支持重置消费位点

　　　　3. 每条消息需要被相同订阅

　　3.4 延迟消息

　　　　订单需要30分钟内支付完成，超过30分钟订单状态设置为未支付。适用于生产和消费之间有时间窗口的要求。实现思路是将延迟消息通过临时存储进行暂存，到期后投递到目标Topic中。

　　　　对临时存储的要求：

　　　　1.高性能，写入性能要高，关系型数据库通常不满足

　　　　2.高可靠，消息不能丢失，需要持久化

　　　　3. 支持排序，不同延迟的消息发送时间不同

　　　　4. 支持长时间保存，延迟时间可能几个月。

　　3.5 RocketMQ的延迟消息

　　　　延迟消息发送后，存放在一个特殊的topic下，不同的延迟级别有不同的队列序号，队列数是由配置的延迟等级决定的，一个延迟等级一个队列。在延迟时间到达后，由定时线程读取转化成普通的消息存放在真实的Topic下。RokcetMQ的延迟时间是固定等级的，如果想要自定义需要提前修改配置。

　　3.6 批量消息

　　　　发送者一次发送多条消息，批消息的topic是相同的，但是每条消息的msgId是不一样的。一批消息大小不能超过1M

　　3.7 过滤消息

　　　　过滤方式：　　　　

　　　　3.7.1 TAG模式过滤

　　　　发送消息时为每条消息设置TAG标签，同一TOPIC下根据TAG分类。 

　　　　3.7.2 SQL表达式过滤

　　　　发送端通过message.putUserProperty()方法设置属性　　

　　　　消费端订阅消息时通过运行SQL过滤表达式进行条件匹配：consumer.subscribe("topic",MessageSelector.bySql("age between 10 and 20"));

　　3.8 事务消息

　　　　3.8.1 概念介绍

　　　　1. 事务消息：提供类似Open X/XA的分布式事务功能

　　　　2. 半事务消息：不能立即投送的消息，需要发送者的二次确认

　　　　3. 消息回查：对半事务消息，每段时间向发送者确认，发送者提供的回调接口返回三种状态：提交，回滚和未知

　　　　3.8.2 注意事项

　　　　1. 事务消息不支持延迟和批量

　　　　2. 消息回查默认15次，超过则丢弃，并打印错误日志

　　　　3. 超时时间在Broker配置文件的transactionTimeout参数设置，可以通过用户属性CHECK_IMMUNITY_TIME_IN_SECONDS改变限制

　　　　4. 事务消息可能不止一次被检查/消费，需要做好幂等

　　　　5. 事务消息的生产者ID不能与其他类型消息的生产者ID共享

　　　　3.8.3 流程

　　　　1. 发送端发送半消息。sendMessageInTransaction方法

　　　　　　1. 将消息打上事务消息的标记，服务端以区分

　　　　　　2. 发送半事务消息（DefaultMQProducerImpl#send方法，请求头SysFlag属性设置成TRANSACTION_PREPARED_TYPE）

　　　　2. 服务端接收半消息。TransactionalMessageService#prepareMessage方法

　　　　　　1. 将半消息的真实topic，queueId放进消息体自身的map里进行缓存（TransactionalMessageBridge#parseHalfMessageInner方法）

　　　　　　2. 将半消息的topic 设置为“RMQ_SYS_TRANS_HALF_TOPIC”，queueId设置为0（TransactionalMessageBridge#parseHalfMessageInner方法）

　　　　　　3. 将半消息写入commitLog进行持久化（MessageStore#putMessage方法）

　　　　3. 发送端执行本地事务并通知执行结果。sendMessageInTransaction方法

　　　　　　1. 发送成功，执行本地事务executerLocalTransaction方法，方法返回枚举LocalTransactionState(提交，回滚，未知)

　　　　　　2. 执行endTransaction方法：根据本地事务执行情况，通知服务端提交还是回滚

　　　　4. 服务端接收发送端执行结果。EndTransactionProcessor#processRequest方法

　　　　　　1. 根据通知请求体中消息的文件偏移量，取出半消息，还原消息的topic和queueId

　　　　　　2. 若发送端通知提交，重新存储到commitLog（sendFinalMessage方法）

　　　　　　3. 不管是提交还是回滚，都需要删除半消息（deletePrepareMessage方法）。

　　　　　　　实际是新创建一个消息，消息体为半消息的队列偏移量，并存放到RMQ_SYS_TRANS_OP_HALF_TOPIC的队列中，这个topic下的半消息都是已经处理过的。

　　　　5. 服务端定时回查。TransactionalMessageCheckService#onWaitEnd方法

　　　　　　1. 获取RMQ_SYS_TRANS_HALF_TOPIC的半消息队列，循环遍历队列，逐个处理

　　　　　　2. 做下过滤，已经处理过的不再处理(在RMQ_SYS_TRANS_OP_HALF_TOPIC的队列中)

　　　　　　3. 做下过滤，最大回查次数不超过15次（默认，具体看broker的transactionCheckMax配置）和最大存储时间不超过3天

　　　　　　4. 做下过滤，半消息刚放进队列，还不需要执行回查（有个超时时间，默认6秒，具体看broker的transactionTimeOut配置，用户通过赋值CHECK_IMMUNITY_TIME_IN_SECONDS属性设置）

　　　　　　5. 进行回查，resolveHalfMsg()，内部有线程池提交回查任务

　　　　6. 发送端处理回查请求。DefaultMQProducerImpl#checkTransactionState方法

　　　　　　1. 根据TransactionListener#checkLocalTransaction方法获取对应事务Id的状态

　　　　　　2. 根据状态通知服务端提交还是回滚

　　　　源码分析：https://segmentfault.com/a/1190000019755235?utm_source=tag-newest，https://blog.csdn.net/hosaos/article/details/90240260，https://www.sohu.com/a/287495304_612370