一. 讀寫隊列，是在路由時使用
在消息發送時，根據寫隊列個數返回路由信息，而消息消費時按照讀隊列個數返回路由信息。
二. 在物理文件層面，只有寫隊列才會創建文件
舉個例子：寫隊列個數是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中壓根就沒有消息 ，假設ConsumerGroup有兩個消費者，事實上只有第一個消費者在真正的消費消息(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(同時縮容寫隊列和讀隊列可能會導致部分消息未被消費)
五. Perm（Topic的讀寫模式）
6：同時支持讀寫
4：禁寫
2：禁讀