RocketMQ之消息中间件须要解决的问题

消息中间件须要解决哪些问题

1.Publish/Subscribe（发布订阅）

发布订阅是消息中间件最基本的功能

2.Message Priority（消息优先级）

在消息队列中，每条消息都有不一样的优先级，优先级高的先投递。

因为rocketmq的全部消息都是持久化的，按照优先级排序开销会很是大，因此不支持持久化。可是能够配置一个优先级高的队列和一个普通的队列，将不一样的消息发送到不一样的队列。

优先级问题能够分为两类：

1. 只要达到优先级目的便可，不须要严格划分优先级。一般将优先级划分为高、中、低等几个等级。每一个优先级用不一样的topic表示。发送消息经过不一样的topic来表示优先级。缺点是对业务的优先级作了妥协。
2. 严格的优先级。若是让MQ解决此问题，会对MQ的性能形成不少影响。这里要确保一点，业务上是否确实需 要这种严格的优先级，若是将优先级压缩成几个，对业务的影响有多大？

3.Message Order（消息有序）

消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了 3 条消息，分别是订单创 建，订单付款，订单完成。消费时，要按照这个顺序消费才能有意义。可是同时订单之间是能够并行消费的。

rocketmq严格保证消息有序性。

4.Message Filter（消息过滤）

• Broker端消息过滤

　　　　在broker中按照consumer的要求过滤，优势是减小了对应consumer的无用消息的传输。但增长了broker的负担，使得实现变复杂。

• Consumer端消息过滤

　　　　这种过滤方式可由应用彻底自定义实现，可是缺点是不少无用的消息要传输到 consumer端。

5.Message Persistence（消息持久化）

消息中间件一般采用几种方式持久化：

1. 持久化到数据库
2. 持久化到KV存储
3. 文件记录形式的持久化，例如kafka、rocketmq
4. 对内存数据作持久化镜像

前三种持久化方式都具备将内存队列 buffer 进行扩展的能力，后一种则当broker挂掉重启后仍然能将以前内存的数据恢复出来。

rocketmq参考了kafka的持久化方式，充分利用Linux文件系统内存cache来提升性能。

6.Message Reliablity（消息可靠性）

影响消息可靠性的几种状况：

1. broker正常关闭
2. broker异常crash
3. OS crash
4. 机器掉电，但能当即恢复供电状况
5. 机器不能开机（硬件损坏）
6. 磁盘设备损坏

前面1-4四种状况都属于硬件资源可当即恢复的状况。rocketmq在这四种状况下能保证消息不丢，或丢失少许数据（依赖刷盘方式是同步仍是异步）。

5-6两种状况属于单点故障，且不能恢复，一旦发生，在此单点上的消息所有丢失。rocketmq在这两种状况下，经过异步复制，可保证99%的消息不丢。经过同步双写技术能够彻底避免单点，但会影响性能，适合对消息可靠性要求极高的场景，如与钱相关的应用。

7.Low Latency Messaging（低延迟）

在消息不堆积状况下，消息到达 broker 后，能马上到达 consumer。

rocketmq使用长轮询 pulll 方式，可保证消息很是实时，消息实时性不低于 push。

8.At least Once（至少一次） 

指每一个消息必须投递一次

rocketmq的consumer先pull消息到本地，消息完成后，才向服务器返回ask。若是没有消费，必定不会ask消息。

9.Exactly Only Once（只有一次）

• 发送消息阶段不容许重复发送
• 消费消息阶段不容许重复消费

只有两个条件都知足，才能认为消息是去除的。而要实现以上两点，在分布式环境下，无疑会产生巨大开销。

rocketmq并不保证此特性，而是要求在业务上去重，即消费消息作到幂等性。

10.Broker 的 Buffer

broker中的buffer一般指broker中一个队列中的内存buffer大小。若是buffer满了怎么办？

CORBA Notification 规范中处理方式：

• RejectNewEvents：拒绝新来的消息，向producer返回错误码
• 按照特定策略丢弃已有消息

rockermq的队列都是持久化磁盘，buffer大小是磁盘容量，且数据按期清理。

11.回溯消费

回溯消息指consumer成功消费的消息因为业务上的需求，须要从新消费。要支持此功能，broker在向consumer投递消息后，消息仍要保留。。而且从新消费通常是按照时间维度，例如因为 Consumer 系统故障， 恢复后须要从新消费 1 小时前的数据，那么 Broker 要提供一种机制，能够按照时间维度来回退消费进度。

rocketmq支持按照时间回溯消息，时间维度精确到毫秒，能够向前回溯，也能够向后回溯。

12.消息堆积

消息中间件的主要功能是异步解耦，挡住前端的数据洪峰，保证后端系统的稳定性。这要求消息中间件具备必定的消息堆积能力。

消息堆积分两种：

• 一种是消息堆积在内存buffer中，一旦超过内存buffer，能够根据丢弃策略来丢弃消息。这种消息堆积能力主要在于内存buffer的大小。且消息堆积后，性能降低不会太大。由于内存中数据多少对于对外提供的访问能力影响有限。
• 第二种是消息堆积在持久化存储系统中，如：数据库，KV存储，文件记录形式。当消息不能在内存cache中命中时，要不可避免的访问磁盘，从而产生大量读IO，读IO的吞吐量直接决定了消息堆积后的访问能力

13.分布式事务

rocketmq采用第一阶段发送Prepared消息时，拿到消息的offset，第二阶段经过offset访问消息，并修改状态。offset就是数据的地址。

rocketmq实现事务方式，没有经过KV存储作，而是经过offset方式，存在一个显著缺陷，即经过offset更改数据，会令系统的脏页过多。

14.定时消息

定时消息指消息放到broker后，不能当即被consumer消费，需到特定时间点或等待特定时间后才能被消费。

若是支持任意时间精度，在broker层，就必须作消息排序，涉及到持久化，排序就会产生大量性能开销。

rocketmq支持定时消息，但不支持任意精度，只支持特定level，如：5s，10s，1m等

15.消息重试

consumer消费消息失败后，要提供一种重试机制，令消息再消费一次。

consumer消费消息失败有几种状况：

1. 因为消息自己缘由，如反序列化失败，消息数据自己无法处理（话费充值，当前手机号被注销，不能充值）等。这种错误一般须要跳过这条消息，再消费其余消息，这条失败的消息即便马上重试消费，基本不可能成功，因此最好提供一种定时重试机制。
2. 因为依赖的下游应用用服务不可用，如数据库链接不可用，网络缘由等。这种错误即便跳过当前失败的消息，消费其余消息一样会报错。

这种状况建议应用sleep 30s，再消费下条消息，从而减轻broker重试消息的压力。