詳解RPC遠端呼叫和訊息佇列MQ的區別

爛豬皮發表於2019-01-08

PC(Remote Procedure Call)遠端過程呼叫,主要解決遠端通訊間的問題,不需要了解底層網路的通訊機制。

RPC框架

知名度較高的有Thrift(FB的)、dubbo(阿里的)。

詳解RPC遠端呼叫和訊息佇列MQ的區別


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,可以把訊息儲存。

詳解RPC遠端呼叫和訊息佇列MQ的區別


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四個不同大小的資料。

詳解RPC遠端呼叫和訊息佇列MQ的區別

實驗表明:入隊時,當資料比較小時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.如果下游有很多系統關心你的系統發出的通知的時候,果斷地使用訊息佇列吧。

如果想免費學習Java工程化、高效能及分散式、深入淺出。微服務、Spring,MyBatis,Netty原始碼分析的朋友可以加我的Java進階群:478030634,群裡有阿里大牛直播講解技術,以及Java大型網際網路技術的視訊免費分享給大家。

詳解RPC遠端呼叫和訊息佇列MQ的區別



相關文章