問題要從一次Kafka的宕機開始說起。
筆者所在的是一家金融科技公司，但公司內部並沒有採用在金融支付領域更爲流行的 RabbitMQ ，而是採用了設計之初就爲日誌處理而生的 Kafka ，所以我一直很好奇Kafka的高可用實現和保障。從 Kafka 部署後，系統內部使用的 Kafka 一直運行穩定，沒有出現不可用的情況。
但最近系統測試人員常反饋偶有Kafka消費者收不到消息的情況，登陸管理界面發現三個節點中有一個節點宕機掛掉了。但是按照高可用的理念，三個節點還有兩個節點可用怎麼就引起了整個集羣的消費者都接收不到消息呢？
要解決這個問題，就要從 Kafka 的高可用實現開始講起。
Kafka 的多副本冗餘設計
不管是傳統的基於關係型數據庫設計的系統，還是分佈式的如 zookeeper 、 redis 、 Kafka 、 HDFS 等等，實現高可用的辦法通常是採用冗餘設計，通過冗餘來解決節點宕機不可用問題。
首先簡單瞭解 Kafka 的幾個概念：
Broker （節點）：Kafka 服務節點，簡單來說一個 Broker 就是一臺 Kafka 服務器，一個物理節點。
Topic （主題）：在 Kafka 中消息以主題爲單位進行歸類，每個主題都有一個 Topic Name ，生產者根據 Topic Name 將消息發送到特定的 Topic，消費者則同樣根據 Topic Name 從對應的 Topic 進行消費。
Partition （分區）：Topic （主題）是消息歸類的一個單位，但每一個主題還能再細分爲一個或多個 Partition （分區），一個分區只能屬於一個主題。主題和分區都是邏輯上的概念，舉個例子，消息1和消息2都發送到主題1，它們可能進入同一個分區也可能進入不同的分區（所以同一個主題下的不同分區包含的消息是不同的），之後便會發送到分區對應的Broker節點上。
Offset （偏移量）：分區可以看作是一個只進不出的隊列（Kafka只保證一個分區內的消息是有序的），消息會往這個隊列的尾部追加，每個消息進入分區後都會有一個偏移量，標識該消息在該分區中的位置，消費者要消費該消息就是通過偏移量來識別。
就這麼簡單？是的，基於上面這張多副本架構圖就實現了 Kafka 的高可用。當某個 Broker 掛掉了，甭擔心，這個 Broker 上的 Partition 在其他 Broker 節點上還有副本。你說如果掛掉的是 Leader 怎麼辦？那就在 Follower中在選舉出一個 Leader 即可，生產者和消費者又可以和新的 Leader 愉快地玩耍了，這就是高可用。
你可能還有疑問，那要多少個副本纔算夠用？Follower 和 Leader 之間沒有完全同步怎麼辦？一個節點宕機後 Leader 的選舉規則是什麼？
直接拋結論:
多少個副本纔算夠用？
副本肯定越多越能保證 Kafka 的高可用，但越多的副本意味着網絡、磁盤資源的消耗更多，性能會有所下降，通常來說副本數爲3即可保證高可用，極端情況下將 replication-factor 參數調大即可。
Follower 和 Lead 之間沒有完全同步怎麼辦？
Follower 和 Leader 之間並不是完全同步，但也不是完全異步，而是採用一種 ISR機制（ In-Sync Replica）。每個Leader會動態維護一個ISR列表，該列表裏存儲的是和Leader基本同步的Follower。如果有 Follower 由於網絡、GC 等原因而沒有向 Leader 發起拉取數據請求，此時 Follower 相對於 Leader 是不同步的，則會被踢出 ISR 列表。所以說，ISR 列表中的 Follower 都是跟得上 Leader 的副本。
一個節點宕機後 Leader 的選舉規則是什麼？
分佈式相關的選舉規則有很多，像 Zookeeper的 Zab 、 Raft、 Viewstamped Replication、微軟的 PacificA 等。而 Kafka 的 Leader 選舉思路很簡單，基於我們上述提到的 ISR 列表，當宕機後會從所有副本中順序查找，如果查找到的副本在ISR列表中，則當選爲Leader。另外還要保證前任Leader已經是退位狀態了，否則會出現腦裂情況（有兩個Leader）。怎麼保證？Kafka 通過設置了一個 controller 來保證只有一個 Leader。
Ack 參數決定了可靠程度
另外，這裏補充一個面試考Kafka高可用必備知識點：request.required.asks 參數。
Asks 這個參數是生產者客戶端的重要配置，發送消息的時候就可設置這個參數。該參數有三個值可配置：0、1、All 。
第一種是設爲0，意思是生產者把消息發送出去之後，之後這消息是死是活咱就不管了，有那麼點發後即忘的意思，說出去的話就不負責了。不負責自然這消息就有可能丟失，那就把可用性也丟失了。
第二種是設爲1，意思是生產者把消息發送出去之後，這消息只要順利傳達給了Leader，其他
Follower有沒有同步就無所謂了。存在一種情況，Leader剛收到了消息，Follower還沒來得及同步Broker就宕機了，但生產者已經認爲消息發送成功了，那麼此時消息就丟失了。
設爲1是Kafka的默認配置，可見Kafka的默認配置也不是那麼高可用，而是對高可用和高吞吐量做了權衡折中。
第三種是設爲All（或者-1）
意思是生產者把消息發送出去之後，不僅Leader要接收到，ISR列表中的Follower也要同步到，生產者纔會任務消息發送成功。
進一步思考， Asks=All 就不會出現丟失消息的情況嗎？答案是否。當ISR列表只剩Leader的情況下， Asks=All 相當於 Asks=1 ，這種情況下如果節點宕機了，還能保證數據不丟失嗎？因此只有在 Asks=All 並且有ISR中有兩個副本的情況下才能保證數據不丟失。
解決問題
繞了一大圈，瞭解了Kafka的高可用機制，終於回到我們一開始的問題本身， Kafka 的一個節點宕機後爲什麼不可用？
我在開發測試環境配置的 Broker 節點數是3， Topic 是副本數爲3， Partition 數爲6， Asks 參數爲1。
當三個節點中某個節點宕機後，集羣首先會怎麼做？沒錯，正如我們上面所說的，集羣發現有Partition的Leader失效了，這個時候就要從ISR列表中重新選舉Leader。如果ISR列表爲空是不是就不可用了？並不會，而是從Partition存活的副本中選擇一個作爲Leader，不過這就有潛在的數據丟失的隱患了。
所以，只要將Topic副本個數設置爲和Broker個數一樣，Kafka的多副本冗餘設計是可以保證高可用的，不會出現一宕機就不可用的情況（不過需要注意的是Kafka有一個保護策略，當一半以上的節點不可用時Kafka就會停止）。那仔細一想，Kafka上是不是有副本個數爲1的Topic？
問題出在了 __consumer_offset 上， __consumer_offset 是一個 Kafka 自動創建的 Topic，用來存儲消費者消費的 offset （偏移量）信息，默認 Partition 數爲50。而就是這個Topic，它的默認副本數爲1。如果所有的 Partition 都存在於同一臺機器上，那就是很明顯的單點故障了！當將存儲 __consumer_offset 的 Partition 的 Broker 給 Kill 後，會發現所有的消費者都停止消費了。
這個問題怎麼解決？
第一點 ，需要將 __consumer_offset 刪除，注意這個Topic時Kafka內置的Topic，無法用命令刪除，我是通過將 logs 刪了來實現刪除。
第二點 ，需要通過設置 offsets.topic.replication.factor 爲3來將 __consumer_offset 的副本數改爲3。通過將 __consumer_offset 也做副本冗餘後來解決某個節點宕機後消費者的消費問題。
最後，關於爲什麼 __consumer_offset 的 Partition 會出現只存儲在一個 Broker 上而不是分佈在各個 Broker 上感到困惑。
