RocketMQ实战（二）Quick Start初步了解消息失败重试机制天然的消息负载均衡及高效的水平扩展机制 集群消费 AND 广播消费

在上一篇《RocketMQ实战（一）》中已经为大家初步介绍了下RocketMQ以及搭建了双Master环境，接下来继续为大家介绍！

Quick Start

写一个简单的生产者、消费者，带大家快速体验RocketMQ~

Maven配置：

pom.xml

生产者：

生产者代码

消费者：

消费者代码

无论生产者、消费者都必须给出GroupName，而且具有唯一性！ 生产到哪个Topic的哪个Tag下，消费者也是从Topic的哪个Tag进行消费，可见这个Tag有点类似于JMS Selector机制，即实现消息的过滤。 生产者、消费者需要设置NameServer地址。 这里，采用的是Consumer Push的方式，即设置Listener机制回调，相当于开启了一个线程。以后为大家介绍Consumer Pull的方式。

我们看一下运行结果：

生产者运行结果

仔细看看生产者结果输出，你会发现，有的消息发往broker-a，有的在broker-b上，自动实现了消息的负载均衡！

消费者运行结果

这里消费消息是没有什么顺序的，以后我们在来谈消息的顺序性。

我们再来看一看管控台：

消息分布在2个broker上

消费后

在多Master模式中，如果某个Master进程挂了，显然这台broker将不可用，上面的消息也将无法消费，要知道开源版本的RocketMQ是没有提供切换程序，来自动恢复故障的，因此在实际开发中，我们一般提供一个监听程序，用于监控Master的状态。 在ActiveMQ中，生产消息的时候会提供是否持久化的选择，但是对于RocketMQ而言，消息是一定会被持久化的！ 上面的消费者采用的是Push Consumer的方式，那么监听的Listener中的消息List到底是多少条呢？虽然提供了API，如consumer.setConsumeMessageBatchMaxSize(10)，实际上即使设置了批量的条数，但是注意了，是最大是10，并不意味着每次batch的都是10，只有在消息有挤压的情况下才有可能。而且Push Consumer的最佳实践方式就是一条条的消费，如果需要batch，可以使用Pull Consumer。 务必保证先启动消费者进行Topic订阅，然后在启动生产者进行生产（否则极有可能导致消息的重复消费，重复消费，重复消费！重要的事情说三遍！关于消息的重复问题后续给大家介绍~）。而且在实际开发中，有时候不会批量的处理消息，而是原子性的，单线程的去一条一条的处理消息，这样就是实时的在处理消息。（批量的处理海量的消息，可以考虑Kafka）

初步了解消息失败重试机制

消息失败，无非涉及到2端：从生产者端发往MQ的失败；消费者端从MQ消费消息的失败；

生产者端的失败重试

生产者端失败重试

生产者端的消息失败：比如网络抖动导致生产者发送消息到MQ失败。 上图代码示例的处理手段是：如果该条消息在1S内没有发送成功，那么重试3次。

消费者端的失败重试

消费者端的失败，分为2种情况，一个是timeout，一个是exception timeout，比如由于网络原因导致消息压根就没有从MQ到消费者上，在RocketMQ内部会不断的尝试发送这条消息，直至发送成功为止！（比如集群中一个broker失败，就尝试另一个broker） exception，消息正常的到了消费者，结果消费者发生异常，处理失败了。这里涉及到一些问题，需要我们思考下，比如，消费者消费消息的状态有哪些定义？如果失败，MQ将采取什么策略进行重试？假设一次性批量PUSH了10条，其中某条数据消费异常，那么消息重试是10条呢，还是1条呢？而且在重试的过程中，需要保证不重复消费吗？

ConsumeConcurrentlyStatus

消息消费的状态，有2种，一个是成功（CONSUME_SUCCESS），一个是失败&稍后重试（RECONSUME_LATER）

broker启动日志

在启动broker的过程中，可以观察下日志，你会发现RECONSUME_LATER的策略。 如果消费失败，那么1S后再次消费，如果失败，那么5S后，再次消费，......直至2H后如果消费还失败，那么该条消息就会终止发送给消费者了！ RocketMQ为我们提供了这么多次数的失败重试，但是在实际中也许我们并不需要这么多重试，比如重试3次，还没有成功，我们希望把这条消息存储起来并采用另一种方式处理，而且希望RocketMQ不要在重试呢，因为重试解决不了问题了！这该如何做呢？

我们先来看一下一条消息MessageExt对象的输出：

MessageExt [queueId=0, storeSize=137, queueOffset=0, sysFlag=0, bornTimestamp=1492213846916, bornHost=/192.168.99.219:50478, storeTimestamp=1492213846981, storeHost=/192.168.99.121:10911, msgId=C0A8637900002A9F0000000000000000, commitLogOffset=0, bodyCRC=613185359, reconsumeTimes=0, preparedTransactionOffset=0, toString()=Message topic=TopicTest2, flag=0, properties={TAGS=TagA, WAIT=true, MAX_OFFSET=3, MIN_OFFSET=0}, body=16]

注意到reconsumeTimes属性，这个属性就代表消息重试的次数！来看一段代码：

reconsumeTime的使用

注意了，对于消费消息而言，存在2种指定的状态（成功 OR 失败重试），如果一条消息在消费端处理没有返回这2个状态，那么相当于这条消息没有达到消费者，势必会再次发送给消费者！也即是消息的处理必须有返回值，否则就进行重发。

天然的消息负载均衡及高效的水平扩展机制

消息的负载均衡

对于RocketMQ而言，通过ConsumeGroup的机制，实现了天然的消息负载均衡！通俗点来说，RocketMQ中的消息通过ConsumeGroup实现了将消息分发到C1/C2/C3/......的机制，这意味着我们将非常方便的通过加机器来实现水平扩展！ 我们考虑一下这种情况：比如C2发生了重启，一条消息发往C3进行消费，但是这条消息的处理需要0.1S，而此时C2刚好完成重启，那么C2是否可能会收到这条消息呢？答案是肯定的，也就是consume broker的重启，或者水平扩容，或者不遵守先订阅后生产消息，都可能导致消息的重复消费！关于去重的话题会在后续中予以介绍！ 至于消息分发到C1/C2/C3，其实也是可以设置策略的。

消息负载策略

集群消费 AND 广播消费

RocketMQ的消费方式有2种，在默认情况下，就是集群消费，也就是上面提及的消息的负载均衡消费。另一种消费模式，是广播消费。广播消费，类似于ActiveMQ中的发布订阅模式，消息会发给Consume Group中的每一个消费者进行消费。

消费模式

设置消费模式

OK，到这里，本期的RocketMQ就结束了，咱们下期见~

周末愉快！