分散式系統的那些事兒（四） - MQ時代的通信

來自專欄 BeJavaGod

之前在講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環境下訪問到的一些電商數據基本是實時的，更新速度很快。而我在下班以後在家訪問卻發現白天發布的數據並沒有更新，需要在凌晨訪問的時候數據才會更新過來，這樣的做法就是數據的持續更新，服務端不會在乎客戶訪問的內容如何，雖然有時間地點的偏差，但是保證你能夠訪問到即可。

推薦閱讀：