这是我参与「第五届青训营 」笔记创作活动的第6天
BMQ相比较Kafka有哪些优势？
1、Kafka可以保证顺序处理消息,RabbitMQ相对较弱。 2、在消息路由和过滤方面,RabbitMQ提供了更好的支持。 3、RabbitMQ有消息存活时间(TTL)和延迟/预定消息功能
RocketMQ事务消息处理流程简述？
事务消息流程分析 上图说明了事务消息的大致方案，其中分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程。
1.事务消息发送及提交：
(1) 发送消息（half消息）。 (2) 服务端（Broker）响应消息写入结果。 (3) 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）。 (4) 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）
2.补偿流程：
(1) 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查” (2) Producer收到回查消息，检查回查消息对应的本地事务的状态 (3) 根据本地事务状态，重新Commit或者Rollback 其中补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。 事务消息共有三种状态，提交状态、回滚状态、中间状态： TransactionStatus.CommitTransaction: 提交事务，它允许消费者消费此消息。 TransactionStatus.RollbackTransaction: 回滚事务，它代表该消息将被删除，不允许被消费。 TransactionStatus.Unknown: 中间状态，它代表需要检查消息队列来确定状态。
你认为MQ后面应该如何发展？
Consumer 消费消息失败后，要提供一种重试机制，令消息再消费一次。Consumer 消费消息失败通常可以认为 有以下几种情况 由于消息本身的原因，例如反序列化失败，消息数据本身无法处理（例如话费充值，当前消息的手机号被 这种错误通常需要跳过这条消息，再消费其他消息，而这条失败的消息即使立刻重试消费，99%也不成功，所以最好提供一种定时重试机制，即过 10s 秒后再重试。 由于依赖的下游应用服务不可用，例如 db 连接不可用，外系统网络不可达等。 遇到这种错误，即使跳过当前失败的消息，消费其他消息同样也会报错。这种情况建议应用 sleep 30s，再 消费下一条消息，这样可以减轻 Broker 重试消息的压力。
