RocketMQ学习&最佳实践

官方介绍：http://rocketmq.apache.org/docs/quick-start/

 

一、RocketMQ学习

 RocketMQ优点：

 

	延时	单机写吞吐
RocketMQ	<10ms	3w+

 

 基本概念

 　　1、消息模型（Message Model）

　　　　RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成

　　2、消息生产者（Producer）

　　　　负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要

　　3、消息消费者（Consumer）

　　　　负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：pull拉取式消费、push推动式消费

　　4、主题（Topic）

　　　　表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位

　　5、代理服务器（Broker）

　　　　消息中转角色，负责消息的存储、投递和查询以及服务高可用保证。

　　　　代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等

　　6、名称服务（Name server）

　　　　名称服务充当路由消息的提供者。生产者或消费者能够通过名称服务查找各主题对应的Broker IP列表。

　　　　Name Server是一个非常简单的Topic路由注册中心，其角色类似于kafka中的zookeeper，支持Broker的动态注册与发现。

　　　　NameServer通常也是集群的方式部署，各实例间相互不进行信息通讯。

　　　　Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息

　　7、拉取式消费（Pull Consumer）

　　　　Consumer消费的一种类型，应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程

　　8、推动式消费（Push Consumer）

　　　　Consumer消费的一种类型，该模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高

　　9、生产者组（Producer Group）

　　　　同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费

　　10、消费者组（Consumer Group）

　　　　同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）

　　11、集群消费（Clustering）

　　　　集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息

　　12、广播消费（Broadcasting）

　　　　广播消费模式下，相同Consumer Group的每个Consumer实例都接收全量的消息

　　13、普通顺序消息（Normal Ordered Message）

　　　　普通顺序消费模式下，消费者通过同一个消费队列收到的消息是有顺序的，不同消息队列收到的消息则可能是无顺序的

　　14、严格顺序消息（Strictly Ordered Message）

　　　　严格顺序消息模式下，消费者收到的所有消息均是有顺序的

　　15、消息（Message）

　　　　消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。RocketMQ中每个消息拥有唯一的Message ID，且可以携带具有业务标识的Key。系统提供了通过Message ID和Key查询消息的功能

　　16、标签（Tag）

　　　　为消息设置的标志，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性

 

 

 特性介绍

　　1、订阅与发布

　　　　消息的发布是指某个生产者向某个topic发送消息；

　　　　消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息，进而从该topic消费数据

　　2、消息顺序

　　　　消息有序指的是一类消息消费时，能按照发送的顺序来消费。

　　　　例如：一个订单产生了三条消息分别是订单创建、订单付款、订单完成。消费时要按照这个顺序消费才能有意义，但是同时订单之间是可以并行消费的。RocketMQ可以严格的保证消息有序。

　　　　顺序消息分为全局顺序消息与分区顺序消息，全局顺序是指某个 Topic 下的所有消息都要保证顺序；部分顺序消息只要保证每一组消息被顺序消费即可

　　　　　　1）全局顺序 对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。 适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景

　　　　　　2）分区顺序 对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。 适用场景：性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景

　　3、消息过滤

　　　　RocketMQ的消费者可以根据Tag进行消息过滤，也支持自定义属性过滤。

　　　　消息过滤目前是在Broker端实现的，优点是减少了Consumer无用消息的网络传输，缺点是增加了Broker的负担、而且实现相对复杂

　　4、消息可靠性

　　　　RocketMQ支持消息的高可靠，影响消息可靠性的几种情况

　　　　　　1）Broker非正常关闭

　　　　　　2）Broker异常Crash

　　　　　　3）OS Crash

　　　　　　4）机器掉电，但是能立即恢复供电情况

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

　　　　　　6）磁盘设备损坏

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

　　　　5)、6)属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。注：RocketMQ从3.0版本开始支持同步双写

　　5、至少一次

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

　　6、回溯消息

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

　　7、事务消息

　　　　RocketMQ事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致

　　8、延时消息

　　　　延迟消息是指消息发送到Broker后，不会立即被消费，等待特定时间投递给真正的topic。Broker有配置项 messageDelayLevel，表示消息延迟级别，默认值为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”，从1s到2h分别对应着等级1到18 。

　　　　可以配置自定义messageDelayLevel。注意，messageDelayLevel是broker的属性，不属于某个topic。发消息时，设置delayLevel等级即可：msg.setDelayLevel(level)。

　　　　level有以下三种情况：

　　　　　　1）level == 0，消息为非延迟消息

　　　　　　2）1<=level<=maxLevel，消息延迟特定时间，例如level==1，延迟1s

　　　　　　3）level > maxLevel，则level== maxLevel，例如level==20，延迟2h

　　　　延时消息会暂存在名为SCHEDULE_TOPIC_XXXX的topic中，并根据delayTimeLevel存入特定的queue，queueId = delayTimeLevel – 1，即一个queue只存相同延迟的消息，保证具有相同发送延迟的消息能够顺序消费。broker会调度地消费SCHEDULE_TOPIC_XXXX，将消息写入真实的topic。

