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

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

1.Publish/Subscribe（发布订阅）

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

2.Message Priority（消息优先级）

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

由于rocketmq的所有消息都是持久化的，按照优先级排序开销会非常大，所以不支持持久化。但是可以配置一个优先级高的队列和一个普通的队列，将不同的消息发送到不同的队列。

优先级问题可以分为两类：

只要达到优先级目的即可，不需要严格划分优先级。通常将优先级划分为高、中、低等几个等级。每个优先级用不同的topic表示。发送消息通过不同的topic来表示优先级。缺点是对业务的优先级做了妥协。
严格的优先级。如果让MQ解决此问题，会对MQ的性能造成很多影响。这里要确保一点，业务上是否确实需要这种严格的优先级，如果将优先级压缩成几个，对业务的影响有多大？

3.Message Order（消息有序）

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

rocketmq严格保证消息有序性。

4.Message Filter（消息过滤）

Broker端消息过滤

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

Consumer端消息过滤

　　　　这种过滤方式可由应用完全自定义实现，但是缺点是很多无用的消息要传输到 consumer端。

5.Message Persistence（消息持久化）

消息中间件通常采用几种方式持久化：

持久化到数据库
持久化到KV存储
文件记录形式的持久化，例如kafka、rocketmq
对内存数据做持久化镜像

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

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

6.Message Reliablity（消息可靠性）

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

broker正常关闭
broker异常crash
OS crash
机器掉电，但能立即恢复供电情况
机器不能开机（硬件损坏）
磁盘设备损坏

前面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消费消息失败有几种情况：

由于消息本身原因，如反序列化失败，消息数据本身没法处理（话费充值，当前手机号被注销，不能充值）等。这种错误通常需要跳过这条消息，再消费其他消息，这条失败的消息即使立刻重试消费，基本不可能成功，所以最好提供一种定时重试机制。
由于依赖的下游应用用服务不可用，如数据库连接不可用，网络原因等。这种错误即使跳过当前失败的消息，消费其他消息同样会报错。

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