RocketMQ消费者
1消费过程幂等
RocketMQ无法避免消息重复(Exactly-Once)，所以如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。
可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是msgld，也可以是消息内容中的唯一标识字段，例如订单ld等。
在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。(实际过程要考虑原子性问题，判断是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过)
msgld一定是全局唯一标识符，但是实际使用中，可能会存在相同的消息有两个不同msgld的情况(消费者主动重发、因客户端重投机制导致的重复等)，这种情况就需要使业务字段进行重复消费。
2消费速度慢的处理方式
提高消费并行度
绝大部分消息消费行为都属于10密集型，即可能是操作数据库，或者调用RPC，这类消费行为的消费速度在于后端数据库或者外系统的吞吐量。
通过增加消费并行度，可以提高总的消费吞吐量，但是并行度增加到一定程度，反而会下降。
所以，应用必须要设置合理的并行度。如下有几种修改消费并行度的方法：
●同一个ConsumerGroup下，通过增加Consumer实例数量来提高并行度(需要注意的是超
过订阅队列数的Consumer实例无效)。可以通过加机器，或者在已有机器启动多个进程的
方式。
●提高单个Consumer的消费并行线程，通过修改参数consumeThreadMin、consumeThreadMax实现。
●丢弃部分不重要的消息
批量方式消费
某些业务流程如果支持批量方式消费，则可以很大程度上提高消费吞吐量。
例如订单扣款类应用，一次处理一个订单耗时1 s，一次处理10个订单可能也只耗时2s，这样即可大幅度提高消费的吞吐量，通过设置consumer的consumeMessageBatchMaxSize返个参数，默认是1，即一次只消费一条消息，例如设置为N，那么每次消费的消息数小于等于N。
跳过非重要消息
发生消息堆积时，如果消费速度一直追不上发送速度，如果业务对数据要求不高的话，可以选择丢弃不重要的消息。
例如，当某个队列的消息数堆积到10000条以上，则尝试丢弃部分或全部消息，这样就可以快速追上发送消息的速度。示例代码如下：
public ConsumeConcurrentlyStatus consumeMessage(List msgs,consumeConcurrentlyContext context) {
long offset = msgs.get(0).getQueue0ffset();
String maxoffset = msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET);
1ong diff = Long.parseLong(maxoffset) - offset;
if (diff > 100000) {
// TODO消息堆积情况的特殊处理
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
//TODO正常消费过程
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
3优化每条消息消费过程
举例如下，某条消息的消费过程如下：
●根据消息从DB查询[数据1]
●根据消息从DB查询[数据2]
●复杂的业务计算
●向DB插入[数据3]
●向DB插入[数据4]
这条消息的消费过程中有4次与DB的交互，如果按照每次5ms计算，那么总共耗时20ms，假设业务计算耗时5ms，那么总过耗时25ms，所以如果能把4次DB交互优化为2次，那么总耗时就可以优化到15ms，即总体性能提高了40%。所以应用如果对时延敏感的话，可以把DB部署在SSD硬盘，相比于SCSI磁盘，前者的RT会小很多。
4消费打印日志
如果消息量较少，建议在消费入口方法打印消息，消费耗时等，方便后续排查问题。
如果能打印每条消息消费耗时，那么在排查消费慢等线上问题时，会更方便。
public ConsumeConcurrentlystatus consumeMessage(List msgs,ConsumeConcurrentlyContext context){
log.info("RECEIVE_MSG_BEGIN:" + msgs.tostring());
// TODO 正常消费过程
return ConsumeConcurrentlystatus.CONSUME_SUCCESS;
}
5其他消费建议
(1)关于消费者和订阅
第一件需要注意的事情是，不同的消费组可以独立的消费一些topic，并且每个消费组都有自己的消费偏移量。
确保同一组内的每个消费者订阅信息保持一致。
(2)关于有序消息
消费者将锁定每个消息队列，以确保他们被逐个消费，虽然这将会导致性能下降，但是当你关心消息顺序的时候会很有用。
我们不建议抛出异常，你可以返回
ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT作为替代。
(3)关于并发消费
顾名思义，消费者将并发消费这些消息，建议你使用它来获得良好性能，我们不建议抛出异常，你可以返回ConsumeConcurrentlyStatus.RECONSUME_LATER作为替代。
(4)关于消费状态Consume Status
对于并发的消费监听器，你可以返回RECONSUME_LATER来通知消费者现在不能消费这条消息，并且希望可以稍后重新消费它。然后，你可以继续消费其他消息。对于有序的消息监听器，因为你关心它的顺序，所以不能跳过消息，但是你可以返回SUSPEND_CURRENT.QUEUE_A_MOMENT告诉消费者等待片刻。
(5)关于Blocking
不建议阻塞监听器，因为它会阻塞线程池，并最终可能会终止消费进程
(6)关于线程数设置
消费者使用ThreadPoolExecutor在内部对消息进行消费，所以你可以通过设置
setConsumeThreadMin或setConsumeThreadMax来改变它。
(7)关于消费位点
当建立一个新的消费组时，需要决定是否需要消费经存在于Broker中的历史消息。
CONSUME_FROM_LAST_OFFSET将会忽略历史消息，并消费之后生成的任何消息。
CONSUME_FROM_FIRST_OFFSET将会消费每个存在于Broker中的信息。
也可以使用CONSUME_FROM TIMESTAMP来消费在指定时间戳后产生的消息。
public static void main(String[] args) throws MQClientException {
DefaultMQPushConsumer consumer = new DefaultMQPushconsumer("consumer_grp_15_01");
consumer.setNamesrvAddr("node1: 9988");
consumer.subscribe("sl_demo_18"，"*");
//以下三个选一个使用，如果是根据时间戳进行消费，则需要设置时间戳
//从第一个消息开始消费，从头开始
consumer.setConsumeFromwhere(ConsumeFromwhere.CONSUME_FROM_FIRST_OFFSET);
//从最后一个消息开始消费，不消费历史消息
consumer.setConsumeFromwhere(ConsumeFromwhere.CONSUME_FROM_LAST_OFFSET);
//从指定的时间戳开始消费
consumer.setConsumeFromwhere(ConsumeFromwhere.CONSUME_FROM_TIMESTAMP);
//指定时间戳的值
consumer.setConsumeTimestamp("");
consumer.setMessageListener(new MessageListenerConcurrently() {
@override
public ConsumeConcurrentlyStatus consumeMessage(List msgs, ConsumeConcurrentlyContext context) {
// TODO 处理消息的业务逻辑
return ConsumeConcurrentlystatus.CONSUME_SUCCESS;
// return ConsumeConcurrentlyStatus.RECONSUME.LATER;
});
consumer.start();
}