RPC和Message Queue對比

RPC和Message Queue對比

RPC、MQ的結構對比：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

RPC系統結構：   +----------+     +----------+ | Consumer | <=> | Provider | +----------+     +----------+ Consumer調用的Provider提供的服務。     Message Queue系統結構：   +--------+     +-------+     +----------+ | Sender | <=> | Queue | <=> | Receiver | +--------+     +-------+     +----------+ Sender發送消息給Queue；Receiver從Queue拿到消息來處理。 來源： <http://www.cnblogs.com/xiazh/archive/2013/03/17/2964203.html>

功能特色

---

在架構上，RPC和Message的差別點是，Message有一箇中間結點Message Queue，能夠把消息存儲。

消息的特色

---

• Message Queue把請求的壓力保存一下，逐漸釋放出來，讓處理者按照本身的節奏來處理。

• Message Queue引入一下新的結點，讓系統的可靠性會受Message Queue結點的影響。

• Message Queue是異步單向的消息。發送消息設計成是不須要等待消息處理的完成。

因此對於有同步返回需求，Message Queue則方向。

PRC的特色

---

• 同步調用，對於要等待返回結果/處理結果的場景，RPC是能夠很是天然直覺的使用方式。
  # RPC也能夠是異步調用。

• 因爲等待結果，Consumer（Client）會有線程消耗。

若是以異步RPC的方式使用，Consumer（Client）線程消耗能夠去掉。但不能作到像消息同樣暫存消息/請求，壓力會直接傳導到服務Provider。

適用場合說明

---

• 但願同步獲得結果的場合，RPC合適。

• 但願使用簡單，則RPC；RPC操做基於接口，使用簡單，使用方式模擬本地調用。異步的方式編程比較複雜。

• 不但願發送端（RPC Consumer、Message Sender）受限於處理端（RPC Provider、Message Receiver）的速度時，使用Message Queue。

隨着業務增加，有的處理端處理量會成爲瓶頸，會進行同步調用到異步消息的改造。

這樣的改造實際上有調整業務的使用方式。

好比原來一個操做頁面提交後就下一個頁面會看處處理結果；改造後異步消息後，下一個頁面就會變成「操做已提交，完成後會獲得通知」。

不適用場合說明

---

RPC同步調用使用Message Queue來傳輸調用信息。 上面分析能夠知道，這樣的作法，發送端是在等待，同時佔用一箇中間點的資源。變得複雜了，但沒有對等的收益。

對於返回值是void的調用，能夠這樣作，由於實際上這個調用業務上每每不須要同步獲得處理結果的，只要保證會處理便可。（RPC的方式能夠保證調用返回即處理完成，使用消息方式後這一點不能保證了。）

返回值是void的調用，使用消息，效果上是把消息的使用方式Wrap成了服務調用（服務調用使用方式成簡單，基於業務接口）。