之前在講rpc通訊的各種好處，特別好用，但是rpc並不是萬能的，也並不是適用於各種場景的，因為他是同步的；現如今很多場景下的呼叫都是非同步的，系統a呼叫b後，並不需要知道b的結果，而且對b的結果無所謂，甚至你b掛了都無所謂，那麼這個時候使用訊息佇列是十分ok的。
最簡單的場景就是傳送簡訊和email，主機不需要知道是否傳送成功與否，就算失敗了，哪怕再發一次也無所謂。
常見的mq主要有jms，rabbitmq，activemq，kafka以及rocketmq，值得一提的是rocketmq是阿里出的開源訊息佇列，很好用噢。
簡單來說mq可以支援點對點，點對多，訂閱模式的各種訊息，非常使用。舉個非常我們自己使用過的例子，我們每週一三五的凌晨會有運維人員手動來執行一些資料操作，每個操作的實際大約20分鐘，任務有先後順序，執行完後需要檢視上乙個操作是否完畢再進行下乙個操作，這樣導致運維人員會很累，所以後來採用mq來做這些任務，定時任務開始執行後，那麼每個任務完成後只要呼叫對應的mq就能達到人工的效果。一舉兩得。
rabbitmq 一二事 - 簡單佇列使用
rabbitmq 一二事(2) - 工作佇列使用
rabbitmq 一二事(4) - 路由模式介紹
rabbitmq 一二事(5) - 萬用字元模式應用
rabbitmq 整合spring 實現多客戶端傳送訊息佇列
分布式系統的資料一致性（在這裡先不講事務的一致性，後面會講）
當資料被分在多地儲存的時候，那麼資料被讀取的時候的一致性對使用者是需要做保障的。這裡分為強一致性和弱一致性
強一致性：保證使用者不論何時何地，在華北還是華南，中國還是美國，同一時間訪問到的資料是一致的，並不會出現差異性，這樣的做法其實不多，消耗代價十分絕大，對運維團隊的考驗也十分嚴格。
弱一致性：保證使用者訪問資料的速度是ok的，但是資料內容可能隨著時間的不同地點的不同會有差異。比如我在公司vpn環境下訪問到的一些電商資料基本是實時的，更新速度很快。而我在下班以後在家訪問卻發現白天發布的資料並沒有更新，需要在凌晨訪問的時候資料才會更新過來，這樣的做法就是資料的持續更新，服務端不會在乎客戶訪問的內容如何，雖然有時間地點的偏差，但是保證你能夠訪問到即可。
分布式系統的那些事兒（五） 容錯與故障
我們都經歷過巨石應用，單一應用某個功能誘發的故障導致整個站點掛掉，任何人都無法訪問，只能一一排錯再部署上線，這樣造成的影響就是使用者的流失。而分布式應用就沒有這樣的問題，就算某個節點出現故障，那麼主備切換，替換主節點，整個系統還是照樣執行，完全沒有訪問不了的現象。要使系統達到一定的容錯性，那麼 首先...
分布式系統的那些事兒（七） 微服務架構體系
微服務的出現，標誌了又乙個新的里程碑，似乎你不知道微服務就代表你好像out了一樣。微服務是業務服務化，將soa更好的延續了下去。配合restful也能夠更好的提供api介面。簡單來說就是微服務把各種各樣的小的服務區分開來當做乙個當度的應用跑在伺服器上，並且他的通訊機制也是十分簡單的，使用rest或者...
分布式 分布式系統的設計
在計算機領域，當單機效能達到瓶頸時，一般有兩種方式解決效能問題 而分布式系統的設計說白了就是 如何合理將乙個系統拆分成多個子系統部署到不同機器上。講設計方法前，先介紹分布式系統的特性 1 分布性 空間中隨機分布。這些計算機可以分布在不同的機房，不同的城市，甚至不同的國家。2 對等性 分布式系統中的計...