RocketMQ

 

Mq的优点：

• 应用解耦

• 流量的削峰填谷

• 数据分发（将数据发送到多个系统）

• 异步处理

Mq的缺点：

• 系统可用性降低

使用mq后引用外部依赖增多，mq挂了将会影响应用的可用性

• 系统复杂度提高

消息的重复消费、Exactly-Once问题、消息消费顺序问题、消息丢失问题

• 一致性问题

多个系统同时处理消息，其中一个系统失败，整个系统一致性如何保证

常用MQ比较：

 

特性	RabbitMq	RocketMQ	Kafka
开发语言	Erlang	Java	Scala 和 Java
成熟度	成熟	比较成熟	成熟的日志领域
时效性	微秒级	毫秒级	毫秒级
社区活跃度	高	高	高
单机吞吐量	5.9W/S，CPU资源消耗较高；消息持久化场景下在2.6w/s左右	11.6w/s，RocketMQ 的消息写入内存后即返回ack，由单独的线程专门做刷盘的操作，所有的消息均是顺序写文件。（内存消耗相对较大）	17.3w/s，这主要取决于它的队列模式保证了写磁盘的过程是线性IO。此时broker磁盘IO已达瓶颈。（cpu消耗相对较大）
topic数量对吞吐量的影响		topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降这是 RocketMQ的一大优势，在同等机器下，可以支撑大量的topic	topic 从几十个到几百个的时候，吞吐量会大幅度下降所以在同等机器下，kafka 尽量保证 topic 数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源
可用性	高，基于主从架构实现高可用性	非常高，分布式架构	非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	以 broker 为中心，有消息的确认机制	经过参数优化配置，可以做到0丢失	经过参数优化配置，消息可以做到0丢失。以 consumer 为中心，无消息的确认机制
功能支持	基于erlang开发，所以并发能力很强，性能极其好，延时很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准

RocketMQ角色：

• Producer: 消息生产者

• Consumer: 消息消费者

• Broker: 消息存储中心，主要作用是接收来自 Producer 的消息并存储， Consumer 从这里取得消息。Broker上存储着多个topic的消息。

• Name Server: 保存 Broker 相关 Topic 等元信息并给 Producer ，提供 Consumer 查找 Broker 信息。（类似于注册中心）

• Topic: 区分不同的消息的类别；一个topic可以多个Producer生产，也可以多个Consumer消费。

• Message Queue: Message是在每个Broker上以Queue的形式记录。同一个topic有多个队列存储消息，消息在队列里有序，不同队列的数据相对无序。

• Tag：消息标签，用来进一步区分某个 Topic 下的消息分类，消息队列 RocketMQ 允许消费者按照 Tag 对消息进行过滤，确保消费者最终只消费到他关注的消息类型。