RocketMQ生产者

一、Tags的使用

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

message.setTags("TagA")。

二、 Keys的使用

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

//订单Id

String orderld = "20034568923546";

message.setKeys(orderld);

三、日志的打印

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

/....../
package org.apache.rocketmq.client.producer;

public enum SendStatus{
    SEND_OK,
    FLUSH_DISK_TIMEOUT,
    FLUSH_SLAVE_TIMEOUT,
    SLAVE_NOT_AVAILABLE
}

以下对每个状态进行说明：

●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服务器可用。

四、消息发送失败处理方式

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

●至多重试2次(同步发送为2次，异步发送为0次)。

●如果发送失败，则轮转到下一个Broker。这个方法的总耗时时间不超过sendMsgTimeout设置的值，默认10s。

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

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

上述db重试方式为什么没有集成到MQ客户端内部做，而是要求应用自己去完成，主要基于以下几点考虑：

1. MQ的客户端设计为无状态模式，方便任意的水平扩展，且对机器资源的消耗仅仅是cpu、内存、网络。

2.如果MQ客户端内部集成一个KV存储模块，那么数据只有同步落盘才能较可靠，而同步落盘本身性能开销较大，所以通常会采用异步落盘，又由于应用关闭过程不受MQ运维人员控制，可能经常会发生kill -9这样暴力方式关闭，造成数据没有及时落盘而丢失。

3. Producer所在机器的可靠性较低，一般为虚拟机，不适合存储重要数据。综上，建议重试过程交由应用来控制。

五、选择oneway形式发送

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

●客户端发送请求到服务器

●服务器处理请求

●服务器向客户端返回应答

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