消息中间件之 Rocket MQ 总结（一）

小白又来更新啦，前面已经分享了异步编程之CompletableFuture，不知道是否有帮助嘿嘿，相关文章链接 CompletableFuture 实现异步总结（三）-CSDN博客，今天要跟大家分享的是消息中间件之Rocket MQ，如果文章有什么误区，还请各位大佬帮忙指出，不玻璃心。

---

一、MQ简介

MQ，Message Queue，是一种提供消息队列服务的中间件，也称为消息中间件，提供了消息生产、存储、消费全过程API的软件系统。消息即数据，一般消息体不会很大，具体看业务。

二、Rocket MQ

1.消息中间件的功能

1. 应用解耦：服务之间耦合度降低。举个例子：假如有个购买商品入口的服务A，使用MySQL用来存储用户的下单和库存更新的情况，如果是高并发的情况下，请求数飙升，那底层的MySQL势必会有宕机的风险，也就会影响用户下单这个流程的进行，这不是我们想看到的结果。那如果有个“中转站”，类似“菜鸟驿站”，也就是说用户下单之后，只需要告诉用户已经下单成功了，至于什么时候库存有没有更新成功，上游服务就不需要管了，而下游服务只需要到中转站去获取用户下单的消息即可。

2. 流量削峰、负载均衡：还是接着第1点的例子，假如高并发的情况下，请求数增多，而MySQL可以承受的并发量是有限的，一旦达到顶峰值，如果这个时候请求数大于MySQL本身能够承受的峰值，那其他多出来的请求数，也就丢失了。这个时候如果采用消息中间件来缓冲大量的请求,匀速消费，这样就不会出现请求丢失的情况。

3. 数据收集：分布式系统会产生海量级数据流，如:业务日志、监控数据、用户行为等。针对这些数据流进行实时或批量采集汇总，然后对这些数据流进行大数据分析。

三、常见的消息中间件

中间件	Active MQ	Rabbit MQ	Kafka	Rocket MQ
开发语音	Java	Er Lang	scala	Java
单机吞吐量	万级	万级	十万级	十万级
topic	无概念	无概念	百级Topic时会影响系统吞吐量	千级Topic时会影响系统吞吐量
适用场景	不适合用于上千个队列的应用场景	有消息确认机制和持久化机制	日志领域	单机支持1万以上持久化队列
时效性	ms级别	μs（微秒）级别	ms级别	延迟在ms级别以内

四、MQ部分角色之需要注意的点

1. Topic：

• 表示一类消息的集合，每个主题包含多条消息，且每条消息只能属于一个主题；
• 一个producer可以同时发送多种Topic的消息，而一个consumer只对某种特定的Topic，只可以消费和订阅一种Topic的消息；

• 一个Topic的Queue中的消息只能被一个消费者组中的一个消费者消费。一个Queue中的消息不允许同一个消费者组中的多个消费者同时消费。

2. 分片：

• 分片不同于分区。在RocketMQ中,分片指的是存放相应Topic的Broker，每个分片中会创建出相应数量的分区，即Queue，每个Queue的大小都是相同的。

3. 消息标识(MessageId/Key)：

• RocketMQ中每个消息拥有唯一的MessageId，且可以携带具有业务标识的Key，以方便在日志中对消息的查询，便于排查问题。

4. queue：

• queue，即队列，是 RocketMQ 中消息存储和传输的实际容器，也是 Apache RocketMQ 消息的最小存储单元。 Apache RocketMQ 的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。

5. producer：

• 消息的生产者，负责生产消息。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行发送消息。

• RocketMQ中的producer都是以 producer group（生产者组） 形式出现的，一个producer group可以发送多种topic的消息；

6. consumer：

• 消息的消费者，负责消费消息。从broker获取消息并对消息进行消费；
• 消费者都是以 consumer group （消费者组）出现的，一个consumer group中的消费者消费同一个topic的消息；
• 负载均衡：consumer 在消费消息层面也是负载均衡的，一个topic中的不同的queue平均分配给同一个consumer group 中的不同的consumer，不是将消息负载均衡；
• 容错：如果一个consumer group中的某一个consumer宕机了，该group中的其他consumer可以继续消费宕机的consumer负责的queue中的消息。

总结

        今天跟大家分享的是一些基础知识，希望能够有所帮助，未完待续.............