消息中間件有很多種，如：ActiveMQ、RabbitMQ，Kafka，RocketMQ
- ActiveMQ
- RabbitMQ
- RocketMQ
- Kafka
筆者也只在項目中使用到了Kafka ，所以面試時也只總結了一下Kafka，本篇就主講Kakfa了
1、kafka的特點
Kafka是Apache下的一個子項目，是一個高性能跨語言分佈式Publish/Subscribe消息隊列系統。
具有以下特性：高吞吐、持久可靠、擴展性與容錯性好
- 持久性、可靠性：消息被持久化到本地磁盤，並且支持數據備份防止數據丟失
- 高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；
- 可擴展性：kafka集羣支持熱擴展
- 容錯性：允許集羣中節點失敗（若副本數量爲n,則允許n-1個節點失敗）
如果有日誌採集功能，肯定是首選kafka了
擴展：
高吞吐原因：順序讀寫、零拷貝、分區分配
2、kafka基本元素
- topic： 主題，每個topic有多個分區，則需要對多個消費者做負載均衡，但請注意，相同的消費者組中不能有比分區更多的消費者，否則多出的消費者一直處於空等待，不會收到消息
- producer： 生產者：發佈消息的對象
- consumenr： 消費者：訂閱並處理消息的種子對象
- broker： 代理：保存消息的服務器，一個Borker就是Kafka集羣中的一個實例
3、文件存儲機制
-
每一個topic都有多個partition，多個partition，好處在於他對broker進行的分片，每個分片存儲合理的消息數，提升了io性能
-
每個partition爲一個目錄，partiton命名規則爲topic名稱+有序序號，第一個partiton序號從0開始
-
每個partition又分爲多個段segment，所以每次操作都是針對一小部分做操作，很輕便，並且增加
並行操作的能力 -
parition(分區)內的每條消息都有一個有序的id號（偏移offset）；offset表示partiion的第多少message
segment file組成：
-
由2大部分組成。分別爲index file和data file，成對出現，
-
後綴”.index”和“.log”分別表示爲segment索引文件、數據文件
Kafka使用順序寫入磁盤，將數據順序插入到文件末尾，
消費者端通過控制偏移量來讀取消息
4、消息發送方式
同步（sync）和異步（async）：默認是同步方式，可通過producer.type屬性進行配置
同步模式：生產者寫一條消息的時候，它就立馬發送到某個分區去
(a)生產者等待10S，如果broker沒有給出ack響應，就認爲失敗。
(b)生產者重試3次，如果還沒有響應，就報錯。
在異步模式：先緩存一段時間再發送；時間和發送數量都可配置；
異步模式，還有4個配套的參數，如下：
| Property | Default | Description |
|---|---|---|
| queue.buffering.max.ms | 5000 | 異步模式時，producer緩存隊列消息的時間(毫秒)。 |
| queue.buffering.max.messages | 10000 | 異步模式時，最大緩存的消息數量，超過則阻塞或者丟棄。 |
| queue.enqueue.timeout.ms | -1 | 如果設置爲0，丟掉；-1，阻塞 |
| batch.num.messages | 200 | 異步模式時，每次批量發送的數量，達到纔會發送 |
**消息發送的應答機制 **
request.required.acks
- 0—不進行消息接收是否成功的確認；
- 1—表示當Leader接收成功時確認；
- -1—表示Leader和Follower都接收成功時確認；
5、消息分發策略
1、分區分配
範圍分區，輪詢分區，隨意分配
範圍分區：Range 策略是對每個主題而言的，首先對同一個主題裏面的分區按照序號進行排序，並對消費者按照字母順序進行排序。然後將 partitions 的個數除於消費者線程的總數來決定每個消費者線程消費幾個分區。如果除不盡，那麼前面幾個消費者線程將會多消費一個分區。
輪詢分區：輪詢分區策略是把所有 partition 和所有 consumer 線程都列出來，然後按照hashcode 進行排序。按照hashcode排序通過輪詢分配 partition 給消費線程
默認情況下， kafka 採用的是 hash 取模的分區算法。如果Key 爲 null，則會隨機分配一個分區。
kafka提供了2種策略來刪除數據：基於時間刪除和基於partition文件的大小刪除。
2、重平衡
當消費者離開消費組（比如重啓、宕機等）時，它所消費的分區會分配給其他分區。這種現象稱爲重平衡
reblance觸發條件
1.當消費者group內部有新的消費者加入時。
2.當有消費者離開消費者group時
3.topic新增分區時
以上三種情況觸發reblance策略，重新制定消費者消費分區。時；
6、數據丟失問題
生產者丟失場景：
- 不進行消息接收確認情況下(acks=0)，當網絡異常、緩衝區滿了等情況時，消息可能丟失；
- 當Leader接收成功時確認(acks=1)、同步模式下，Leader確認接收成功後但掛掉了，副本沒有同步，數據可能丟失；
- 解決方案： ack配置（0：不確認；1：leader確認；-1：主從都確認）
消費者消息丟失的場景
- 如果設置了自動提交，可能當消費者把消息取出來、並提交了offset後，還沒來得及消費就掛掉了
解決方案：關閉自動提交
7、重複消費問題
底層根本原因：已經消費了數據，但是offset沒提交。
場景：
- 強制kill線程，導致消費者的數據沒有offset提交
- 消費後的數據，當offset還沒有提交時，partition就斷開連接。比如：超過了Kafka的session timeout時間，導致重平衡
解決方案：
- 關閉自動提交
- 每次都判斷消息是否重複消費過了
8、ZooKeeper和kafka關係
kafka使用ZooKeeper用於管理、協調代理。每個Kafka代理通過Zookeeper協調其他Kafka代理。
面試總結整理：
offer直通車（一）之JAVA
offer直通車（二）之數據結構與算法
offer直通車（三）之設計模式
offer直通車（四）之數據庫
offer直通車（五）之WEB
offer直通車（六）之Spring系列
offer直通車（七）之Linux 系統
offer直通車（八）之分佈式微服務
offer直通車（九）之緩存中間件
offer直通車（十）之消息中間件