分布式消息队列RocketMQ

一、RocketMQ概述

---

1.1 MQ 概述

MQ，Message Queue，是一种提供消息队列服务的中间件，也成为消息中间件，是一套提供了消息生产、存储、消费全过程API的软件系统。消息即数据

1.2 MQ 用途

MQ的用途总结起来可分为以下三点

• 限流削峰

MQ可以将系统的超量请求暂存其中，以便系统后期可以慢慢进行处理，从而避免了请求的丢失或系统被压垮

• 异步解耦

上游系统对下游系统的调用若为同步调用，则会大大降低系统的吞吐量与并发度，且系统耦合度太高。而异步调用则会解决这些问题。所以两层之间若要实现由同步到异步的转化，一般性做法就是，在这两层间添加一个MQ层

• 数据收集

分布式系统会产生海量数据，如：业务日志、监控数据、用户行为等。针对这些数据流进行实时或批量采集汇总，然后对这些数据流进行大数据分析，这是当前互联网平台的必备技术。通过MQ完成此类数据收集是最好的选择

1.3 常见 MQ 产品

• ActiveMQ

ActiveMQ 是使用Java语言开发一款MQ产品。早期很多公司与项目中都在使用。但现在的社区活跃度已经很低。现在的项目中已经很少使用了

• RabbitMQ

RabbitMQ 是使用 ErLang 语言开发的一款MQ产品。其吞吐量较 Kafka 与 RocketMQ 要低，且由于其不是Java语言开发，所以公司内部对其实现定制化开发难度较大。对于Spring Cloud Netflix，其仅支持 RabbitMQ 与 Kafka。吞吐量在5.95w/s，CPU资源消耗较高

• Kafka

Kafka 是使用Scala / Java语言开发的一款MQ产品。其最大的特点就是高吞吐量，常用于大数据领域的实时计算、日志采集等场景。其没有遵循任何常见的MQ协议，而是使用自研协议，会出现数据丢失，功能比较单一。吞吐量高达17.w/s，这主要取决于它的队列模式保证了写磁盘的过程是线性IO。此时broker磁盘IO已达瓶颈

• RocketMQ

RocketMQ 是使用Java语言开发的一款MQ产品。经过数年阿里双11的考验，性能与稳定性非常高。其没有遵循任何常见的MQ协议，而是使用自研协议。对于Spring Cloud Alibaba，其支持RabbitMQ、Kafka，但没有提倡使用 RocketMQ。吞吐量在11.6w/s，磁盘IO%util已接近100%。RocketMQ的消息写入内存后即返回ack，由单独的线程专门做刷盘的操作，所有的消息均是顺序写文件

1.4 MQ 的优缺点

• 系统可用性减低

系统引入外部依赖增多，系统的稳定性就会变差。一旦MQ宕机，对业务会产生影响。这就需要考虑如何保证MQ的高可用

• 系统复杂度提高

引入MQ后系统复杂度会大大提高。以前服务之间可以进行同步的服务调用，引入MQ后，就会变成异步调用，数据的链路就会变得更加复杂。并且还会带来其他一些问题。比如：如何保证消费的消息不会丢失？不会重复消费消息？如何保证消息的顺序性等问题

• 消息一致性问题

A系统处理完业务，通过MQ发送消息给B、C系统进行后续的业务处理。如果B系统处理成功，C系统处理失败，这事就需要考虑如何保证消息数据处理的一致性

1.5 MQ 常见协议

• JMS

JMS，Java Messaging Service（Java消息服务）。是Java平台上有关MOM（Message Oriented Middleware，面向消息的中间件）的技术规范，它便于消息系统中的Java应用程序进行消息交换，并且通过提供标准的产生、发送、接收消息的接口，简化企业应用开发。AcitveMQ是该协议的典型实现

• STOMP

STOMP，Streaming Text Oriented Message Protocol（面向文本流消息协议），是一种MOM设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。ActiveMQ是该协议的典型实现，RabbitMQ通过插件可以支持该协议

• AMQP

AMQP，Advanced Message Queuing Protocol（高级消息队列协议），是一个提供统一消息服务的应用层标准，是应用层协议的一个开放标准，是一种MOM设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端 / 中间件不同产品，不同开发语言等条件限制。RabbitMQ是该协议的典型实现

• MQTT

MQTT，Message Queuing Telemetry Transport（消息队列遥感测传输），是IBM开发的一个即时通讯协议，是一种二进制协议，主要用于服务器和低低功耗IoT（物联网）设备间的通信。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当作传感器和制动器的通信协议。RabbitMQ通过插件可以支持该协议

1.6 参考约束和建议

Apache RocketMQ 系统中存在很多自定义参数和资源命名，您在使用 Apache RocketMQ 时建议参考如下说明规范系统设置，避对某些具体参数设置不合理导致应用出现异常

