應用場景：
l分布式元件／系統互相通信 l資料複制、同步 ldelay queue l廣播通知
案例分析：基于消息的分布式架構
對分布式消息系統機制的分析好文：
http://www.infoq.com/cn/articles/message-based-distributed-architecture
http://tech.sina.com.cn/i/2010-11-16/14434871585.shtml：
我們再來看微網誌的方案，是以我們自己實作了一個多機房同步的方案。就是我們前端應用将資料寫到資料庫，再通過一個消息代理，相當于通過我們自己開發的一個技術，将資料廣播到多個機房。這個不但可以做到兩個機房，而且可以做到三個、四個。具體的方式就是通過消息廣播方式将資料多點分布，就是說我們的資料送出給一個代理，這個代理幫我們把這些資料同步到多個機房，那我們應用不需要關心這個資料是怎麼樣同步過去的。
用這種消息代理方式有什麼好處呢？可以看一下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：下一代分布式消息系統
| Kafka是一個消息系統，原本開發自LinkedIn，用作LinkedIn的活動流（activity stream）和營運資料處理管道（pipeline）的基礎。現在它已為多家不同類型的公司 作為多種類型的資料管道（data pipeline）和消息系統使用。 活動流資料是所有站點在對其網站使用情況做報表時要用到的資料中最正常的部分。活動資料包括頁面通路量（page view）、被檢視内容方面的資訊以及搜尋情況等内容。這種資料通常的處理方式是先把各種活動以日志的形式寫入某種檔案，然後周期性地對這些檔案進行統計分析。營運資料指的是伺服器的性能資料（CPU、IO使用率、請求時間、服務日志等等資料)。營運資料的統計方法種類繁多。 近年來，活動和營運資料處理已經成為了網站軟體産品特性中一個至關重要的組成部分，這就需要一套稍微更加複雜的基礎設施對其提供支援。 |
活動流和營運資料的若幹用例
|
支援多資料中心，但采用鏡像技術，實時性等各方面會有問題，本質還是各中心獨立
Hedwig
https://cwiki.apache.org/ZOOKEEPER/hedwig.html
http://zookeeper.apache.org/bookkeeper/docs/r4.0.0/hedwigUser.html
RabbitMQ
http://www.imneio.com/2009/10/zeromq_in_dotnet/（負面消息）
ActiveMQ
使用到消息總線的場景：
l分布式事務 l資料複制 l日志同步 ldelay queue l廣播通知