　　　　需要注意的是，延时消息会在第一次写入和调度写入真实topic时都会计数，因此发送数量、tps都会变高。

　　9、消息重试

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

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

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

　　　　RocketMQ会为每个消费组都设置一个Topic名称为“%RETRY%+consumerGroup”的重试队列（这里需要注意的是，这个Topic的重试队列是针对消费组，而不是针对每个Topic设置的），用于暂时保存因为各种异常而导致Consumer端无法消费的消息。考虑到异常恢复起来需要一些时间，会为重试队列设置多个重试级别，每个重试级别都有与之对应的重新投递延时，重试次数越多投递延时就越大。RocketMQ对于重试消息的处理是先保存至Topic名称为“SCHEDULE_TOPIC_XXXX”的延迟队列中，后台定时任务按照对应的时间进行Delay后重新保存至“%RETRY%+consumerGroup”的重试队列中

　　10、消息重投

　　　　生产者在发送消息时，同步消息失败会重投，异步消息有重试，oneway没有任何保证。

　　　　消息重投保证消息尽可能发送成功、不丢失，但可能会造成消息重复，消息重复在RocketMQ中是无法避免的问题。消息重复在一般情况下不会发生，当出现消息量大、网络抖动，消息重复就会是大概率事件。另外，生产者主动重发、consumer负载变化也会导致重复消息。如下方法可以设置消息重试策略：

　　　　　　1）retryTimesWhenSendFailed:同步发送失败重投次数，默认为2，因此生产者会最多尝试发送retryTimesWhenSendFailed + 1次。不会选择上次失败的broker，尝试向其他broker发送，最大程度保证消息不丢。超过重投次数，抛出异常，由客户端保证消息不丢。当出现RemotingException、MQClientException和部分MQBrokerException时会重投。
　　　　　　2）retryTimesWhenSendAsyncFailed:异步发送失败重试次数，异步重试不会选择其他broker，仅在同一个broker上做重试，不保证消息不丢。
　　　　　　3）retryAnotherBrokerWhenNotStoreOK:消息刷盘（主或备）超时或slave不可用（返回状态非SEND_OK），是否尝试发送到其他broker，默认false。十分重要消息可以开启。

　　11、流量控制

　　　　生产者流控，因为Broker处理能力达到瓶颈；消费者流控，因为消费能力达到瓶颈

　　　　生产者流控（注意，生产者流控，不会尝试消息重投）：

　　　　　　1）commitLog文件被锁时间超过osPageCacheBusyTimeOutMills时，参数默认为1000ms，返回流控。
　　　　　　2）如果开启transientStorePoolEnable == true，且broker为异步刷盘的主机，且transientStorePool中资源不足，拒绝当前send请求，返回流控。
　　　　　　3）broker每隔10ms检查send请求队列头部请求的等待时间，如果超过waitTimeMillsInSendQueue，默认200ms，拒绝当前send请求，返回流控。
　　　　　　4）broker通过拒绝send 请求方式实现流量控制

 　　　　消费者流控（结果是降低拉取频率）：

　　　　　　1）消费者本地缓存消息数超过pullThresholdForQueue时，默认1000。
　　　　　　2）消费者本地缓存消息大小超过pullThresholdSizeForQueue时，默认100MB。
　　　　　　3）消费者本地缓存消息跨度超过consumeConcurrentlyMaxSpan时，默认2000

　　　　12、死信队列

　　　　　　死信队列用于处理无法被正常消费的消息。

　　　　　　当一条消息初次消费失败，消息队列对自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中

　　　　　　RocketMQ将这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），将存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。在RocketMQ中，可以通过使用console控制台对死信队列中的消息进行重发来使得消费者实例再次进行消费

 

 

 

二、最佳实践

　　1、生产者

　　　　1.1：发送消息注意事项

　　　　　　1）Tags的使用

　　　　　　　　一个应用尽可能用一个Topic，而消息子类型则可以用tags来标识。tags可以由应用自由设置，只有生产者在发送消息设置了tags，消费方在订阅消息时才可以利用tags通过broker做消息过滤：message.setTags("TagA")

　　　　　　2）Keys的使用

　　　　　　　　每个消息在业务层面的唯一标识码要设置到keys字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引（哈希索引），应用可以通过topic、key来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证key尽可能唯一，这样可以避免潜在的哈希冲突

　　　　　　　　String orderId = "20034568923546"; // 订单Id
　　　　　　　　message.setKeys(orderId);

　　　　　　3）日志的打印

　　　　　　　　​消息发送成功或者失败要打印消息日志，务必要打印SendResult和key字段。send消息方法只要不抛异常，就代表发送成功。发送成功会有多个状态，在sendResult里定义。以下对每个状态进行说明：

　　　　　　　　①：SEND_OK

