先說RPC

RPC通常指的是PRC框架（分佈式框架），或者PRC協議，如GRPC,JSON-RPC等。這類框架主要解決遠程通信間的問題，所以底層的通信機制是不需要使用者去關心去實現就能很好實現遠程通信的，最出名的莫過於阿里的dubbo。

再說任務隊列

這是個邏輯概念，即比如飯店高峰期時，顧客單子不得不按照下單順序一個個放在廚房，進行先後炒菜處理，這一堆的單子就是任務隊列。

最後說消息隊列

消息隊列（MQ）可以理解成兩個應用程序間（生產者消費者間）的通信，例如短信發送模塊，因為模塊的發送速度跟不上，這時候需要有一個容器，暫存一下，緩解下壓力，那麼“消息隊列”就是在消息的傳輸過程中保存消息的“容器”。然後短信模塊就可以從容不怕的去消息隊列取出要發出的短信內容，進行發送處理。

java進階架構師

說實話，第一次看到這個問題，真心有點兒暈。在工作中，任務隊列，消息隊列和rpc都是常用的實踐方案，但是這三者解決的問題似乎沒有什麼相關性。如：任務隊列往往是需要大規模處理業務邏輯時，將相關的任務入隊列，進行異步調用，從而解決任務阻塞的問題；消息隊列是異構系統（或者說系統）之間異步通信的一種方法，主要是用來解決系統間信息同步問題的；而rpc是一種遠程調用方式，是在代碼的實現層面異步調用外部服務用的。就這種描述來看，三者之間的確沒有什麼瓜葛。

但是出於好奇，我在網上搜索了這個問題，發現知乎有相同的問題，並且有大神【靈劍】給出了比較專業的答案，我將其答案描述如下。

任務隊列、消息隊列、rpc是不同層次上的東西，任務隊列是邏輯模型，消息隊列是通信模型，RPC是包含了通信模型的編程模型（或者框架）。

消息隊列（MQ）是一種能實現生產者到消費者單向通信的通信模型，一般來說是指實現這個模型的中間件，比如RabbitMQ。它可以是一個產品，或者是操作系統提供的一種服務之類。

RPC一般來說是具體指某一種RPC編程框架或協議，如JSON-RPC、GRPC等，它自己有一整套通信的規範，而在此之上實現什麼功能是可以定製的。對於RPC來說，調用方不太關心底層的通信機制，只關心它能實現遠程調用這一點；框架則不太關心上面承載的究竟是怎樣的應用，只負責將調用過程發送到執行端，並將結果回傳。