錯誤理解

之所以將這個標題，定義為錯誤理解，原因就是無法真正的說服自己；

訊息佇列的模式有兩種pull與push.先說說我之前的理解：

• pull模式指，客戶端連線上broker之後，主動發起方法呼叫獲取遠端的結果，說的直白一點就是一次RPC呼叫，即同步方法呼叫;

• push模式:

  客戶端與broker建立連線，當有訊息進入broker,broker進行訊息推送至所有的連線客戶端,即非同步方法呼叫；但是真正的實現中broker一般是很難維護這麼多長連線，那麼它又是如何實現push的呢?

activemq的pull與push模式實現方式

今天有時間，於是打開了activemq 的5.14.x的程式碼，一探究竟。對於activemq的程式碼我不作描述，本文主是為了糾正思想。對於訊息佇列pull與push模式的實現方式如下：

• pull模式

  客戶端(指一個connection,一般情況指一個tcp的連線建立)連線到broker之後，啟動一個執行緒，這個執行緒的任務就是迴圈呼叫方法從broker中拉取相應的訊息至本地。如果是同步方法呼叫獲取則將相應的訊息存放在本地記憶體中，當同步方法消費訊息時，則從該記憶體區中直接獲取相應的訊息進行消費；

• push模式

  客戶端連線到broker之後，啟動一個執行緒，這個執行緒的任務就是迴圈呼叫方法從broker中拉取相應的訊息至本地。如果是非同步方法呼叫，則直接呼叫監聽器方法，間接呼叫業務消費訊息的方法，而不使用本地記憶體進行訊息的快取;所以這裡的非同步只是客戶端的非同步，而非broker的主動推送。通過這種方式既能解決多客戶端的連線，也能解決類似服務端的push型的訊息推送。在網際網路中這種實現才具有普便性，因為這種方式即解決了效能問題又解決了非同步訊息的需求。

通過對於pull與push的模式對比，可以非常清晰的理解如下問題:

• 為什麼在網際網路上大吞吐量的訊息佇列都是採用pull模式，而非broker push模式？
• 為什麼採用broker push模式，由於消費端的效能會影響整個訊息佇列伺服器的效能？
• 為什麼採用broker push模式，容易造成broker的訊息積壓?

總結

對於網路的理解沒有深刻認識，就會造成一種想當然的認識，然後自己就會進行一個誤區，以至於問題無法解決。那麼換一個思路則山重水複疑無路，柳暗花明又一村。

思路決定出路…