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