RocketMQ实战(三)之生产者、消费者

一：Maven配置

加入rocketmq-client依赖

二：生产者、消费者

1：生产者

2：消费者

DefaultMQPushConsumer和DefaultMQProducer需要设置三个参数：

一是这个Consumer的GroupName,二是NameServer的地址和端口号，三是Topic的名称。

无论生产者、消费者都必须给出GroupName，而且具有唯一性！

生产到哪个Topic的哪个Tag下，消费者也是从Topic的哪个Tag进行消费，可见这个Tag有点类似于JMS Selector机制，即实现消息的过滤。

生产者、消费者需要设置NameServer地址。

三：运行结果

生产者的运行结果：

生产者可以自动实现了消息的负载均衡！

消费者运行结果：

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

我们再来看一看管控台：

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

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

1：生产端的失败重试：

生产者端的消息失败：比如网络抖动导致生产者发送消息到MQ失败。

上图代码示例的处理手段是：如果该条消息在1S内没有发送成功，那么重试3次。

2：消费端的失败重试

消费者端的失败，分为2种情况，一个是timeout，一个是exception

timeout，比如由于网络原因导致消息压根就没有从MQ到消费者上，在RocketMQ内部会不断的尝试发送这条消息，直至发送成功为止！（比如集群中一个broker失败，就尝试另一个broker）

exception，消息正常的到了消费者，结果消费者发生异常，处理失败了。这里涉及到一些问题，需要我们思考下，比如，消费者消费消息的状态有哪些定义？如果失败，MQ将采取什么策略进行重试？假设一次性批量PUSH了10条，其中某条数据消费异常，那么消息重试是10条呢，还是1条呢？而且在重试的过程中，需要保证不重复消费吗？

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

注意了，对于消费消息而言，存在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中的每一个消费者进行消费。