参数	建议范围	说明
Topic名称	字符建议：字母az或AZ、数字0~9以及下划线（）、短划线（-）和百分号（%）。 长度建议：1~64个字符。 系统保留字符：Topic名称不允许使用以下保留字符或含有特殊前缀的字符命名。 保留字符: TBW102 *BenchmarkTest* SELF_TEST_TOPIC *OFFSET_MOVED_EVENT* SCHEDULE_TOPIC_XXXX *RMQ_SYS_TRANS_HALF_TOPIC* RMQ_SYS_TRACE_TOPIC *RMQ_SYS_TRANS_OP_HALF_TOPIC 特殊前缀:* rmq_sys %RETRY% %DLQ% rocketmq-broker-	Topic命名应该尽量使用简短、常用的字符，避免使用特殊字符。特殊字符会导致系统解析出现异常，字符过长可能会导致消息收发被拒绝
ConsumerGroup名称	字符建议：支持字母az或AZ、数字0~9以及下划线（）、短划线（-）和百分号（%）。 长度建议：1~64个字符。 系统保留字符：ConsumerGroup不允许使用以下保留字符或含有特殊前缀的字符命名。 保留字符: *DEFAULT_CONSUMER* DEFAULT_PRODUCER *TOOLS_CONSUMER* FILTERSRV_CONSUMER *__MONITOR_CONSUMER* CLIENT_INNER_PRODUCER *SELF_TEST_P_GROUP* SELF_TEST_C_GROUP *CID_ONS-HTTP-PROXY* CID_ONSAPI_PERMISSION *CID_ONSAPI_OWNER* CID_ONSAPI_PULL *CID_RMQ_SYS_TRANS* 特殊字符 * CID_RMQ_SYS * CID_HOUSEKEEPING	无
ACL Credentials	字符建议：AK（AccessKey ID）、SK（AccessKey Secret）和Token仅支持字母az或AZ、数字0~9。 长度建议：不超过1024个字符	无
请求超时时间	默认值：3000毫秒。 取值范围：该参数为客户端本地行为，取值范围建议不要超过30000毫秒	请求超时时间是客户端本地同步调用的等待时间，请根据实际应用设置合理的取值，避免线程阻塞时间过长
消息大小	默认值：不超过4 MB。不涉及消息压缩，仅计算消息体body的大小。 取值范围：建议不超过4 MB	消息传输应尽量压缩和控制负载大小，避免超大文件传输。若消息大小不满足限制要求，可以尝试分割消息或使用OSS存储，用消息传输URL
消息自定义属性	字符限制：所有可见字符。 长度建议：属性的Key和Value总长度不超过16 KB。 系统保留属性：不允许使用以下保留属性作为自定义属性的Key。 保留属性Key	无
MessageGroup	字符限制：所有可见字符。 长度建议：1~64字节	MessageGroup是顺序消息的分组标识。一般设置为需要保证顺序的一组消息标识，例如订单ID、用户ID等
消息发送重试次数	默认值：3次。 取值范围：无限制	消息发送重试是客户端SDK内置的重试策略，对应用不可见，建议取值不要过大，避免阻塞业务线程。 如果消息达到最大重试次数后还未发送成功，建议业务侧做好兜底处理，保证消息可靠性
消息消费重试次数	默认值：16次	消费重试次数应根据实际业务需求设置合理的参数值，避免使用重试进行无限触发。重试次数过大容易造成系统压力过量增加
事务异常检查间隔	默认值：60秒	事务异常检查间隔指的是，半事务消息因系统重启或异常情况导致没有提交，生产者客户端会按照该间隔时间进行事务状态回查。 间隔时长不建议设置过短，否则频繁的回查调用会影响系统性能
半事务消息第一次回查时间	默认值：取值等于[事务异常检查间隔] * 最大限制：不超过1小时	无
半事务消息最大超时时长	默认值：4小时。 * 取值范围：不支持自定义修改	半事务消息因系统重启或异常情况导致没有提交，生产者客户端会按照事务异常检查间隔时间进行回查，若超过半事务消息超时时长后没有返回结果，半事务消息将会被强制回滚。 您可以通过监控该指标避免异常事务
PushConsumer本地缓存	默认值： *最大缓存数量：1024条。 *最大缓存大小：64 M。 取值范围：支持用户自定义设置，无限制	消费者类型为PushConsumer时，为提高消费者吞吐量和性能，客户端会在SDK本地缓存部分消息。缓存的消息的数量和大小应设置在系统内存允许的范围内
PushConsumer重试间隔时长	默认值： *非顺序性投递：间隔时间阶梯变化，具体取值，请参见PushConsumer消费重试策略。 *顺序性投递：3000毫秒	无
PushConsumer消费并发度	默认值：20个线程	无
获取消息最大批次	默认值：32条	消费者从服务端获取消息时，一次获取到最大消息条数。建议按照实际业务设置合理的参数值，一次获取消息数量过大容易在消费失败时造成大批量消息重复
SimpleConsumer最大不可见时间	默认值：用户必填参数，无默认值。 取值范围建议：最小10秒；最大12小时	消费不可见时间指的是消息处理+失败后重试间隔的总时长，建议设置时取值比实际需要耗费的时间稍微长一些