本篇主要介紹kafka的分區(qū)和副本，因為這兩者是有些關聯(lián)的，所以就放在一起來講了，后面順便會給出一些對應的配置以及具體的實現(xiàn)代碼，以供參考~

1.kafka分區(qū)機制

分區(qū)機制是kafka實現(xiàn)高吞吐的秘密武器，但這個武器用得不好的話也容易出問題，今天主要就來介紹分區(qū)的機制以及相關的部分配置。

首先，從數(shù)據(jù)組織形式來說，kafka有三層形式，kafka有多個主題，每個主題有多個分區(qū)，每個分區(qū)又有多條消息。

而每個分區(qū)可以分布到不同的機器上，這樣一來，從服務端來說，分區(qū)可以實現(xiàn)高伸縮性，以及負載均衡，動態(tài)調(diào)節(jié)的能力。

當然多分區(qū)就意味著每條消息都難以按照順序存儲，那么是不是意味著這樣的業(yè)務場景kafka就無能為力呢？不是的，最簡單的做法可以使用單個分區(qū)，單個分區(qū)，所有消息自然都順序寫入到一個分區(qū)中，就跟順序隊列一樣了。而復雜些的，還有其他辦法，那就是使用按消息鍵，將需要順序保存的消息存儲的單獨的分區(qū)，其他消息存儲其他分區(qū)，這個在下面會介紹。

我們可以通過replication-factor指定創(chuàng)建topic時候所創(chuàng)建的分區(qū)數(shù)。

bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test

比如這里就是創(chuàng)建了1個分區(qū)，的主題。值得注意的是，還有一種創(chuàng)建主題的方法，是使用zookeeper參數(shù)的，那種是比較舊的創(chuàng)建方法，這里是使用bootstrap參數(shù)的。

1.1 分區(qū)個數(shù)選擇

既然分區(qū)效果這么好，是不是越多分區(qū)越好呢？顯而易見并非如此。

分區(qū)越多，所需要消耗的資源就越多。甚至如果足夠大的時候，還會觸發(fā)到操作系統(tǒng)的一些參數(shù)限制。比如linux中的文件描述符限制，一般在創(chuàng)建線程，創(chuàng)建socket，打開文件的場景下，linux默認的文件描述符參數(shù)，只有1024，超過則會報錯。

看到這里有讀者就會不耐煩了，說這么多有啥用，能不能直接告訴我分區(qū)分多少個比較好？很遺憾，暫時沒有。

因為每個業(yè)務場景都不同，只能結合具體業(yè)務來看。假如每秒鐘需要從主題寫入和讀取1GB數(shù)據(jù)，而消費者1秒鐘最多處理50MB的數(shù)據(jù)，那么這個時候就可以設置20-25個分區(qū)，當然還要結合具體的物理資源情況。

而如何無法估算出大概的處理速度和時間，那么就用基準測試來測試吧。創(chuàng)建不同分區(qū)的topic，逐步壓測測出最終的結果。如果實在是懶得測，那比較無腦的確定分區(qū)數(shù)的方式就是broker機器數(shù)量的2~3倍。

1.2 分區(qū)寫入策略

所謂分區(qū)寫入策略，即是生產(chǎn)者將數(shù)據(jù)寫入到kafka主題后，kafka如何將數(shù)據(jù)分配到不同分區(qū)中的策略。

常見的有三種策略，輪詢策略，隨機策略，和按鍵保存策略。其中輪詢策略是默認的分區(qū)策略，而隨機策略則是較老版本的分區(qū)策略，不過由于其分配的均衡性不如輪詢策略，故而后來改成了輪詢策略為默認策略。

輪詢策略

所謂輪詢策略，即按順序輪流將每條數(shù)據(jù)分配到每個分區(qū)中。

舉個例子，假設主題test有三個分區(qū)，分別是分區(qū)A，分區(qū)B和分區(qū)C。那么主題對接收到的第一條消息寫入A分區(qū)，第二條消息寫入B分區(qū)，第三條消息寫入C分區(qū)，第四條消息則又寫入A分區(qū)，依此類推。

輪詢策略是默認的策略，故而也是使用最頻繁的策略，它能最大限度保證所有消息都平均分配到每一個分區(qū)。除非有特殊的業(yè)務需求，否則使用這種方式即可。

隨機策略

隨機策略，也就是每次都隨機地將消息分配到每個分區(qū)。其實大概就是先得出分區(qū)的數(shù)量，然后每次獲取一個隨機數(shù)，用該隨機數(shù)確定消息發(fā)送到哪個分區(qū)。

