一、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小时 | 消费不可见时间指的是消息处理+失败后重试间隔的总时长，建议设置时取值比实际需要耗费的时间稍微长一些 |
