【框架】RocketMQ

颜色一族关于新项目的上的MQ技术选型上的讨论。

讨论会成员
绿，作为一个具有广泛交流的茶，是一个非常合适的人选，去组织此次MQ技术选择讨论。
白，作为一个具有10年工作经验，一直冲锋在开发一线的技术人员。对于公司中的很多项目都有参与架构设计。
蓝，是一个比白工作更久的技术人员，他已经老了。有一点根不上这快速迭代的技术，更多的是对公司老旧项目的开发管理，所使用的技术也是相当的古老。

绿：既然大家都到齐了，那对于我们新项目要使用到的是什么MQ，请大家畅所欲言。

蓝首先发言：我认为使用RabbitMQ作为消息中间件比较合适。现在市面上就有很多的项目使用RabbitMQ作为消息中间件，而且，我们公司也存在这样的项目。对于使用RabbitMQ在搭建集群以及使用上都比较的有经验。

白：RabbitMQ在早期确实是比较好的消息中间件，但是，现在已经发布的RocketMQ相对而言更好。并且RocketMQ是使用Java语言实现的中间件，我们还可以阅读源码等。

白：RocketMQ还有如下有点：同步消息，异步消息，单向消息（单向消息可以用于日志等）。
。。。批量消息：消息的批量发送，打次发送不能大于4M
。。。顺序消息：在发送的消息要保证消费顺序
。。。事务消息：在使用到分布式事务的时候，可以使用该方式实现
。。。延时消息：不能发任意时刻的延时消息，只能发送指定的18个等级的延时消息。1s 2s 4s
。。。过滤消息的方式：Tag过滤和sql过滤

为什么使用MQ？

• 吞吐量
• 高可用
• 解耦

RocketMQ部署
名称	特点
单Master	单机模式，只有一个Broker，如果Broker宕机，MQ不可用
多Master模式	组成集群，每个节点都是Master节点配置简单，性能最高，某个节点宕机不会影响MQ服务；缺点：如果某个节点宕机，该节点中未被消费的消息在节点恢复之前不会被消费
多Master多Slave，异步复制	每个Master配右一个Slave，多对Master-Slave，Master与Slave消息采用异步复制方式，主从消息一致性只会毫秒级的延时。优点：弥补了多Mater模式（无Slave）下节点宕机后再恢复前不可订阅的问题。在Master宕机后，消费者可从Slave节点进行消费。采用多Master多Slave模式，异步复制进行部署，将会有较低的延时和较高的吞吐量 ；缺点：如果Master宕机，磁盘损坏的情况下，如果没有及时将消息复制到Slave，会导致有少量消息丢失
多Master多Slave，同步双写	与多Master多Slave模式，异步复制方式基本一致，不同之处在于只有Master和Slave都写入成功以后，才会向客户端返回成功。优点：数据与服务都无单点，Master宕机情况下，消息无延时，服务可用性和数据可用心都非常高；缺点：降低消息写入效率，影响系统吞吐量
	实际部署中，根据业务场景的所需要的性能和消息可靠性等方面来选择后两种

部署RocketMQ

保证RocketMQ高可用

RocketMQ工作流程

面试参考
https://blog.csdn.net/m0_37900506/article/details/118978969
https://www.jianshu.com/p/d21734a16cf4

​