rabbitmq 限制速度_提升RabbitMQ消费速度的一些实践

RabbitMQ是一个开源的消息中间件，自带管理界面友好、开发语言支持广泛、没有对其它中间件的依赖，而且社区非常活跃，特别适合中小型企业拿来就用。这篇文章主要探讨提升RabbitMQ消费速度的一些方法和实践，比如增加消费者、提高Prefetch count、多线程处理、批量Ack等。

增加消费者

这个道理比较容易理解，多个人搬砖的速度肯定比一个人要快很多。

不过实际情况中还需要面对一些技术挑战，比如后端处理能力、并发冲突，以及处理顺序。

后端处理能力：比如多个消费者都要操作数据库，那么数据库连接的并发数和读写吞吐量就是后端处理能力，如果达到了数据库的最大处理能力，增加再多的消费者也没有用，甚至会因为数据库拥塞导致整体消费速度的下降。这个问题还存在另一种情况，就是消费者是否真正的发挥了后端服务的处理能力，比如使用Redis时是否采用了多线程、IO复用等方式来进一步提升吞吐量。

并发冲突：比如两个消费者都要去修改用户的积分，单个消费者的做法可能就是取出来、改下字段的值、最后再update到数据库，多个消费者时如果同时取出了相同的数据，还这样处理的话就会出问题了。这时候可能需要修改下SQL语句，直接在SQL语句中修改积分，由数据库写入事务来处理并发冲突；或者搞一个分布式锁，对于具体的某个用户同时只能有一个消费者来处理其积分。

处理顺序：如果消息需要被顺序处理，那么各个消费者之间还需要增加一个同步机制。比如基于GPS定位的电子围栏，在出围栏的某个时段，先产生了围栏内定位消息、然后产生了围栏外定位消息；如果围栏外定位消息先被一个消费者处理，则判定为出围栏，这没有问题；然后围栏内定位消息被另一个消费者处理，则会被判定为入围栏，这个就属于误判了。这时候可能要同步一个已处理定位时间，早于这个时间的定位就抛弃掉；或者同一个设备的定位消息通过某种算法控制只能由某个消费者进行处理。

解决后边两个问题的方法不可避免的要引入多个消费者之间的协商机制，如果这些协商机制设计不好会对处理速度带来很大影响。因此多人搬砖速度快的前提是多个人搬砖时不需要大家频繁的坐下来协商谁搬哪块砖，否则就会浪费很多时间在相互协调上，反而不能提升搬砖的速度。

所以通过增加消费者提升消费速度得以成立的前提是消费者业务并发处理能力要足够，消费者依赖的后端服务处理能力也要足够