消息中间件RocketMq相关知识点

   

1. 中⼩型公司⾸选RabbitMQ：管理界⾯简单，⾼并发。

2. ⼤型公司可以选择RocketMQ：更⾼并发，可对rocketmq进⾏定制化开发。

3. ⽇志采集功能，⾸选kafka，专为⼤数据准备。

  

1. 消息可靠性：

影响消息可靠性的情况：

i. Broker正常关闭

ii. Broker异常Crash

iii. OS Crash

iv. 机器掉电，但是能⽴即恢复供电情况。

v. 机器⽆法开机（可能是cpu、主板、内存等关键设备损坏）

vi. 磁盘设备损坏。

1、(1)、(2)、(3)、(4)四种情况都属于硬件资源可⽴即恢复情况，RocketMQ在这四种情况下能保证消息不丢，或者丢失少量数据（依赖刷盘⽅式是同步还是异步）。

2、(5)、(6)属于单点故障，且⽆法恢复，⼀旦发⽣，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极⾼的场合，例如与Money相关的应⽤。

    

2. 消息低延迟：

在消息不堆积情况下，消息到达Broker后，能⽴刻到达Consumer。RocketMQ使⽤⻓轮询Pull⽅式，可保证消息⾮常实时，消息实时性不低于Push。

    

3. 每个消息⾄少投递⼀次：

RocketMQ Consumer先pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费⼀定不会ack消息，所以 RocketMQ可以很好的⽀持此特性。

  

4. 每个消息只消费⼀次：

1、前提：

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

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

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

  

5. Broker的Buffer满了怎么办？

a. 下⾯是CORBA Notification规范中处理⽅式：

i. RejectNewEvents 拒绝新来的消息，向Producer返回RejectNewEvents错误码。

ii. 按照特定策略丢弃已有消息。

1. AnyOrder - Any event may be discarded on overflow. This is the default setting for this property.

2. FifoOrder - The first event received will be the first discarded.

3. LifoOrder - The last event received will be the first discarded.

4. PriorityOrder - Events should be discarded in priority order, such that lower priority events will be discarded before higher priority events.

5. DeadlineOrder - Events should be discarded in the order of shortest expiry deadline first.

b. RocketMQ没有内存Buffer概念，RocketMQ的队列都是持久化磁盘，数据定期清除。

对于此问题的解决思路，RocketMQ同其他MQ有⾮常显著的区别，RocketMQ的内存Buffer抽象成⼀个⽆限⻓度的队列，不管有多少数据进来都能装得下，这个⽆限是有前提的，Broker会定期删除过期的数据，例如Broker只保存3天的消息，那么这个Buffer虽然⻓度⽆限，但是3天前的数据会被从队尾删除。

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

  

6. 回溯消息：

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

b. RocketMQ⽀持按照时间回溯消费，时间维度精确到毫秒，可以向前回溯，也可以向后回溯。

  

7. 消息堆积：

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

i. 消息堆积在内存Buffer，⼀旦超过内存Buffer，可以根据⼀定的丢弃策略来丢弃消息，如CORBA Notification规范中描述。适合能容忍丢弃消息的业务，这种情况消息的堆积能⼒主要在于内存Buffer⼤⼩，⽽且消息堆积后，性能下降不会太⼤，因为内存中数据多少对于对外提供的访问能⼒影响有限。

ii. 消息堆积到持久化存储系统中，例如DB，KV存储，⽂件记录形式。 当消息不能在内存Cache命中时，要不可避免的访问磁盘，会产⽣⼤量读IO，读IO的吞吐量直接决定了消息堆积后的访问能⼒。

b. 评估消息堆积能⼒主要有以下四点：

i. 消息能堆积多少条，多少字节？即消息的堆积容量。

ii. 消息堆积后，发消息的吞吐量⼤⼩，是否会受堆积影响？

iii. 消息堆积后，正常消费的Consumer是否会受影响？

iv. 消息堆积后，访问堆积在磁盘的消息时，吞吐量有多⼤？

  

8. 分布式事务：

1. 已知的⼏个分布式事务规范，如XA，JTA等。其中XA规范被各⼤数据库⼚商⼴泛⽀持，如Oracle，Mysql等。其中XA的TM实现佼佼者如Oracle Tuxedo，在⾦融、电信等领域被⼴泛应⽤。

2. 分布式事务涉及到两阶段提交问题，在数据存储⽅⾯的⽅⾯必然需要KV存储的⽀持，因为第⼆阶段的提交回滚需要修改消息状态，⼀定涉及到根据Key去查找Message的动作。RocketMQ在第⼆阶段绕过了根据Key去查找Message的问题，采⽤第⼀阶段发送Prepared消息时，拿到了消息的Offset，第⼆阶段通过Offset去访问消息，并修改状态，Offset就是数据的地址。

