本文不對三者之間的性能進行對比，只是從三者的特性上區分他們，並指出三者的不用應用場景。
1、publish/subscribe
發布訂閱模式如下圖所示可以具有多個生產者和發布者，redis、kafka、rebittMQ都滿足這樣的要求。
但是三者有各自的特色。
1.1 redis
redis的特征就是快，由於其數據是存儲在內存中的，處理速度相對另外兩者快了不少。通過使用redis可以實現一個簡單具有實時通信功能的聊天室。
2.2 kafka
kafka的設計初衷是一個日志系統，其隊列中的數據能夠持久化一段時間。因此后來的consumer能夠通過自定義offset來實現獲取之前的消息，而redis就不具備這樣的能力。
2.3 rabittMQ
rabittMQ設計的一個核心概念為Exchange，Exchange存在的意義是producer不會直接向queue發送消息，而是將消息先發給exchanger，而exchanger選擇將數據轉發給queue。rabittMQ的exchanger有4種轉發策略，包括direct、topic、headers、fanout。因此rabittMQ在消息的路由方面相比redis和kafka更加靈活。
2、work queue
work queue模式相比發布訂閱者模式更側重負載均衡，我們可以把一個隊列當做一個任務，而消費該隊列的worker需要共同處理隊列里的任務，同一條消息只能被處理一次。如下圖所示是work queue的示意圖：
2.1redis
redis可以使用list數據結構來實現這一任務，因為redis的單個操作是原子的，保障了一條消息只能被處理一次，但是缺點是consumer需要自己實現，還有一些負載均衡地策略也要自己去實現。
2.2rabittMQ
rabittMQ內部實現了這一功能，使用輪訓的方式給worker發消息保證了負載均衡。缺點是可拓展性不好，當consumer相當多的時候，所有的consumer都要向同一個queue去獲取數據，這樣導致queue的性能稱為了瓶頸。
2.3kafka
kafka通過consumer group的方式實現了work queue，同一個group的消費者能夠協調完成任務。kafka在分布式方面做得很好，在kafka中，一個queue和topic的概念等同，只是topic可以被分成多個partition，而這些partition分別存儲在不同的服務器上，這樣，同一個Consumer group中的consumer在消費數據的時候可以從不同的partition中獲取數據，減少了單台服務器的壓力。
3、更加復雜的情況
如下圖所示復雜的情況，以日志舉例，error日志需要持久化，所有的日志都應該打印出來。那么這里有兩個工作流，一個是持久化，一個是打印。
如果用redis和kafka來實現的話需要在producer上下功夫，將消息區分之后發送到不同的queue上，而rabittMQ則更加靈活，可以通過exchanger來實現消息的轉發。
4、小節
redis的特點就是快
kafka的特點是可拓展性高，可以持久化
rabittMQ的特點是靈活，能夠實現各種消息需求。
5 參考資料
原文鏈接：http://blog.csdn.net/maitianshouwei/article/details/57124155