1. 程式人生 > >分布式系統的那些事兒(三) - MQ時代的通信

分布式系統的那些事兒(三) - MQ時代的通信

任務 會有 服務端 分布 ive 結果 團隊 並不會 短信

之前在講RPC通信的各種好處,特別好用,但是RPC並不是萬能的,也並不是適用於各種場景的,因為他是同步的;現如今很多場景下的調用都是異步的,系統A調用B後,並不需要知道B的結果,而且對B的結果無所謂,甚至你B掛了都無所謂,那麽這個時候使用消息隊列是十分OK的。

最簡單的場景就是發送短信和email,主機不需要知道是否發送成功與否,就算失敗了,哪怕再發一次也無所謂。

常見的MQ主要有JMS,RabbitMQ,ActiveMQ,Kafka以及RocketMQ,值得一提的是RocketMQ是阿裏出的開源消息隊列,很好用噢。

簡單來說MQ可以支持點對點,點對多,訂閱模式的各種消息,非常使用。舉個非常我們自己使用過的例子,我們每周一三五的淩晨會有運維人員手動來執行一些數據操作,每個操作的實際大約20分鐘,任務有先後順序,執行完後需要查看上一個操作是否完畢再進行下一個操作,這樣導致運維人員會很累,所以後來采用MQ來做這些任務,定時任務開始運行後,那麽每個任務完成後只要調用對應的MQ就能達到人工的效果。一舉兩得。

關於消息隊列的一些文章在之前都有寫過,具體可以參考以下鏈接:

RabbitMQ 一二事 - 簡單隊列使用

RabbitMQ 一二事(2) - 工作隊列使用

RabbitMQ 一二事(3) - 訂閱模式(微信公眾號模式)的應用

RabbitMQ 一二事(4) - 路由模式介紹

RabbitMQ 一二事(5) - 通配符模式應用

RabbitMQ 整合Spring 實現多客戶端發送消息隊列

分布式系統的數據一致性(在這裏先不講事務的一致性,後面會講)

當數據被分在多地存儲的時候,那麽數據被讀取的時候的一致性對用戶是需要做保障的。這裏分為強一致性和弱一致性

強一致性:保證用戶不論何時何地,在華北還是華南,中國還是美國,同一時間訪問到的數據是一致的,並不會出現差異性,這樣的做法其實不多,消耗代價十分絕大,對運維團隊的考驗也十分嚴格。

弱一致性:保證用戶訪問數據的速度是OK的,但是數據內容可能隨著時間的不同地點的不同會有差異。比如我在公司VPN環境下訪問到的一些電商數據基本是實時的,更新速度很快。而我在下班以後在家訪問卻發現白天發布的數據並沒有更新,需要在淩晨訪問的時候數據才會更新過來,這樣的做法就是數據的持續更新,服務端不會在乎客戶訪問的內容如何,雖然有時間地點的偏差,但是保證你能夠訪問到即可。

分布式系統的那些事兒(三) - MQ時代的通信