3. RocketMQ这种实现事务⽅式，没有通过KV存储做，⽽是通过Offset⽅式，存在⼀个显著缺陷，即通过Offset更改数据，会令系统的脏⻚过多，需要特别关注。

 

9. 定时消息：

a. 定时消息是指消息发到Broker后，不能⽴刻被Consumer消费，要到特定的时间点或者等待特定的时间后才能被消费。

b. 如果要⽀持任意的时间精度，在Broker层⾯，必须要做消息排序，如果再涉及到持久化，那么消息排序要不可避免的产⽣巨⼤性能开销。

c. RocketMQ⽀持定时消息，但是不⽀持任意时间精度，⽀持特定的level，例如定时5s，10s，1m等。

   

10. 消息重试：

Consumer消费消息失败后，要提供⼀种重试机制，令消息再消费⼀次。Consumer消费消息失败通常可以认为有以下⼏种情况：

i. 由于消息本身的原因，例如反序列化失败，消息数据本身⽆法处理（例如话费充值，当前消息的⼿机号被注销，⽆法充值）等。这种错误通常需要跳过这条消息，再消费其他消息，⽽这条失败的消息即使⽴刻重试消费，99%也不成功，所以最好提供⼀种定时重试机制，即过10s秒后再重试。

ii. 由于依赖的下游应⽤服务不可⽤，例如db连接不可⽤，外系统⽹络不可达等。遇到这种错误，即使跳过当前失败的消息，消费其他消息同样也会报错。这种情况建议应⽤sleep 30s，再消费下⼀条消息，这样可以减轻Broker重试消息的压⼒。

  

11. RocketMq是什么？

上图是⼀个典型的消息中间件收发消息的模型，RocketMQ也是这样的设计，简单说来，RocketMQ具有以下特点：

        是⼀个队列模型的消息中间件，具有⾼性能、⾼可靠、⾼实时、分布式特点。

        Producer、Consumer、队列都可以分布式。

        Producer向⼀些队列轮流发送消息，队列集合称为Topic，Consumer如果做⼴播消费，则⼀个consumer实例消费。

这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合。

        能够保证严格的消息顺序

        提供丰富的消息拉取模式

        ⾼效的订阅者⽔平扩展能⼒

        实时的消息订阅机制

        亿级消息堆积能⼒

        较少的依赖

  

12. RocketMq物理部署结构

Name Server是⼀个⼏乎⽆状态节点，可集群部署，节点之间⽆任何信息同步。

Broker部署相对复杂，Broker分为Master与Slave，⼀个Master可以对应多个Slave，但是⼀个Slave只能对应⼀个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，⾮0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建⽴⻓连接，定时注册Topic信息到所有Name Server。

Producer与Name Server集群中的其中⼀个节点（随机选择）建⽴⻓连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建⽴⻓连接，且定时向Master发送⼼跳。Producer完全⽆状态，可集群部署。

Consumer与Name Server集群中的其中⼀个节点（随机选择）建⽴⻓连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建⽴⻓连接，且定时向Master、Slave发送⼼跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

  

13. RocketMq逻辑结构

1、Producer Group

⽤来表示⼀个发送消息应⽤，⼀个Producer Group下包含多个Producer实例，可以是多台机器，也可以是⼀台机器的多个进程，或者⼀个进程的多个Producer对象。⼀个Producer Group可以发送多个Topic消息，Producer Group 作⽤如下：

1. 标识⼀类Producer

2. 可以通过运维⼯具查询这个发送消息应⽤下有多个Producer实例

3. 发送分布式事务消息时，如果Producer中途意外宕机，Broker会主动回调Producer Group内的任意⼀台机器来确认事务状态。

2、Consumer Group

⽤来表示⼀个消费消息应⽤，⼀个Consumer Group下包含多个Consumer实例，可以是多台机器，也可以是多个进程，或者是⼀个进程的多个Consumer对象。⼀个Consumer Group下的多个Consumer以均摊⽅式消费消息，如果设置为⼴播⽅式，那么这个Consumer Group下的每个实例都消费全量数据。

  

14. RocketMq数据存储结构

如上图所示，RocketMQ采取了⼀种数据与索引分离的存储⽅法。有效降低⽂件资源、IO资源，内存资源的损耗。即便是阿⾥这种海量数据，⾼并发场景也能够有效降低端到端延迟，并具备较强的横向扩展能⼒。