``` 在broker端，默認是不存儲priority信息的，我們需要手動開啟，修改activemq.xml配置文件，在broker標簽的子標簽policyEntries中增加下述配置： <policyEntry?queue=">"?prioritizedMessages="true"/> 不過對于“非持久化”類型的消息(如果沒有被swap到臨時文件)，它們被保存在內存中，它們不存在從文件Paged in到內存的過程，因為可以保證優先級較高的消息，總是在prefetch的時候被優先獲取，這也是“非持久化”消息可以擔保消息發送順序的優點。 Broker在收到Producer的消息之后，將會把消息cache到內存，如果消息需要持久化，那么同時也會把消息寫入文件；如果通道中Consumer的消費速度足夠快(即積壓的消息很少，尚未超過內存限制，我們通過上文能夠知道，每個通道都可以有一定的內存用來cache消息)，那么消息幾乎不需要從存儲文件中Paged In，直接就能從內存的cache中獲取即可，這種情況下，priority可以擔保“全局順序”；不過，如果消費者滯后太多，cache已滿，就會觸發新接收的消息直接保存在磁盤中，那么此時，priority就沒有那么有效了。 在Queue中，prefetch的消息列表默認將會采用“輪詢”的方式(roundRobin，注意并不是roundRobinDispatch)[備注：因為Queue不支持任何DispatchPolicy]，依次添加到每個consumer的pending buffer中，比如有m1-m2-m3-m4四條消息，有C1-C2兩個消費者，那么: m1->C1,m2->C2,m3->C1,m4->C2。這種輪序方式，會對基于權重的消息發送有些額外的影響，假如四條消息的權重都不同，但是(m1,m3)->C1，事實上m2的權重>m3,對于C1而言，它似乎丟失了“順序性”。 ```