RocketMQ实战（二）

我就是我 2022-06-13 03:24 197阅读 0赞

转自http://www.jianshu.com/p/790d6bc4a1c1

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

# Quick Start #

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

Maven配置：

![1240][]

pom.xml

生产者：

![1240 1][]

生产者代码

消费者：

![1240 2][]

消费者代码

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

我们看一下运行结果：

![1240 3][]

生产者运行结果

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

![1240 4][]

消费者运行结果

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

我们再来看一看管控台：

![1240 5][]

消息分布在2个broker上

![1240 6][]

消费后

> 在多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消费消息的失败；

生产者端的失败重试

![1240 7][]

生产者端失败重试

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

消费者端的失败重试

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

![1240 8][]

ConsumeConcurrentlyStatus

> 消息消费的状态，有2种，一个是成功（CONSUME\_SUCCESS），一个是失败&稍后重试（RECONSUME\_LATER）

![1240 9][]

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属性，这个属性就代表消息重试的次数！来看一段代码：

![1240 10][]

reconsumeTime的使用

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

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

![1240 11][]

消息的负载均衡

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

![1240 12][]

消息负载策略

# 集群消费 AND 广播消费 #

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

![1240 13][]

消费模式

![1240 14][]

设置消费模式

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

[RocketMQ]: http://www.jianshu.com/p/3afd610a8f7d
[1240]: /images/20220613/b4e02f275eff46da8811a07805fa30e5.png
[1240 1]: /images/20220613/32efa1e7c06c4f7db0d066f606e4ef6f.png
[1240 2]: /images/20220613/d966bdc6bfb24128ae05b93f8d180f05.png
[1240 3]: /images/20220613/4a021f1cab2649aea3383c1bbd4268f4.png
[1240 4]: /images/20220613/226f6ed6a2144b47ad7a557cc1cf6df5.png
[1240 5]: /images/20220613/d12630b4a106411889f2b90d3ab063f4.png
[1240 6]: /images/20220613/f247a1e98a55452ca4f4b43bfea8c3a6.png
[1240 7]: /images/20220613/cf9c2b7dc303464baa0b498230103e2f.png
[1240 8]: /images/20220613/e2138ac3e5de4eb08cdf4c48d627842e.png
[1240 9]: /images/20220613/7b710d518ffd49e8ab37304e45f3deea.png
[1240 10]: /images/20220613/9d9a51cd9f3e4f4eb30ded13b45b14be.png
[1240 11]: /images/20220613/f676e21c1fcf456591e654ecddddfdac.png
[1240 12]: /images/20220613/0782c91368024821a5bbd8271a472488.png
[1240 13]: /images/20220613/41e2ad576a894f238848b847c9333beb.png
[1240 14]: /images/20220613/62503e76d92542ac9ed79161f5c94b99.png