應用場景：

對分散式訊息系統機制的分析好文：

　我們再來看微博的方案，所以我們自己實現了一個多機房同步的方案。就是我們前端應用將資料寫到資料庫，再通過一個訊息代理，相當於通過我們自己開發的一個技術，將資料廣播到多個機房。這個不但可以做到兩個機房，而且可以做到三個、四個。具體的方式就是通過訊息廣播方式將資料多點分佈，就是說我們的資料提交給一個代理，這個代理幫我們把這些資料同步到多個機房，那我們應用不需要關心這個資料是怎麼樣同步過去的。

　　用這種訊息代理方式有什麼好處呢？可以看一下Yahoo是怎麼來做的？第一個是資料提供之後沒有寫到db之後是不會消失的，我只要把資料提交成功就可以了，不需要關心資料怎麼到達機房。第二個特點YMB是一款訊息代理的產品，但是它唯一神奇的地方是為廣域網設計的，它可以把多機房應用歸到內部，我們應用不需要關注這個問題。這個原理跟我們目前自己開發的技術相似。

我們看一下推送架構怎麼從架構底層做到實時性的。從左上角的一條微博在我們系統釋出之後，我們把它放在一個訊息佇列裡面，然後會有一個訊息佇列的處理程式把它拿過來，處理以後放到db裡面。假如說我們不做持久化，因為我們推送資料也不能丟失，我們就要寫一個很複雜的程式，將資料非同步去存，這樣就會非常複雜，而且系統也會有不穩定的因素。從另外一個角度來說，我們做持久化也是做過測試的。我們推送整個流程可以做到100毫秒和200毫秒之間，就是說我們在這個時間能把資料推送出去。

對於一些商業網站，其需要在上海、北京、美國等多點部署，採用訊息匯流排可以解決資料一致性問題，當發生寫操作時，資料除了被儲存到本地，同時放到訊息佇列中，這樣可同步到其他資料中心。

Kafka

Kafka Architecture Design：http://kafka.apache.org/documentation.html#design

 譯文：http://www.oschina.net/translate/kafka-design

http://www.infoq.com/cn/articles/apache-kafka?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

Apache Kafka：下一代分散式訊息系統

支援多資料中心，但採用映象技術，實時性等各方面會有問題，本質還是各中心獨立

Hedwig

RabbitMQ

ActiveMQ

使用到訊息匯流排的場景：