Kafka是一個高效能的分散式釋出訂閱訊息系統，其實activeMq，RabbitMq，kafka都比較類似。

其解決的問題：解耦、非同步、削峰，以及對應的場景
小知識：mysql每秒處理2000個請求已經差不多了
activeMq，rabbitMq，rocketMq，kafka優缺點比較，從單機吞吐量、時效性、可用性、訊息可靠性四個方面分析：

吞吐量：activeMq和rabbitMq是每秒萬級，後兩者是十萬級
時效性：除了rabbitMq是微秒級的，其他的三個都是毫秒級的
可用性：都是高可用性，前兩者是主從架構，後兩者是分散式架構，其中kafka的資料多個副本存在不同的broker上，少量機器宕機不影響使用
訊息可靠性

kafka與傳統mq之間的區別？
1、持久化的日誌，無限保留。
2、分散式系統
3、支援實時的流式處理

釋出訂閱訊息系統都需要面臨三個問題，資料丟失、重複消費、順序消費：

如何減少資料丟失？
Kafka0.8版本以前是沒有副本機制的，相當於映象叢集模式，每一個節點都擁有了所有的資料，每一個節點宕機，其他的節點可以保證正常的使用。
但是0.8版本及之後，有了副本機制，kafka由多個broker組成，一個broker認為是一個節點，一個topic，由多個（partition）分割槽組成，資料分佈在多個分割槽上，為了高可用性，每個分割槽都存在多個副本，不同的副本存在於不同的broker上，副本之間存在leader和follower，生產者是會和leader進行互動，follower從leader拉取資料，保證和leader的資料一致，這樣一個broker宕機後，如果某個分割槽的的leader掛掉，由於其他broker上有副本存在，那個只需要重對應的副本選舉出leader即可。
這裡面需要注意，一個是保證分割槽均勻的分佈在不同的broker上保證高可用性，第二個也需要保證同一個分割槽的副本存在於不同的broker上，不然也是會出現資料丟失的。
第二個是確認機制，有三種，分別是0,1，all三種，0：生產者發出訊息後，不保證kafka已經收到訊息，發出即不管。1：生產者發出訊息後，kafka返回確認訊息，此時算髮送成功。All:生產者發出訊息，kafka需要保證除了leader收到訊息，且follower也全部同步過去後，才返回確認收到。kafka預設是1。

如何保證資料不重複消費？
資料的不重複消費，常規可以通過兩種方式來實現，一種是資料庫的主鍵來約束，避免重複插入，一種可以通過redis存下唯一標識來限制。

如何保證順序消費訊息？
kafka的不同的分割槽上是無法保證順序的，所以要保證順序消費訊息，需要做到生產者保證訊息每次都發到一個分割槽，有兩種方式，一種是一個topic只建立一個分割槽，第二種是生產者傳送訊息時指定傳送到哪個分割槽。
kafka如何保證單個分割槽有序的，是通過加鎖保證有序。
有兩種場景：
一種是broker leader給producer傳送ack時，因為網路原因超時，此時生產者會進行重試，造成訊息重複。
一種是先後兩條訊息傳送，第一條訊息傳送失敗，第二條訊息傳送成功，然後第一條訊息重試後傳送成功，造成亂序。
為了解決重試引入的資料重複和亂序問題，kafka引入了 Producer ID（PID）和Sequence Number。對於每一個PID，該生產者傳送訊息的每個<topic,partion> 都會對應一個單調遞增的Sequence Number。
同樣broker端也會為每一個<PID,Topic,Partition>維護一個序號，並且每條訊息commit成功，都會將其序號遞增。對於接收的每條訊息，如果其序號比Broker維護的需要大一，則broker會接受，否則將其丟棄。如果訊息序號比broker維護的序號差值比1大，則說明中間有資料尚未寫入，此時資料為亂序，broker拒絕該訊息，producer丟擲InvalidSequenceNumber異常，表示非法的序列號。如果訊息序號小於等於broker維護的序號，說明該訊息已經被儲存，即為重複訊息，broker直接丟棄該訊息，producer丟擲DuplicateSequenceNumber。

出現消費者故障，出現活鎖問題？
kafka消費者正常情況下是訂閱一個topic並且可以poll訊息，一個topic下的分割槽只能被一個消費者佔有，消費定期向zookeeper傳送心跳檢測，證明自己活著。但是如果一個消費者佔據了一個分割槽後，正常傳送心跳，但是不poll訊息，這種情況下就是活鎖現象。
如何解決活鎖？kafka可以配置一個活躍檢測機制，配置引數是max.poll.interval.ms，如果客戶端呼叫poll的頻率大於了最大間隔，就會和當前客戶端斷開連線，讓其他消費者過來消費。但是這樣也會引入新的問題，如果消費者處理訊息過慢，在一定時間內沒有處理完訊息，沒有poll操作，此時會被斷開連線，觸發rebalance，所以為了保證訊息正常消費，可以合理設定poll超時時長和每次拉取的資料條數spring.kafka.consumer.max-poll-records