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重试消息的压力。

 

posted @ 2018-09-20 23:25  羽觞醉月  阅读(5369)  评论(0编辑  收藏