用topic來進行消息管理，每個topic包含多個part，每個part對應(yīng)一個邏輯log，有多個segment組成。

segment中的消息id由其邏輯位置決定，可以用消息id直接定位到消息的存儲位置，避免id到位置的額外映射。

生產(chǎn)者發(fā)到某個topic的消息會被均勻的分布到多個part上，broker收到消息會寫入最后的segment文件中，當(dāng)某個segment上的消息條數(shù)達到配置值或消息發(fā)布時間超過閾值時，segment上的消息會被flush到磁盤，只有flush到磁盤上的消息消費者才能收到。并且通過rolling的機制，保證segment的文件不至于過大。

消費者可以rewind back到任意位置重新進行消費，當(dāng)消費者故障時，可以選擇最小的offset進行重新讀取消費消息。

Kafka對消息的重復(fù)、丟失、錯誤以及順序型沒有嚴格的要求。但是part只會被consumer group內(nèi)的一個consumer消費，故kafka保證每個parti內(nèi)的消息會被順序的消費。

broker沒有副本機制，一旦broker宕機，該broker的消息將都不可用。同時broker是無狀態(tài)的，broker不保存消費者的狀態(tài)，由消費者自己保存。無狀態(tài)導(dǎo)也致消息的刪除成為難題，所以Kafka選擇消息保存一定時間后會被刪除。

大量的依賴Zookeeper，需要Zookeeper來管理broker與consumer的動態(tài)加入與離開。以及消費關(guān)系及每個partion的消費信息。

我們真的每個消息都能到1K嗎？

我們真的需要雙方都對消息ACK的系統(tǒng)嗎？

RabbitMQ做為一個Broker，不單單做到了簡單的數(shù)據(jù)轉(zhuǎn)發(fā)功能，還保證了單個隊列上的數(shù)據(jù)有序，即便是有多個消費者和多個生產(chǎn)者。

RabbitMQ的策略是實時轉(zhuǎn)發(fā)，而不像Kafka那樣等待刷盤之后才讓消費者來消費。

如果消費者和生產(chǎn)者不對等，會產(chǎn)生大量的磁盤IO操作，進行消息換出。

AMQP協(xié)議本身比較復(fù)雜，參數(shù)比較多。

Erlang寫的，很多人不熟悉，并且Mnesia出現(xiàn)問題好多人解決不了。

Kafka大量依賴Zookeeper，它的broker并不保存任何狀態(tài)，如果Zookeeper集群不幸悲劇了，那么整個Kafka集群的消息就全完蛋了。

上面問題有人會說這概率好小，我也同樣認為這個概率很小，那么一個broker當(dāng)機呢？當(dāng)一個broker當(dāng)機了整個消息隊列由于負載均衡的算法，在一瞬間消費者和生產(chǎn)者之間的消息就全亂掉了。很多需要保證消息順序的系統(tǒng)一下子就完蛋了。

RabbitMQ的消息應(yīng)當(dāng)盡可能的小，并且只用來處理實時且要高可靠性的消息。

消費者和生產(chǎn)者的能力盡量對等，否則消息堆積會嚴重影響RabbitMQ的性能。

集群部署，使用熱備，保證消息的可靠性。

應(yīng)當(dāng)有一個非常好的運維監(jiān)控系統(tǒng)，不單單要監(jiān)控Kafka本身，還要監(jiān)控Zookeeper。

對消息順序不依賴，且不是那么實時的系統(tǒng)。

對消息丟失并不那么敏感的系統(tǒng)。