在比較早的版本，默認的分區(qū)策略就是隨機策略，但其實使用隨機策略也是為了更好得將消息均衡寫入每個分區(qū)。但后來發(fā)現(xiàn)對這一需求而言，輪詢策略的表現(xiàn)更優(yōu)，所以社區(qū)后來的默認策略就是輪詢策略了。

按鍵保存策略

按鍵保存策略，就是當生產(chǎn)者發(fā)送數(shù)據(jù)的時候，可以指定一個key，計算這個key的hashCode值，按照hashCode的值對不同消息進行存儲。

至于要如何實現(xiàn)，那也簡單，只要讓生產(chǎn)者發(fā)送的時候指定key就行。欸剛剛不是說默認的是輪詢策略嗎？其實啊，kafka默認是實現(xiàn)了兩個策略，沒指定key的時候就是輪詢策略，有的話那激素按鍵保存策略了。

上面有說到一個場景，那就是要順序發(fā)送消息到kafka。前面提到的方案是讓所有數(shù)據(jù)存儲到一個分區(qū)中，但其實更好的做法，就是使用這種按鍵保存策略。

讓需要順序存儲的數(shù)據(jù)都指定相同的鍵，而不需要順序存儲的數(shù)據(jù)指定不同的鍵，這樣一來，即實現(xiàn)了順序存儲的需求，又能夠享受到kafka多分區(qū)的優(yōu)勢，豈不美哉。

1.3 實現(xiàn)自定義分區(qū)

說了這么多，那么到底要如何自定義分區(qū)呢？

kafka提供了兩種讓我們自己選擇分區(qū)的方法，第一種是在發(fā)送producer的時候，在ProducerRecord中直接指定，但需要知道具體發(fā)送的分區(qū)index，所以并不推薦。

第二種則是需要實現(xiàn)Partitioner.class類，并重寫類中的partition(String topic, Object key, byte[] keyBytes,Object value, byte[] valueBytes, Cluster cluster) 方法。后面在生成kafka producer客戶端的時候直接指定新的分區(qū)類就可以了。

package kafkaconf;
import java.util.List;
import java.util.Map;
import java.util.concurrent.ThreadLocalRandom;

import org.apache.kafka.clients.producer.Partitioner;
import org.apache.kafka.common.Cluster;
import org.apache.kafka.common.PartitionInfo;


public class MyParatitioner implements Partitioner {
    @Override
    public void configure(Map<String, ?> configs) {
    }

    @Override
    public int partition(String topic, Object key, byte[] keyBytes,
                         Object value, byte[] valueBytes, Cluster cluster) {
        //key不能空，如果key為空的會通過輪詢的方式 選擇分區(qū)
        if(keyBytes == null || (!(key instanceof String))){
            throw new RuntimeException("key is null");
        }
        //獲取分區(qū)列表
        List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);

        //以下是上述各種策略的實現(xiàn)，不能共存
        //隨機策略
        return ThreadLocalRandom.current().nextInt(partitions.size());

        //按消息鍵保存策略
        return Math.abs(key.hashCode()) % partitions.size();

        //自定義分區(qū)策略, 比如key為123的消息，選擇放入最后一個分區(qū)
        if(key.toString().equals("123")){
            return partitions.size()-1;
        }else{
            //否則隨機
            ThreadLocalRandom.current().nextInt(partitions.size());
        }
    }

    @Override
    public void close() {
    }
}

然后需要在生成kafka producer客戶端的時候指定該類就行：

    val properties = new Properties()
    ......
    props.put("partitioner.class", "kafkaconf.MyParatitioner");  //主要這個配置指定分區(qū)類
    ......其他配置
    val producer = new KafkaProducer[String, String](properties)

2.kafka副本機制

說完了分區(qū)，再來說說副本。先說說副本的基本內(nèi)容，在kafka中，每個主題可以有多個分區(qū)，每個分區(qū)又可以有多個副本。這多個副本中，只有一個是leader，而其他的都是follower副本。僅有l(wèi)eader副本可以對外提供服務。

多個follower副本通常存放在和leader副本不同的broker中。通過這樣的機制實現(xiàn)了高可用，當某臺機器掛掉后，其他follower副本也能迅速”轉正“，開始對外提供服務。

這里通過問題來整理這部分內(nèi)容。

kafka的副本都有哪些作用？

