偽裝-嘴角輕蔑的傷
我曾經使用過RabbitMQ和正在使用kafka，姑且說下！
RabbitMQ和kafka都是分佈式消息中間件系統！作為生產者和消費者的解耦合組件，保證服務之間的通信行為！
但是RabbitMQ主要的側重點為broker，希望提供生產者和消費者之間消息傳遞的良好保證和消息數據的持久化！而kafka核心點是為生產者的大量數據提供支持，支持在線消費者和可能掛掉的消費者，在儘量低延遲的情況下發送消息！
都能對消息數據進行持久化，都實現了producer和comsumer之間的解耦，都擁有超高的吞吐量和穩定性！
所以，可以把rabbitMQ和kafka看做一個層級的東西！
而zeroMQ是一個十分輕量級的消息系統，在高吞吐量和低延遲方面性能更優，但是zeroMQ並不實現生產者和消費者之間的解耦合，而且zeroMQ的使用也十分困難，並不具備組件化，服務化的標準，需要自己實現socket等，同時，zeroMQ並不支持持久化消息數據，雖然性能高，但是消息丟失帶來的影響也是不可估量的！
所以zeroMQ並不是嚴格的消息中間件系統！不過性能，吞吐量，實時性卻是最高的！
關於kafka，rabbitmq的使用有需要的童鞋可以進一步交流，更多的技術分享，敬請關注。。。
謝逅架構
RabbitMQ、ZeroMQ和Kafka是一個層級的東西麼？這個還真心不清楚，對於RabbitMQ和Kafka在項目開發中或多或少使用過，而ZeroMQ之前都沒有聽說過，更何談了解使用呢？接下來我就簡單說說我對RabbitMQ和Kafka的認識，以及相關的使用場景。
先來說說RabbitMQ，這個使用的業務場景比較廣泛，所有傳統意義上的消息隊列解耦的情況幾乎都可以用RabbitMQ來解決。記得之前做用戶登錄的活躍人次統計時，由於初期的設計不支持這種報表查詢，而且報表的定製特性不適合通過基礎框架來做開發，隨後的方案就是通過解析登錄日誌文件來生成用戶的登錄記錄，然後通過RabbitMQ將解析完成的記錄發給做報表的團隊，完成任務間的協同開發。定時任務解析、RabbitMQ解耦，較為從容的完成了月登錄人次的統計，是應用解耦使用的典型場景。經過實踐，RabbitMQ在三個比較典型的場景中使用較多，即異步處理、應用解耦、流量削峰。
再來說說Kafka，Kafka設計的初衷就是處理日誌的，可以看做是一個日誌系統，針對性很強。其典型的應用場景是用戶訪問日誌的存儲和使用，結合storm流組件進行訪問日誌、點擊流日誌的實時流量，以及其他類似的業務場景。典型的使用場景有：日誌收集、消息系統、用戶活動跟蹤、運營指標、流式處理等。kafka的特性如下：
- 高吞吐量、低延遲：kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒，每個topic可以分多個partition, consumer group 對partition進行consume操作。
- 可擴展性：kafka集群支持熱擴展
- 持久性、可靠性：消息被持久化到本地磁盤，並且支持數據備份防止數據丟失
- 容錯性：允許集群中節點失敗（若副本數量為n,則允許n-1個節點失敗）
- 高併發：支持數千個客戶端同時讀寫
綜合考慮，RabbitMq比kafka的對比如下：RabbitMq比Kafka成熟，在可用性上，穩定性上，可靠性上，RabbitMq超過Kafka；Kafka設計的初衷就是處理日誌的，可以看做是一個日誌系統，針對性很強，所以它並沒有具備一個成熟MQ應該具備的特性；Kafka的性能（吞吐量、tps）比RabbitMq要強，兩者在這方面沒有可比性。
