PC（Remote Procedure Call）遠程過程調用，主要解決遠程通信間的問題，不需要了解底層網絡的通信機制。
RPC框架
知名度較高的有Thrift(FB的)、dubbo(阿里的)。
RPC的一般需要經歷4個步驟：
1、建立通信
首先要解決通訊的問題：即A機器想要調用B機器，首先得建立起通信連接，主要是通過在客戶端和服務器之間建立TCP連接。
2、服務尋址
要解決尋址的問題，A服務器上如何連接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱是什么。
3、網絡傳輸
1）序列化
當A服務器上的應用發起一個RPC調用時，調用方法和參數數據都需要先進行序列化。
2）反序列化
當B服務器接收到A服務器的請求之后，又需要對接收到的參數等信息進行反序列化操作。
4、服務調用
B服務器進行本地調用（通過代理Proxy）之后得到了返回值，此時還需要再把返回值發送回A服務器，同樣也需要經過序列化操作，然后再經過網絡傳輸將二進制數據發送回A服務器。
通常，一次完整的PRC調用需要經歷如上4個步驟。
MQ(消息隊列)
消息隊列（MQ）是一種能實現生產者到消費者單向通信的通信模型，一般來說是指實現這個模型的中間件。
典型的MQ中間件:
RabbitMQ、ActiveMQ、Kafka等
典型的特點：
1、解耦
2、可靠投遞
3、廣播
4、最終一致性
5、流量削峰
6、消息投遞保證
7、異步通信（支持同步）
8、提高系統吞吐、健壯性
典型的使用場景：秒殺業務中利用MQ來實現流量削峰，以及應用解耦使用。
RPC和MQ的區別和關聯
1.在架構上，RPC和MQ的差異點是，Message有一個中間結點Message Queue，可以把消息存儲。
2.同步調用：對於要立即等待返回處理結果的場景，RPC是首選。
3.MQ 的使用，一方面是基於性能的考慮，比如服務端不能快速的響應客戶端（或客戶端也不要求實時響應），需要在隊列里緩存。
另外一方面，它更側重數據的傳輸，因此方式更加多樣化，除了點對點外，還有訂閱發布等功能。
4.而且隨着業務增長，有的處理端處理量會成為瓶頸，會進行同步調用改造為異步調用，這個時候可以考慮使用MQ。
那么，這些詳細的MQ消息隊列的選型我們該如何選擇比較呢？
主流的消息隊列MQ比較，詳解MQ的4類應用場景
消息隊列已經逐漸成為企業IT系統內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步RPC的主要手段之一。
當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發的Notify、MetaQ、RocketMQ等。
現在主要探討主流的消息隊列MQ比較，特征，以及典型使用場景。
目前主流的MQ產品
1.ZeroMQ
號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。
擴展性好，開發比較靈活，采用C語言實現，實際上只是一個socket庫的重新封裝，如果做為消息隊列使用，需要開發大量的代碼。ZeroMQ僅提供非持久性的隊列，也就是說如果down機，數據將會丟失。其中，Twitter的Storm中使用ZeroMQ作為數據流的傳輸。
2.RabbitMQ
結合erlang語言本身的並發優勢，支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。
性能較好，但是不利於做二次開發和維護。
3.ActiveMQ
歷史悠久的開源項目，是Apache下的一個子項目。已經在很多產品中得到應用，實現了JMS1.1規范，可以和spring-jms輕松融合，實現了多種協議，不夠輕巧（源代碼比RocketMQ多），支持持久化到數據庫，對隊列數較多的情況支持不好。
4.Redis
做為一個基於內存的K-V數據庫，其提供了消息訂閱的服務，可以當作MQ來使用，目前應用案例較少，且不方便擴展。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。
測試數據分為 128Bytes、512Bytes、1K和10K四個不同大小的數據。
實驗表明：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如 果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於 Redis。
5.Kafka/Jafka
Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發布/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。
具有以下特性：
-
快速持久化，可以在O(1)的系統開銷下進行消息持久化；
-
高吞吐，在一台普通的服務器上既可以達到10W/s的吞吐速率；完全的分布式系統，Broker、Producer、Consumer都原生自動支持分布式，自動實現負載均衡；
-
支持Hadoop數據並行加載，對於像Hadoop的一樣的日志數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。
-
Kafka通過Hadoop的並行加載機制統一了在線和離線的消息處理。Apache Kafka相對於ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分布式系統。
時需要消息隊列
當你需要使用消息隊列時，首先需要考慮它的必要性。
可以使用mq的場景有很多，最常用的幾種:
-
做業務解耦
-
最終一致性
-
廣播
-
錯峰流控等
反之，如果需要強一致性，關注業務邏輯的處理結果，則RPC顯得更為合適。
消息隊列使用場景
1.解耦
解耦是消息隊列要解決的最本質問題。所謂解耦，簡單點講就是一個事務，只關心核心的流程。而需要依賴其他系統但不那么重要的事情，有通知即可，無需等待結果。換句話說，基於消息的模型，關心的是“通知”，而非“處理”。
舉一個例子，關於訂單系統，訂單最終支付成功之后可能需要給用戶發送短信積分什么的，但其實這已經不是我們系統的核心流程了。
如果外部系統速度偏慢（比如短信網關速度不好），那么主流程的時間會加長很多，用戶肯定不希望點擊支付過好幾分鍾才看到結果。那么我們只需要通知短信系統“我們支付成功了”，不一定非要等待它立即處理完成。
2.最終一致性
最終一致性指的是兩個系統的狀態保持一致，要么都成功，要么都失敗。
當然有個時間限制，理論上越快越好，但實際上在各種異常的情況下，可能會有一定延遲達到最終一致狀態，但最后兩個系統的狀態是一樣的。
業界有一些為“最終一致性”而生的消息隊列，如：
-
Notify（阿里）
-
QMQ（去哪兒）等
其設計初衷，就是為了交易系統中的高可靠通知。
以一個銀行的轉賬過程來理解最終一致性，轉賬的需求很簡單，如果A系統扣錢成功，則B系統加錢一定成功。反之則一起回滾，像什么都沒發生一樣。
然而，這個過程中存在很多可能的意外：
-
A扣錢成功，調用B加錢接口失敗。
-
A扣錢成功，調用B加錢接口雖然成功，但獲取最終結果時網絡異常引起超時。
-
A扣錢成功，B加錢失敗，A想回滾扣的錢，但A機器down機。
可見，想把這件看似簡單的事真正做成，真的不那么容易。
所有跨VM的一致性問題，從技術的角度講通用的解決方案是：
-
強一致性，分布式事務，但落地太難且成本太高，后文會具體提到。
-
最終一致性，主要是用“記錄”和“補償”的方式。在做所有的不確定的事情之前，先把事情記錄下來，然后去做不確定的事情，結果可能是：成功、失敗或是不確定，“不確定”（例如超時等）可以等價為失敗。成功就可以把記錄的東西清理掉了，對於失敗和不確定，可以依靠定時任務等方式把所有失敗的事情重新搞一遍，直到成功為止。
-
回到剛才的例子，系統在A扣錢成功的情況下，把要給B“通知”這件事記錄在庫里（為了保證最高的可靠性可以把通知B系統加錢和扣錢成功這兩件事維護在一個本地事務里），通知成功則刪除這條記錄，通知失敗或不確定則依靠定時任務補償性地通知我們，直到我們把狀態更新成正確的為止。
-
整個這個模型依然可以基於RPC來做，但可以抽象成一個統一的模型，基於消息隊列來做一個“企業總線”。
-
具體來說，本地事務維護業務變化和通知消息，一起落地（失敗則一起回滾），然后RPC到達broker，在broker成功落地后，RPC返回成功，本地消息可以刪除。否則本地消息一直靠定時任務輪詢不斷重發，這樣就保證了消息可靠落地broker。
-
broker往consumer發送消息的過程類似，一直發送消息，直到consumer發送消費成功確認。
-
我們先不理會重復消息的問題，通過兩次消息落地加補償，下游是一定可以收到消息的。然后依賴狀態機版本號等方式做判重，更新自己的業務，就實現了最終一致性。
最終一致性不是消息隊列的必備特性，但確實可以依靠消息隊列來做最終一致性的事情。
另外，所有不保證100%不丟消息的消息隊列，理論上無法實現最終一致性。好吧，應該說理論上的100%，排除系統嚴重故障和bug。
像Kafka一類的設計，在設計層面上就有丟消息的可能（比如定時刷盤，如果掉電就會丟消息）。哪怕只丟千分之一的消息，業務也必須用其他的手段來保證結果正確。
2.廣播
消息隊列的基本功能之一是進行廣播。
如果沒有消息隊列，每當一個新的業務方接入，我們都要聯調一次新接口。有了消息隊列，我們只需要關心消息是否送達了隊列，至於誰希望訂閱，是下游的事情，無疑極大地減少了開發和聯調的工作量。
比如本文開始提到的產品中心發布產品變更的消息，以及景點庫很多去重更新的消息，可能“關心”方有很多個，但產品中心和景點庫只需要發布變更消息即可，誰關心誰接入。
3.錯峰與流控
試想上下游對於事情的處理能力是不同的。
比如，Web前端每秒承受上千萬的請求，並不是什么神奇的事情，只需要加多一點機器，再搭建一些LVS負載均衡設備和Nginx等即可。
但數據庫的處理能力卻十分有限，即使使用SSD加分庫分表，單機的處理能力仍然在萬級。由於成本的考慮，我們不能奢求數據庫的機器數量追上前端。
這種問題同樣存在於系統和系統之間，如短信系統可能由於短板效應，速度卡在網關上（每秒幾百次請求），跟前端的並發量不是一個數量級。
但用戶晚上個半分鍾左右收到短信，一般是不會有太大問題的。如果沒有消息隊列，兩個系統之間通過協商、滑動窗口等復雜的方案也不是說不能實現。
但系統復雜性指數級增長，勢必在上游或者下游做存儲，並且要處理定時、擁塞等一系列問題。而且每當有處理能力有差距的時候，都需要單獨開發一套邏輯來維護這套邏輯。所以，利用中間系統轉儲兩個系統的通信內容，並在下游系統有能力處理這些消息的時候，再處理這些消息，是一套相對較通用的方式。
消息隊列使用總結
1.消息隊列不是萬能的，對於需要強事務保證而且延遲敏感的，RPC是優於消息隊列的。
2.對於一些無關痛癢，或者對於別人非常重要但是對於自己不是那么關心的事情，可以利用消息隊列去做。
3.支持最終一致性的消息隊列，能夠用來處理延遲不那么敏感的“分布式事務”場景，而且相對於笨重的分布式事務，可能是更優的處理方式。
4.當上下游系統處理能力存在差距的時候，利用消息隊列做一個通用的“漏斗”，在下游有能力處理的時候，再進行分發。
5.如果下游有很多系統關心你的系統發出的通知的時候，果斷地使用消息隊列吧。