在創建或更改topic時，需要配置writeQueueNums和readQueueNums數，這里的讀寫隊列有什么作用？
初識rocketmq的童鞋，很容易把讀寫隊列和讀寫分離混淆在一起。其實在rocketmq里是完全不同的兩個概念。讀寫分離，是用HA機制，將一個節點的數據同步到另外一個節點，主節點多用於寫（也可讀），從節點只用於讀。往往一主多從，通過讀寫分離減輕系統壓力。
讀寫隊列，則是在做路由信息時使用。在消息發送時，使用寫隊列個數返回路由信息，而消息消費時按照讀隊列個數返回路由信息。在物理文件層面，只有寫隊列才會創建文件。舉個例子：寫隊列個數是8，設置的讀隊列個數是4.這個時候，會創建8個文件夾，代表0 1 2 3 4 5 6 7，但在消息消費時，路由信息只返回4，在具體拉取消息時，就只會消費0 1 2 3這4個隊列中的消息，4 5 6 7壓根就沒有被消費。反過來，如果寫隊列個數是4，讀隊列個數是8，在生產消息時只會往0 1 2 3中生產消息，消費消息時則會從0 1 2 3 4 5 6 7所有的隊列中消費，當然 4 5 6 7中壓根就沒有消息 ，假設消費group有兩個消費者，事實上只有第一個消費者在真正的消費消息(0 1 2 3)，第二個消費者壓根就消費不到消息。
由此可見，只有readQueueNums>=writeQueueNums,程序才能正常進行。最佳實踐是readQueueNums=writeQueueNums。那rocketmq為什么要區分讀寫隊列呢？直接強制readQueueNums=writeQueueNums，不就沒有問題了嗎？
rocketmq設置讀寫隊列數的目的在於方便隊列的縮容和擴容。思考一個問題，一個topic在每個broker上創建了128個隊列，現在需要將隊列縮容到64個，怎么做才能100%不會丟失消息，並且無需重啟應用程序？
最佳實踐：先縮容寫隊列128->64，寫隊列由0 1 2 ......127縮至 0 1 2 ........63。等到64 65 66......127中的消息全部消費完后，再縮容讀隊列128->64.(同時縮容寫隊列和讀隊列可能會導致部分消息未被消費)
轉自：https://blog.csdn.net/qian_348840260/article/details/108975241