PS：JMQ是公司內(nèi)部的消息中間件，不同MQ之間存在數(shù)據(jù)上的差異，但理論可借鑒；
JMQ主題創(chuàng)建時(shí)，默認(rèn)隊(duì)列數(shù)為5. 即該主題在每個(gè)broker上會(huì)創(chuàng)建5個(gè)隊(duì)列。
每個(gè)隊(duì)列內(nèi)的消息先進(jìn)先出， 在沒有打開并行消費(fèi)的情況下，當(dāng)隊(duì)列中有消息被拉取且沒有被ACK時(shí)，該隊(duì)列會(huì)被加鎖，其它客戶端進(jìn)程無法拉取到該隊(duì)列上剩余消息。
所以當(dāng) 客戶端進(jìn)程數(shù)> 主題擁有的broker數(shù)*主題隊(duì)列數(shù) 時(shí)，客戶端并發(fā)量受限。 這時(shí)增加消費(fèi)者實(shí)例數(shù)會(huì)造成部分實(shí)例空閑，將不再能增加消息處理能力，增大隊(duì)列數(shù)可以讓客戶端的線程得到充分利用。
需要注意的是：如果客戶端代碼中沒有顯示的配置最大線程數(shù)， 則默認(rèn)情況下，最大線程數(shù)會(huì)被設(shè)置為隊(duì)列數(shù)。 在這種情況下，調(diào)大隊(duì)列數(shù)會(huì)導(dǎo)致客戶端線程數(shù)增加， 使客戶端CPU負(fù)載和內(nèi)存使用率增高，存在導(dǎo)致客戶端宕機(jī)的風(fēng)險(xiǎn)。
以jbp_mq為例：
topic：jbp_to_bu_topic
CPU/內(nèi)存使用情況如下：
線程連接數(shù)： 消費(fèi)者112個(gè)
broker數(shù)：4個(gè)
隊(duì)列數(shù)：10個(gè)
