RocketMQ是企业级的，经过这段时间的学习，简单的总结下，为什么选择RocketMQ可参考Why choose RocketMQ

消息模型和消费模式

• 消息模型分为广播(Broadcast)和集群(Cluster),广播就是一条消息被所有消费者消费，应用场景：网关推送、推送配置、；集群就是，一条消息只会被一个消费者消费，应用场景：微服务解耦。

• 消费模式分为Concurrent、Orderly，Concurrent就是M1、M2两条消息可以被同时消费，M2可以不用等M1被消费完；Orderly就是先消费完M1才能消费M2，M1消费完之前M2不能被消费。

通过RocketMQMessageListener的messageModel、consumeMode就能看出来。

org.apache.rocketmq.spring.annotation.RocketMQMessageListener
	/**
	*Control consume mode, you can choice receive message concurrently or
	*/
	ConsumeMode consumeMode() default ConsumeMode.CONCURRENTLY;

    /**
     * Control message mode, if you want all subscribers receive message all message, broadcasting is a good choice.
     */
    MessageModel messageModel() default MessageModel.CLUSTERING;

org.apache.rocketmq.spring.annotation.ConsumeMode
public enum ConsumeMode {
    /**
     * Receive asynchronously delivered messages concurrently
     */
    CONCURRENTLY,

    /**
     * Receive asynchronously delivered messages orderly. one queue, one thread
     */
    ORDERLY
}

org.apache.rocketmq.spring.annotation.MessageModel
public enum MessageModel {
    BROADCASTING("BROADCASTING"),
    CLUSTERING("CLUSTERING");
}

发送重试

rocketmq在发送时会重试，确保消息的发送成功性，超过最大重试次数则报错，发送分为同步发布和异步发送;

• 发送失败时，会立刻进行重试，除非触发了throttle
• 触发throttle后，重试间隔随着次数会变长

消费重试

在消费消息时如果出错或者超时，则会消费重试，所以业务逻辑要保持幂等性。

消费者的负载均衡

分为消息负载均衡和队列负载均衡,基于消息的负载均衡，是push consumer、simple consumer唯一且默认的策略；基于队列的负载均衡是pull consumer的默认策略。

• 基于消息的负载均衡



• 
  
• 基于队列的负载均衡

最佳实践

生产者

发送消息的预防措施

tag的使用

一个应用使用一个topic，然后tag自由设置

key的使用

Message的Key最好是独一无二的、不重复的值，比如订单id、用户id、请求id，这里区分一下Msg Id和Msg Key

Message ID

Definition: the unique identifier of a message. The ID of each message is globally unique in the cluster.

Values: automatically generated by the producer client. A message ID is a string of 32 characters that consists of digits and uppercase letters.

(Optional) Message keys

Definition: the list of index keys for messages. You can configure different keys to distinguish between messages and quickly find messages.

Values: defined by the producer client.

Msg Id是生产者客户端自动生成，是全局唯一的；Msg Key是可选的，由用户填入，通常用来与其它消息做区分，用来快速查找消息。

打印log

打印消息的发送结果（成功或者失败），以在出问题时排查。

处理发送失败的情况

虽然发送有重试机制，只能确保一定程度的发送可靠性，如果不容许消息丢失，则在发送失败时，最好存入数据库，然后再定时发送。

消费者

消费方法是幂等的

RocketMQ不能避免消费重复，所以如果业务对消息重复敏感，则要在业务层面去处理。通常要借助于关系型数据，首先判断消息一个独一无二的key，比如msgId或者消息内容中的订单id，如果数据库中存在则不再处理；如果数据库不存在，则插入、消费。
msgId肯定是全局唯一的，但在实际中，通常因为消费重试、发送重试可能存在相同内容的两条消息有不同的msgId。

消费变慢

增加消费的并行性

消息消费是IO密集型操作，通常是操作数据库或者RPC调用。

• 在同一个ConsumerGroup，新增Consumer的实例数，比如新增一台机器或者在同一台机器上新增服务。
• 增加各个Consumer的消费并行线程数，比如PushConsumer、SimpleConsumer

批量消费

某些业务进程支持批量消费，消费吞吐量能答复改善。比如比如应用的订单消费一次花费1秒处理一个订单，但可能一次，花费2秒处理10个订单，所以吞吐量能大幅提升。推荐SimpleConsumer ，设置每个调用接口的批量大小，从而一次推送多条消息。

Reset site to skip non-important messages

消息大量涌入，如果消费速率跟不上分发速率，并且业务并不要求所有数据，那么可以选择抛弃不重要的消息。You are advised to use the reset site function to directly adjust the consumption site to a specified time or location.

优化每条消息的消费过程

比如，消费一条消息的过程如下

Query [data 1] from DB according to message
Query [data 2] from DB according to message
Complex business calculations
Insert [data 3] into DB
Insert [data 4] into DB

假如每次DB交互耗时5ms，整个消费5ms，那整个就是4*5+5=25ms，假如4次DB交互缩减为2次，那么优化后总时间15ms，这也就意味着总体性能提升了40%；如果应用对延迟很敏感，则DB可以部署到SSD硬盘上，相比SCSI硬盘，前者的RT小很多。

消费打印日志

如果消息数量比较小，建议在消费的入口方法处，打印消息，就是消费的时间会更长一些。

Broker

Broker Role

Broker roles可以归类为 ASYNC_MASTER, SYNC_MASTER, and SLAVE。如果对消息可靠性，你有严格的需求，那么部署SYNC_MASTER + SLAVE。如果不要求消息可靠性，则部署ASYNC_MASTER + SLAVE。如果仅仅是测试，则部署ASYNC_MASTER only 或者 SYNC_MASTER

FlushDiskType

相比ASYNC_FLUSH，SYNC_FLUSH 会有性能损失，但更加可靠。因此要根据实际场景做权衡。

Broker Configuration

当安装在docker容器中时，要设置brokerIP1，否则无法访问。