一、Kafka宕機引發的高可用問題
問題要從一次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的多副本冗餘設計實現了？別急，咱繼續往下看。
在Kafka 0.8版本以前，是沒有多副本冗餘機制的，一旦一個節點掛掉，那麼這個節點上的所有 Partition的數據就無法再被消費。這就等於發送到Topic的有一部分數據丟失了。
在0.8版本後引入副本記者則很好地解決宕機後數據丟失的問題。副本是以 Topic 中每個 Partition的數據爲單位，每個Partition的數據會同步到其他物理節點上，形成多個副本。
每個 Partition 的副本都包括一個 Leader 副本和多個 Follower副本，Leader由所有的副本共同選舉得出，其他副本則都爲Follower副本。在生產者寫或者消費者讀的時候，都只會與Leader打交道，在寫入數據後Follower就會來拉取數據進行數據同步。
就這麼簡單？是的，基於上面這張多副本架構圖就實現了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上感到困惑，如果有朋友瞭解的煩請指教~
