開源社群有好多優秀的佇列中介軟體，比如rabbitmq和kafka，每個佇列都貌似有其特性，在進行工程選擇時，往往眼花繚亂，不知所措。對於rabbitmq和kafka，到底應該選哪個？
rabbitmq是乙個分布式系統，這裡面有幾個抽象概念。
因為mirror queue要和master queue保持一致，故需要同步機制，正因為一致性的限制，導致所有的讀寫操作都必須都操作在master queue上（想想，為啥讀也要從master queue中讀？和資料庫讀寫分離是不一樣的。），然後由master節點同步操作到mirror queue所在的節點。即使consumer連線到了非master queue節點，該consumer的操作也會被路由到master queue所在的節點上，這樣才能進行消費。
所以，到這裡小夥伴們就可以看到 rabbitmq的不足：由於master queue單節點，導致效能瓶頸，吞吐量受限。雖然為了提高效能，內部使用了erlang這個語言實現，但是終究擺脫不了架構設計上的致命缺陷。
說實話，kafka我覺得就是看到了rabbitmq這個缺陷才設計出的乙個改進版，改進的點就是：把乙個佇列的單一master變成多個master，即一台機器扛不住qps，那麼我就用多台機器扛qps，把乙個佇列的流量均勻分散在多台機器上不就可以了麼？注意，多個master之間的資料沒有交集，即一條訊息要麼傳送到這個master queue，要麼傳送到另外乙個master queue。
這裡面的每個master queue 在kafka中叫做partition，即乙個分片。乙個佇列有多個主分片，每個主分片又有若干副分片做備份，同步機制類似於rabbitmq。
佇列讀取的時候虛擬出乙個group的概念，乙個topic內部的訊息，只會路由到同group內的乙個consumer上，同乙個group中的consumer消費的訊息是不一樣的；group之間共享乙個topic，看起來就是乙個佇列的多個拷貝。所以，為了達到多個group共享乙個topic資料，kafka並不會像rabbitmq那樣訊息消費完畢立馬刪除，而是必須在後台配置儲存日期，即只儲存最近一段時間的訊息，超過這個時間的訊息就會從磁碟刪除，這樣就保證了在乙個時間段內，topic資料對所有group可見（這個特性使得kafka非常適合做乙個公司的資料匯流排）。佇列讀同樣是讀主分片，並且為了優化效能，消費者與主分片有一一的對應關係，如果消費者數目大於分片數，則存在某些消費者得不到訊息。
由此可見，kafka絕對是為了高吞吐量設計的，比如設定分片數為100，那麼就有100臺機器去扛乙個topic的流量，當然比rabbitmq的單機效能好。
本文只做了kafka和rabbitmq的對比，但是開源佇列豈止這兩個，zeromq，rocketmq，jmq等等，時間有限也就沒有細看，故不在本文比較範圍之內。
本文內容參考自rabbitmq和kafka官方文件，所以真要搞懂乙個中介軟體的原理最好去看官方文件，文件裡面有詳細的設計方案，我們可以自己進行設計方案的對比，從而找出符合自己實際情況的中介軟體。
訊息佇列 Kafka和rabbitMQ
0.建立topic bin kafka topics.sh create zookeeper localhost 2181 replication factor1 partitions1 topic test 1.檢視kafka topic列表 bin kafka topic.sh zoopkeep...
訊息佇列 RabbitMQ和Kafka
2種模式 點對點 consumer主動對queue監控，檢查是否收到訊息 優點 解耦 通過中介軟體通訊 冗餘 可做快取 擴充套件性順序保證 非同步通訊 consumer即使down掉，訊息還是儲存在queue，等consumer恢復會自動處理訊息 關於broker裡的exchange不可以直接將訊息...
RabbitMQ和kafka的區別
rabbitmq遵循amqp協議,rabbitmq的broker由exchange,binding,queue組成,其中exchange和binding組成了訊息的路由鍵 客戶端producer通過連線channel和server進行通訊,consumer從queue獲取訊息進行消費 長連線，que...