1、说明
1.1、场景
为了搞个支持高并发、低延时的基础消息平台,同时要支持js端,造成了现有开源软件选择面太窄,在评估了rabbmitmq、emqtt、activemq、rocketmq后,综合考虑选择了RabbitMQ作为消息中间件,为啥要选RabbitMQ呢,RabbitMQ社区活跃久经沙场、除了AMQP消息协议外支持通过插件方式同时支持MQTT、STOMP协议同时各协议能互通、高性能、支持集群等等综合性原因,选择了它。
在使用方面作为要支持网页端消息基础平台,由于RabbitMQ原生的AMQP协议官方不提供基于websocket的网页端支持,选择了使用MQTT协议作为消息通讯协议。在qos1的情况下,使用如下两种类测试用例:
测试结果表明单个topic的consumer客户端TPS达到1.6w/s时,大量的消息处于unconfirmed状态堵塞在服务端,导致publish发送消息堵塞,发送时延极速增加(达到10多秒),TPS此时已经达到上限无论是新增publish客户端还是新增consumer客户端都无法增加消费的TPS,如下:
由于要基于单个topic的消息路由瞬间大量并发低延时的消息平台来说,这点TPS是不够用,虽然此问题可以通过将消息分散到不同的topic来进行分散处理但是这增加了软件的复杂度和管理难度。
1.2、原因分析
之前有基于AMQP协议对RabbitMQ进行性能测试,上述场景单队列单consumer客户端情