前一篇文章《rabbitmq和kafka到底怎麼選？》，我們在吞吐量方面比較了kafka和rabbitmq，知道了kafka的吞吐量要高於rabbitmq。本文從可靠性方面繼續**兩個佇列的差異。
我們通過前文知道，rabbitmq的佇列分為master queue和mirror queue，mirror queue 在master queue宕機之後，會被提公升為master queue，如下圖所示。
佇列a的consumer在消費的時候，機器宕機，此時客戶端和服務端分別做如下動作：
當master queue 所在節點宕機後，其正在被消費的訊息的相關資訊全部丟失，即服務端不知道消費者對那一瞬間消費的訊息是否進行了ack，所以在mirror queue被提公升為master queue時，會把宕機前正在進行消費的的訊息全部重新傳送一遍，即客戶端重連後，訊息可能被重複消費，這個時候就必須依靠應用層邏輯來判斷來避免重複消費。
在持久化方面，rabbitmq的master queue每次收到新訊息後，都會立刻寫入磁碟，並把訊息同步給mirror queue。假設在master queue 收到訊息後，訊息未同步到mirror queue 之前master queue 宕機，則此時mirror queue中就沒有剛剛master queue收到的那條訊息，當這個mirror queue被提公升為master queue時，消費者連線到新的master queue上進行消費時就丟了一條訊息。所以，rabbitmq也會丟訊息，只不過這個丟訊息的概率非常低。
我們知道kafka中的每個佇列叫做topic，乙個topic有多個主分片和副分片，當主分片所在機器宕機後，服務端會把乙個副分片提公升為主分片，如下圖所示。
服務端和客戶端會有如下動作：
kafka同樣有主從同步，所以也必定存在與rabbitmq同樣丟訊息的問題。但是kafka的每個客戶端儲存了讀取訊息的偏移資訊，故當乙個主分片宕機後，kafka客戶端可以從副分片相應位移後繼續消費，不會有重複消費的情況。
持久化方面，kafka預設把訊息直接寫檔案，但是由於作業系統的cache原因，訊息可能不會立馬寫到磁碟上，這個時候就需要重新整理檔案到磁碟。由於重新整理檔案到磁碟是乙個比較耗時的操作，故kafka提供了兩種不同的重新整理配置：
我們完全可以把log.flush.interval.messages設定為1，這樣kafka就能在持久化方面達到和rabbitmq同樣的安全級別。
但是kafka集群依賴zk，如上圖所示，所以對於kafka穩定性的評估必須考慮zk集群的穩定性，而一般我們認為任何分布式集群的穩定性都小於1，故兩個集群的串聯穩定性會下降一些，維護更複雜一些，這點沒有rabbitmq有優勢。
其實好多開源元件隨著時間推移，往往都進行了各種改進。就比如kafka雖然是為了日誌而生，給人第一印象是容易丟訊息，但是經過這麼多年的改進，其可靠性可能並不遜色rabbitmq了，只需要你根據不同的業務場景配置不同的配置引數，即可達到適合自己的安全級別。
好了，以上就是我的個人分析，多有不足，希望能和小夥伴進行**。
訊息佇列 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...