　　　　　　　　　　消息发送成功。要注意的是消息发送成功也不意味着它是可靠的。要确保不会丢失任何消息，还应启用同步Master服务器或同步刷盘，即SYNC_MASTER或SYNC_FLUSH

　　　　　　　　②：FLUSH_DISK_TIMEOUT

　　　　　　　　　　消息发送成功但是服务器刷盘超时。此时消息已经进入服务器队列（内存），只有服务器宕机，消息才会丢失。消息存储配置参数中可以设置刷盘方式和同步刷盘时间长度，如果Broker服务器设置了刷盘方式为同步刷盘，即FlushDiskType=SYNC_FLUSH（默认为异步刷盘方式），当Broker服务器未在同步刷盘时间内（默认为5s）完成刷盘，则将返回该状态——刷盘超时

　　　　　　　　③：FLUSH_SLAVE_TIMEOUT

　　　　　　　　　　消息发送成功，但是服务器同步到Slave时超时。此时消息已经进入服务器队列，只有服务器宕机，消息才会丢失。如果Broker服务器的角色是同步Master，即SYNC_MASTER（默认是异步Master即ASYNC_MASTER），并且从Broker服务器未在同步刷盘时间（默认为5秒）内完成与主服务器的同步，则将返回该状态——数据同步到Slave服务器超时

　　　　　　　　④：SLAVE_NOT_AVAILABLE

　　　　　　　　　　消息发送成功，但是此时Slave不可用。如果Broker服务器的角色是同步Master，即SYNC_MASTER（默认是异步Master服务器即ASYNC_MASTER），但没有配置slave Broker服务器，则将返回该状态——无Slave服务器可用

 

　　　　1.2：消息发送失败处理方式

　　　　　Producer的send方法本身支持内部重试，重试逻辑如下：

　　　　　　1）至多重试2次

　　　　　　2）如果同步模式发送失败，则轮转到下一个Broker，如果异步模式发送失败，则只会在当前Broker进行重试。这个方法的总耗时时间不超过sendMsgTimeout设置的值，默认10s

　　　　　　3）如果本身向broker发送消息产生超时异常，就不会再重试

　　　　以上策略也是在一定程度上保证了消息可以发送成功。如果业务对消息可靠性要求比较高，建议应用增加相应的重试逻辑：比如调用send同步方法发送失败时，则尝试将消息存储到db，然后由后台线程定时重试，确保消息一定到达Broker

　　　　

　　　　1.3：选择oneway形式发送

　　　　　通常消息的发送是这样的一个过程：

　　　　　　1）客户端发送请求到服务器

　　　　　　2）服务端处理请求

　　　　　　3）服务端向客户端返回应答

　　　　　所以，一次消息发送的耗时时间是上述三个步骤的总和，而某些场景要求耗时非常短，但是对可靠性要求并不高，例如日志收集类应用，此类应用可以采用oneway形式调用，oneway形式只发送请求不等待应答，而发送请求在客户端实现层面仅仅是一个操作系统系统调用的开销，即将数据写入客户端的socket缓冲区，此过程耗时通常在微秒级

 

　　2、消费者

    一个topic使用一个消费组

　　　　2.1：消费过程幂等

　　　　　　RocketMQ无法避免消息重复（Exactly-Once），所以如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。

　　　　　　可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是msgId，也可以是消息内容中的唯一标识字段，例如订单id等。在消费处理之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。（实际过程要考虑原子性问题，判断是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过）

　　　　　　msgId一定是全局唯一标识符，但是实际使用中，可能会存在相同的消息有两个不同msgId的情况（消费者主动重发、因客户端重投机制导致的重复等），这种情况就需要使业务字段进行重复消费

 

    2.2：消费失败重试

     并发消费：并发消费消费失败采用的是退避重试的机制，消费失败的消息将发回系统延时队列，每一次消费失败，delayLevel 将 +1，默认最大重试次数为 16 次，超过最大次数将进入死信队列。重试 16 次的时间间隔分别对应延时消息的 level3 ~ level18，时间为 10s ~ 2h

level	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18
延时	1s	5s	10s	30s	1m	2m	3m	4m	5m	6m	7m	8m	9m	10m	20m	30	1h	2h

    顺序消费：顺序消费为了保证顺序，不会发回服务端，采用的是本地不断重试的机制，默认重试消费次数为 Integer.MAX_VALUE, 可设置最大重试次数，超过最大次数将进入死信队列

    配置重试次数：

maxReconsumeTimes

消费失败时的最大重试次数

默认值 -1 （对应并发消费为16 ，顺序消费为 Integer.MAX）

 

 

 

总结：

　　RocketMQ为什么速度快？

　　顺序存储、PageCache和异步刷盘

　　1、顺序存储：消息顺序写入，比随机写入省去磁盘寻址

　　2、写入消息并不是直接写入磁盘，而是先写入操作系统的PageCache

　　3、最后由操作系统异步将缓存中的事务刷到磁盘中

 

 

END.