RocketMQ

消息中间件功能

• 主要功能是异步解耦
• 流量削峰，挡住前端的数据洪峰，保证后端系统的稳定；这就要求消息中间件有一定的消息堆积能力；文件记录形式存储在硬盘。

At Least One，每个消息必须投递一次，最少投递一次。Consumer先将消息pull到本地，消费完成后，向服务器返回ack，如果没有消费一定不返回ack。

Exactly Only One，仅发一次；只有满足，在发送阶段不允许发送重复消息，在消费阶段不允许消费重复消息，才能认定只发一次；RocketMQ并不保证此特性，需要我们在业务上去重，即消费消息要做到幂等性；

RocketMQ知识点

RocketMQ是阿里开源的高性能、高吞吐量的分布式消息中间件。

Topic 消息类别（一级消息类型）Tag 子主题（同一业务模块不同目的的消息）

GroupName 实现消费消息的负载均衡（集群消费），生产者高可用

Producer 消息生产者 Consumer 消息消费者 NameServer 名称服务器，提供路由信息 Broker 消息存储/转发服务器

Message 消息载体 Message Queue 消息队列 Message ID 消息全局唯一标志

发送消息方式

• 可靠同步发送：用在重要消息通知，传递
• 可靠异步发送：通常用于对响应时间敏感的业务，可以对异步发送回调
• 单向发送：适用于对可靠性要求不高的场景，例如日志发送（只发送消息不等待应答）

消息获取方式

• PullConsumer（消费者主动拉取消息，取消息的过程需要开发人员编写，通过topic拿到队列集合，然后从每个队列取消息，记录当前队列的offset；可以控制拉取的速度，大小，可控性好）
• PushConsumer（主动推送给消费者；对轮询进行封装，注册MessageListener监听器，监听消息获取；如果推送过多，消息会堆积在消费端）

https://blog.csdn.net/zhangcongyi420/article/details/90548393

消息类型

• 集群消息（同一Topic下的Consumer平摊消费）
• 广播消息（每条消息，每个Consumer都会消费）
• 定时消息/延时消息（不会立即消费，到特定的时间或延迟后，进行消费）
• 事务消息（提供类似XA的分布式事务功能，达到事务最终一致性）
• 顺序消息（严格顺序消息）

消息堆积（流量削峰） 消息过滤 （可以按照tag或body进行过滤） 消息轨迹（方便排查问题）

消息重发（在消息持久化的范围内-默认3天，按照时间点重新消费消息）

默认队列 RocketMQ中，Topic默认队列是4（0-3）；消息生产后推送到mq的topic上，会随机选择一个投递队列

组件

NameServer是RocketMQ的寻址服务，Broker启动时会向NameServer注册。客户端依靠NameServer获取对应的Topic路由信息。其是无状态的节点，集群间互不通信；客户端连接NameServer，会随机选择一个，以做到负载均衡。即使全部宕机，也不影响系统使用。

Broker，存储/抓发消息，只有Master才能进行写入操作；M/S同步数据，策略取决于Master的配置，可以采用同步双写，异步复制。消费者可以从M/S消费，默认情况是通过Master消费，Master宕机后，就从Slave消费。Broker与NameServer建立长连接，注册Topic信息。（心跳间隔，每隔30秒，向NameServer发送心跳；心跳超时，NameServer每隔10秒扫描所有存活的Broker，若2分钟内未发送心跳，则断开连接；Broker一旦断开，NameServer会立即感知；）

Toipc与Broker是多对多的关系。一个Topic分布在多个Broker上，一个Broker可以配置多个Topic。这样能做到负载均衡。

Broker宕机，消费者会从Slave上消费消息；可能会有部分消息未同步到Slave上，但消息最终不会丢失，一旦Master恢复，消息就会消费掉。

Broker消息堆积不可能无限制（磁盘有限），所以会有消息清理；文件默认保留3天，当磁盘达到阀值，或者超过保留时间，会进行清理。

Consumer与NameServer保持长连接，默认每隔30秒轮询获取topic信息；消费者会与关联的Broker保持长连接。生产者也一样

生产者投递消息时，可以指定投递的队列（MessageQueueSelector）；不指定，就是随机发送。

RocketMQ与Kafka对比

• RocketMQ，支持广播消息，支持消息重复提交，自身有nameserver，采用Java编写；
• Kafka，需要zookeeper做服务注册与发现，采用Scala编写；

持久化

• 高性能文件存储；RocketMQ，单文件commitLog；Kafka，多分片（文件）；

Master/Slave选举功能

• Kafka具备Master/Slave选举功能，Master宕机后，会选举某个Slave升级为Master；
• RocketMQ不具备选举功能，角色固定，当Master挂后，把原本写到这个Broker的请求迁移到其他Broker上，而消费者继续从Slave上消费；

吞吐量

• Kafka比RocketMQ有更大的吞吐量。kafka在消息存储过程中会根据topic和partition的数量创建物理文件，也就是说我们创建一个topic并指定了3个partition，那么就会有3个物理文件目录；
• RocketMQ真正存储消息的commitLog其实就只有一个物理文件；
• kafka的多文件并发写入 VS rocketMq的单文件写入，性能差异kafka完胜；

数据安全

• RocketMQ支持实时刷盘，异步刷盘，同步复制，异步复制（更加安全）
• Kafka使用异步刷盘，异步复制

消息投递实时性

• Kafka使用短轮询方式，实时性取决于轮询间隔时间
• RocketMQ采用长轮询，实时性高

消息重试

• Kafka消息失败不支持重试
• RocketMQ消费失败，支持定时重试，每次重试时间间隔顺延

消息顺序

• RoketMQ支持严格的消息顺序
• Kafka支持顺序消息，但服务宕机后，会产生消息乱序

定时消息

• Kafka不支持定时消息
• RocketMQ支持定时Level

分布式事务消息

• RocketMQ支持；Kafak不支持

消息查询

• RocketMQ支持通过msgid查询；Kafka不支持；

消息回溯

• RocketMQ支持按时间回溯；Kafka理论上可以按照Offset回溯。

消息并行度

• Kafka消息并行度跟Topic的分区数一致
• RocketMQ顺序消息跟Kafka一致，乱序消息跟机器数+线程数有关

消息堆积能力

• 亿级以上，完全满足业务需求

消息过滤

• RocketMQ，支持tag过滤，或对任意消息根据body过滤
• Kafka支持

https://www.cnblogs.com/ynyhl/p/11320797.html

短轮询，长轮询

短轮询，长轮询，都是客户端不停的向服务端发起请求；短轮询，服务的会直接返回结果；长轮询，如果没有数据，会将请求挂起一段时间，如果还没有结果，就会返回，或者等到超时；（长，短轮询，是由服务端编码设定的）

长连接、短连接

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

https://www.cnblogs.com/gotodsp/p/6366163.html

MQ应用场景

异步处理（例如邮件、短信发送）/应用解耦（短信系统与主业务系统解耦）/流量削峰（秒杀活动将请求写入消息队列）/消息通信

MQ常见问题

如何保证消息不丢失？

生产者生产消息-->Broker存储消息-->消费者消费消息

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/

https://www.cnblogs.com/xiaodf/p/5075167.html

https://www.jianshu.com/p/d8a21ab2c2d3

https://www.jianshu.com/p/a2e4e45709c4

https://www.cnblogs.com/hzmark/p/orderly_message.html