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

一:Maven配置

加入rocketmq-client依赖

RocketMQ实战(三)之生产者、消费者_第1张图片

二:生产者、消费者

1:生产者

RocketMQ实战(三)之生产者、消费者_第2张图片

2:消费者

RocketMQ实战(三)之生产者、消费者_第3张图片

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

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

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

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

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

三:运行结果

生产者的运行结果:

RocketMQ实战(三)之生产者、消费者_第4张图片

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

消费者运行结果:

RocketMQ实战(三)之生产者、消费者_第5张图片

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

我们再来看一看管控台:

RocketMQ实战(三)之生产者、消费者_第6张图片

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

消息失败,无非涉及到2端:从生产者端发往MQ的失败;消费者端从MQ消费消息的失败

1:生产端的失败重试:

RocketMQ实战(三)之生产者、消费者_第7张图片

RocketMQ实战(三)之生产者、消费者_第8张图片

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

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

2:消费端的失败重试

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

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

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

RocketMQ实战(三)之生产者、消费者_第9张图片

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

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

RocketMQ实战(三)之生产者、消费者_第10张图片

对于RocketMQ而言,通过ConsumeGroup的机制,实现了天然的消息负载均衡!通俗点来说,RocketMQ中的消息通过ConsumeGroup实现了将消息分发到C1/C2/C3/......的机制,这意味着我们将非常方便的通过加机器来实现水平扩展!

我们考虑一下这种情况:比如C2发生了重启,一条消息发往C3进行消费,但是这条消息的处理需要0.1S,而此时C2刚好完成重启,那么C2是否可能会收到这条消息呢?答案是肯定的,也就是consume broker的重启,或者水平扩容,或者不遵守先订阅后生产消息,都可能导致消息的重复消费!关于去重的话题会在后续中予以介绍!

至于消息分发到C1/C2/C3,其实也是可以设置策略的。

RocketMQ实战(三)之生产者、消费者_第11张图片

五:集群消费 AND 广播消费

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

RocketMQ实战(三)之生产者、消费者_第12张图片

 

你可能感兴趣的:(RocketMQ实战(三)之生产者、消费者)