RocketMQ原理刨析

 RocketMQ原理

本文类容基本上和RocketMQ design类似，并无过多的改动。主要内容包括：

RocketMQ概述，主要是概念上的一些内容

RocketMQ的特点以及消息发送、消费模型

RocketMQ原理：mmap+write，文件系统，数据存储结构，队列，刷盘策略，消息查询，消息过滤，事务消息，发送、订阅负载均衡，同步双写/异步复制，充分利用内存，消息堆积能力以及解决办法

 

一、  RocketMQ概述

1.  MessageFilter

1)   Broker端消息过滤

在Broker中，按照Consumer的要求做过滤，优点是减少了对于Consumer无用消息的网络传输。缺点是增加了Broker的负担，实现相对复杂。

² 淘宝Notify支持多种过滤方式，包含直接按照消息类型过滤，灵活的语法表达式过滤，几乎可以满足最苛刻的过滤需求。

² RocketMQ支持按照简单的Message Tag过滤，也支持按照Message Header、body进行过滤。

² CORBA Notification规范中也支持灵活的语法表达式过滤。

2)   Consumer端消息过滤

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

 

2.  消息可靠性

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

² Broker正常关闭


² Broker异常Crash


² OSCrash


² 机器掉电，但是能立即恢复供电情况。


² 机器无法开机(可能是cpu、主板、内存等关键设备损坏)


² 磁盘设备损坏。


前四种情况都属于硬件资源可立即恢复情况，RocketMQ在这四种情况下能保证消息不丢，或者丢失少量数据(依赖刷盘方式是同步还是异步)。后两种属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。

RocketMQ从3.0版本开始支持同步双写。

 

3.  消息原语

1)   At most once

最多一次，发送一次，无论成败，将不会重发。

2)   At least Once

消息投递后，如果未能收到ack，则再次投递。

每个消息必须投递一次RocketMQ Consumer先pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息，所以RocketMQ可以很好的支持此特性。

3)   Exactly Only Once

² 发送消息阶段，不允许发送重复的消息。

² 消费消息阶段，不允许消费重复的消息。


只有以上两个条件都满足情况下，才能认为消息是“Exactly Only Once”，而要实现以上两点，在分布式系统环境下，不可避免要产生巨大的开销。所以RocketMQ为了追求高性能，并不保证此特性，要求在业务上进行去重，也就是说消费消息要做到幂等性。RocketMQ虽然不能严格保证不重复，但是正常情况下很少会出现重复发送、消费情况，只有网络异常，Consumer启停等异常情况下会出现消息重复。

此问题的本质原因是网络调用存在不确定性，即既不成功也不失败的第三种状态，所以才产生了消息重复性问题。

4.  回溯消费

是指Consumer已经消费成功的消息，由于业务上需求需要重新消费，要支持此功能，Broker在向Consumer投递成功消息后，消息仍然需要保留。并且重新消费一般是按照时间维度，例如由于Consumer系统故障，恢复后需要重新消费1小时前的数据，那么Broker要提供一种机制，可以按照时间维度来回退消费进度。RocketMQ支持按照时间回溯消费，时间维度精确到毫秒，可以向前回溯，也可以向后回溯。

 

5.  消息堆积

消息中间件的主要功能是异步解耦，还有个重要功能是挡住前端的数据洪峰，保证后端系统的稳定性，这就要求消息中间件具有一定的消息堆积能力，消息堆积分以下两种情况:

消息堆积在内存Buffer，一旦超过内存Buffer，可以根据一定的丢弃策略来丢弃消息，如CORBA Notification规范中描述。适合能容忍丢弃消息的业务，这种情况消息的堆积能力主要在于内存Buffer大小，而且消息堆积后，性能下降不会太大&#x