應用場景：

案例分析：基於消息的分布式架構

對分布式消息系統機制的分析好文：

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：下一代分布式消息系統

支持多數據中心，但采用鏡像技術，實時性等各方面會有問題，本質還是各中心獨立

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