记一次 rocketmq 使用时的异常。

  这里就不说什么rocketmq 源码啥的了,因为没看过。网上一搜这两个异常 大部分都是什么源码解读,也没说出现后的解决办法(蓝瘦香菇)。

大量测试发现:

1、system busy , start flow control for a while

  该异常会造成 消息丢失。

2、broker busy , start flow control for a while

  该异常不会造成消息丢失。(这是最坑的,都异常了消息竟然是正常发送了的。)

 

解决过程:

1、最开始时候 ,测试发现在性能好的服务器上 只会出现system busy,也就是说出现异常就会消息丢失。

  所以:业务代码进行处理,出现异常就会重发到当前topic的 bak队列,当时想的是既然这个topic busy了,就换到另外的topic去发,总不能都 busy吧。

也算是临时解决了。

2、运行一年后,可能是服务器上运行的东西多了,或者其他原因。发现有消息重复的现象。不用想肯定是报broker busy异常,重发到topic的 bak队列了。又因为broker busy可能不会造成消息丢失,所以消息重复就出现了。

3、无奈,找新的解决方法。本来想的是判断异常,如果是broker busy就不重发了。

报着试一试的态度,又去百度了一下,还是搜出来一堆源码解读。搭上梯子,google一下,还真找到了。

https://stackoverflow.com/questions/47749906/rocketmq-throw-exception-timeout-clean-queuebroker-busy-start-flow-control-f

https://www.cnblogs.com/cs99lzzs/p/9181555.html

想到不知道在哪看的的一句话,在stackoverflow上能找到和你一样的问题,那问题已经解决了百分之90了。这他喵的真实至理名言啊。

==============吐槽完=================

又经过大量测试验证:

解决方案:

修改rocketmq配置文件:

方案一:sendMessageThreadPoolNums 改成 1 ,没有的话新增一行。

  sendMessageThreadPoolNums=1

方案二(推荐):useReentrantLockWhenPutMessage改成true,没有的话新增一行。

  sendMessageThreadPoolNums=32

  useReentrantLockWhenPutMessage=true

 

说明:

  sendMessageThreadPoolNums这个属性是发送线程池大小, rocketmq4.1版本之后默认为 1,之前版本默认什么不知道但是肯定大于1。这个属性改成1的话,就不用管useReentrantLockWhenPutMessage这个属性了;

  如果改成大于1,就需要将useReentrantLockWhenPutMessage这个属性设置为 true;

  目前测试 未发现这两个方案有什么区别,sendMessageThreadPoolNums=1 时也支持多线程发送,发送速度感觉和 sendMessageThreadPoolNums大于1没有区别,都能跑满100M的网卡。

  感觉如果useReentrantLockWhenPutMessage=true的时候,就是打开锁(属性名翻译一下也大概是这个意思),然后关键代码其实还是单线程处理;

  有闲功夫的话去翻翻源码看看去。

  最后 我是选择的方案二,毕竟看着好看点。

内容来源于网络如有侵权请私信删除