其實這個問題本身是有些問題的，任務隊列，消息隊列和RPC完全是幾個不相關的概念，或者說它們并不是同一層面的概念，如果非要扯上一些關系的話，那么任務隊列可以通過消息隊列實現，RPC和消息隊列是同步和異步的差別。

任務隊列

我還沒有聽說過一個叫做任務隊列的框架、中間件或其他任務和技術有關的名詞；我能想象到的任務隊列，更多的是一個業務概念，當有很多任務（硬件資源不足以同時處理這些任務），或任務和任務之間有先后順序的時候，可以通過對其進行排序處理，這就是任務隊列。

RPC

RPC：RemoteProcedureCall，中文意思就是遠程過程調用。

遠程是相對于本地來說的，有遠程調用就有本地調用，那么先說說本地調用是什么，這個就簡單了；

比如下圖，我們的代碼在同一個進程中（或者說同一個地址空間）調用另外一個方法，得到我們需要的結果，這就是本地調用：

那么想象一下，如果這里的add方法是一個很復雜的方法，很多系統都想用這個方法，那么我們可以把這個方法單獨拆成一個服務，提供給各個系統進行調用，那么本地就會變成遠程，就會變成這樣：

那么在Server_A中怎么調用Server_B中的add方法呢？

很多人都會想到Server_B封裝一個接口，通過服務把這個方法暴露出去，比如通過HTTP請求，那么Server_A就可以調用Server_B中的add方法了。

通過這種方法實現起來沒有問題，也是一個不錯的解決方法，就是在每次調用的時候，都要發起HTTP請求，代碼里面要寫HttpClient.sendRequest這樣的代碼，那么我們有沒有可能像調用本地一樣，去發起遠程調用呢？讓程序員不知道這是調用的遠程方法呢？這時候就要提到RPC了（并不是說RPC優于HTTP請求，關于這兩個概念我們在下文中討論）。

完整的RPC過程，如圖：

• 服務調用方（Client）調用以本地調用方式調用服務；

• Clientstub負責將方法名、參數組裝成消息體并進行序列化，找到服務地址，將消息發送到服務端；

• Serverstub收到消息后進行反序列化后調用本地的服務；

• 本地服務執行，將結果返回給Serverstub；

• Serverstub將運行結果打包成消息序列化后，發送調用方；

• Clientstub接收到消息，并進行反序列化，調用方最終得到調用結果。

總結來說，RPC用于服務之間的調用問題，特別是分布式環境；RPC讓遠程調用時，像調用本地方法一樣方便和無感知；RPC框架屏蔽了很多底層的細節，不需要開發人員關注這些細節，比如序列化和反序列化、網絡傳輸協議的細節。

消息隊列

在正式講解之前，讓我們看一個簡單的場景：

用戶支付成功后，發送一條提示短信；假設支付的時候會調用支付系統的接口，所需時間Xms，發送短信會調用短信平臺的接口，所需時間Yms，那么支付動作一共需要(X+Y)ms，如果Y值比較大的時候，會造成整個支付過程很慢，那么我們有沒有更好的解決方案呢？

下面，讓我們帶著這個問題來了解一下什么是消息隊列，以及消息隊列的使用場景。

我們可以把消息隊列看做是一個存放消息的容器，我們可以往這個容器中放入消息，也可以從這個容器中取出消息；放入消息的叫做生產者，取走消息的叫做消費者；

• 點對點：如果生產者放入一條消息，只能被一個消費者取走一次，這叫做點對點模式；(pointtopoint，queue)；

• 發布/訂閱：如果生產者放入一條消息，可以被多個消費者取走，這叫做發布/訂閱模式；(publish/subscribe，topic)；

我覺得使用消息隊列主要有兩點好處：

1.異步解耦

如果A系統直接調用B系統的接口，那么當B系統出現故障的時候，A系統也會受到影響；如果A和B之間不直接進行調用，那么耦合度就會變得很低。

2.流量削鋒

還是A系統調用B系統的接口，還有另外一種場景，A發起的調用量在某個時間段突然增多，很可能導致B系統崩潰宕機；這時，A系統可以將請求發送到消息隊列中，B系統按照自己的處理能力，從消息隊列中訂閱消息進行處理，達到了流量削鋒的效果。

我們再回到上面的問題，是不是使用消息隊列就可以很好的解決這個問題了；給客戶發送短信這個業務場景，時效性要求并不高，所以完全可以在支付過程中，把通知短信發到消息隊列中，再由短信平臺消費信息發送短信。

總之，任務隊列，消息隊列和RPC三者的關系就在于：任務隊列可以通過消息隊列實現，RPC和消息隊列是同步和異步的差別。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。