在kafka中，實現(xiàn)副本的目的就是冗余備份，且僅僅是冗余備份，所有的讀寫請求都是由leader副本進行處理的。follower副本僅有一個功能，那就是從leader副本拉取消息，盡量讓自己跟leader副本的內(nèi)容一致。

說說follower副本為什么不對外提供服務？

這個問題本質(zhì)上是對性能和一致性的取舍。試想一下，如果follower副本也對外提供服務那會怎么樣呢？首先，性能是肯定會有所提升的。但同時，會出現(xiàn)一系列問題。類似數(shù)據(jù)庫事務中的幻讀，臟讀。

比如你現(xiàn)在寫入一條數(shù)據(jù)到kafka主題a，消費者b從主題a消費數(shù)據(jù)，卻發(fā)現(xiàn)消費不到，因為消費者b去讀取的那個分區(qū)副本中，最新消息還沒寫入。而這個時候，另一個消費者c卻可以消費到最新那條數(shù)據(jù)，因為它消費了leader副本。

看吧，為了提高那么些性能而導致出現(xiàn)數(shù)據(jù)不一致問題，那顯然是不值得的。

leader副本掛掉后，如何選舉新副本？

如果你對zookeeper選舉機制有所了解，就知道zookeeper每次leader節(jié)點掛掉時，都會通過內(nèi)置id，來選舉處理了最新事務的那個follower節(jié)點。

從結果上來說，kafka分區(qū)副本的選舉也是類似的，都是選擇最新的那個follower副本，但它是通過一個In-sync（ISR）副本集合實現(xiàn)。

kafka會將與leader副本保持同步的副本放到ISR副本集合中。當然，leader副本是一直存在于ISR副本集合中的，在某些特殊情況下，ISR副本中甚至只有l(wèi)eader一個副本。

當leader掛掉時，kakfa通過zookeeper感知到這一情況，在ISR副本中選取新的副本成為leader，對外提供服務。

但這樣還有一個問題，前面提到過，有可能ISR副本集合中，只有l(wèi)eader，當leader副本掛掉后，ISR集合就為空，這時候怎么辦呢？這時候如果設置unclean.leader.election.enable參數(shù)為true，那么kafka會在非同步，也就是不在ISR副本集合中的副本中，選取出副本成為leader，但這樣意味這消息會丟失，這又是可用性和一致性的一個取舍了。

ISR副本集合保存的副本的條件是什么？

上面一直說ISR副本集合中的副本就是和leader副本是同步的，那這個同步的標準又是什么呢？

答案其實跟一個參數(shù)有關：replica.lag.time.max.ms。

前面說到follower副本的任務，就是從leader副本拉取消息，如果持續(xù)拉取速度慢于leader副本寫入速度，慢于時間超過replica.lag.time.max.ms后，它就變成“非同步”副本，就會被踢出ISR副本集合中。但后面如何follower副本的速度慢慢提上來，那就又可能會重新加入ISR副本集合中了。

producer的acks參數(shù)

前面說了那么多理論的知識，那么就可以來看看如何在實際應用中使用這些知識。

跟副本關系最大的，那自然就是acks機制，acks決定了生產(chǎn)者如何在性能與數(shù)據(jù)可靠之間做取舍。

配置acks的代碼其實很簡單，只需要在新建producer的時候多加一個配置：

    val properties = new Properties()
    ......
    props.put("acks", "0/1/-1");  //配置acks，有三個可選值
    ......其他配置
    val producer = new KafkaProducer[String, String](properties)

acks這個配置可以指定三個值，分別是0，1和-1。我們分別來說三者代表什么：

• acks為0：這意味著producer發(fā)送數(shù)據(jù)后，不會等待broker確認，直接發(fā)送下一條數(shù)據(jù)，性能最快
• acks為1：為1意味著producer發(fā)送數(shù)據(jù)后，需要等待leader副本確認接收后，才會發(fā)送下一條數(shù)據(jù)，性能中等
• acks為-1：這個代表的是all，意味著發(fā)送的消息寫入所有的ISR集合中的副本（注意不是全部副本）后，才會發(fā)送下一條數(shù)據(jù)，性能最慢，但可靠性最強

還有一點值得一提，kafka有一個配置參數(shù)，min.insync.replicas，默認是1（也就是只有l(wèi)eader，實際生產(chǎn)應該調(diào)高），該屬性規(guī)定了最小的ISR數(shù)。這意味著當acks為-1（即all）的時候，這個參數(shù)規(guī)定了必須寫入的ISR集中的副本數(shù)，如果沒達到，那么producer會產(chǎn)生異常。

以上~