摘要：一些觀念的修正從版本開始，的標(biāo)語(yǔ)已經(jīng)從一個(gè)高吞吐量，分布式的消息系統(tǒng)改為一個(gè)分布式流平臺(tái)。不僅用在吞吐量高的大數(shù)據(jù)場(chǎng)景，也可以用在有事務(wù)要求的業(yè)務(wù)系統(tǒng)上，但性能較低。消息系統(tǒng)的作用削峰用于承接超出業(yè)務(wù)系統(tǒng)處理能力的請(qǐng)求，使業(yè)務(wù)平穩(wěn)運(yùn)行。

我們?cè)凇?60度測(cè)試：KAFKA會(huì)丟數(shù)據(jù)么？其高可用是否滿足需求？》這篇文章中，詳細(xì)說(shuō)明了KAFKA是否適合用在業(yè)務(wù)系統(tǒng)中。但有些朋友，還不知道KAFKA為何物，以及它為何存在。這在工作和面試中是比較吃虧的，因?yàn)椴恢朗裁磿r(shí)候起，KAFKA似乎成了一種工程師的必備技能。

從 0.9 版本開始，Kafka 的標(biāo)語(yǔ)已經(jīng)從“一個(gè)高吞吐量，分布式的消息系統(tǒng)”改為"一個(gè)分布式流平臺(tái)"。

Kafka不僅僅是一個(gè)隊(duì)列，而且是一個(gè)存儲(chǔ)，有超強(qiáng)的堆積能力。

Kafka不僅用在吞吐量高的大數(shù)據(jù)場(chǎng)景，也可以用在有事務(wù)要求的業(yè)務(wù)系統(tǒng)上，但性能較低。

Kafka不是Topic越多越好，由于其設(shè)計(jì)原理，在數(shù)量達(dá)到閾值后，其性能和Topic數(shù)量成反比。

引入了消息隊(duì)列，就等于引入了異步，不管你是出于什么目的。這通常意味著業(yè)務(wù)流程的改變，甚至產(chǎn)品體驗(yàn)的變更。

上圖是一些小系統(tǒng)的典型架構(gòu)?？紤]訂單的業(yè)務(wù)場(chǎng)景，有大量的請(qǐng)求指向我們的業(yè)務(wù)系統(tǒng)，如果直接經(jīng)過(guò)復(fù)雜的業(yè)務(wù)邏輯進(jìn)入業(yè)務(wù)表，將會(huì)有大量請(qǐng)求超時(shí)失敗。所以我們加入了一張中間緩沖表（或者Redis），用來(lái)承接用戶的請(qǐng)求。然后，有一個(gè)定時(shí)任務(wù)，不斷的從緩沖表中獲取數(shù)據(jù)，進(jìn)行真正的業(yè)務(wù)邏輯處理。

這種設(shè)計(jì)有以下幾個(gè)問(wèn)題：

定時(shí)任務(wù)的輪詢間隔不好控制。業(yè)務(wù)處理容易延遲。

無(wú)法橫向擴(kuò)容處理能力，且會(huì)引入分布式鎖、順序性保證等問(wèn)題。

當(dāng)其他業(yè)務(wù)也需要這些訂單數(shù)據(jù)的時(shí)候，業(yè)務(wù)邏輯就必須要加入到定時(shí)任務(wù)里。

當(dāng)訪問(wèn)量增加、業(yè)務(wù)邏輯復(fù)雜化的時(shí)候，消息隊(duì)列就呼之欲出了。

請(qǐng)求會(huì)暫存在消息隊(duì)列，然后實(shí)時(shí)通過(guò)推（或者拉）的方式進(jìn)行處理。
在此場(chǎng)景下，消息隊(duì)列充當(dāng)了削峰和冗余的組件。

削峰 用于承接超出業(yè)務(wù)系統(tǒng)處理能力的請(qǐng)求，使業(yè)務(wù)平穩(wěn)運(yùn)行。這能夠大量節(jié)約成本，比如某些秒殺活動(dòng)，并不是針對(duì)峰值設(shè)計(jì)容量。

緩沖 在服務(wù)層和緩慢的落地層作為緩沖層存在，作用與削峰類似，但主要用于服務(wù)內(nèi)數(shù)據(jù)流轉(zhuǎn)。比如批量短信發(fā)送。

解耦 項(xiàng)目尹始，并不能確定具體需求。消息隊(duì)列可以作為一個(gè)接口層，解耦重要的業(yè)務(wù)流程。只需要遵守約定，針對(duì)數(shù)據(jù)編程即可獲取擴(kuò)展能力。

冗余 消息數(shù)據(jù)能夠采用一對(duì)多的方式，供多個(gè)毫無(wú)關(guān)聯(lián)的業(yè)務(wù)使用。

健壯性 消息隊(duì)列可以堆積請(qǐng)求，所以消費(fèi)端業(yè)務(wù)即使短時(shí)間死掉，也不會(huì)影響主要業(yè)務(wù)的正常進(jìn)行。

消息系統(tǒng)即然這么重要，那么除了能夠保證高可用，對(duì)它本身的特性也有較高需求。大體有下面幾點(diǎn)：

性能要高 包含消息投遞和消息消費(fèi)，都要快。一般通過(guò)增加分片數(shù)獲取并行處理能力。

消息要可靠 在某些場(chǎng)景，不能丟消息。生產(chǎn)、消費(fèi)、MQ端都不能丟消息。一般通過(guò)增加副本，強(qiáng)制刷盤來(lái)解決。

擴(kuò)展性要好 能夠陪你把項(xiàng)目做大，陪你到天荒地老。增加節(jié)點(diǎn)集群增大后，不能降低性能。

生態(tài)成熟 監(jiān)控、運(yùn)維、多語(yǔ)言支持、社區(qū)的活躍。

Kafka是一個(gè)分布式消息(存儲(chǔ)）系統(tǒng)。分布式系統(tǒng)通過(guò)分片增加并行度；通過(guò)副本增加可靠性，kafka也不例外。我們來(lái)看一下它的結(jié)構(gòu)，順便解釋一下其中的術(shù)語(yǔ)。

你在一臺(tái)機(jī)器上安裝了Kafka，那么這臺(tái)機(jī)器就叫Broker，KAFKA集群包含了一個(gè)或者多個(gè)這樣的實(shí)例。

負(fù)責(zé)往KAFKA寫入數(shù)據(jù)的組件就叫做Producer，消息的生產(chǎn)者一般寫在業(yè)務(wù)系統(tǒng)里。

發(fā)送到KAFKA的消息可能有多種，如何區(qū)別其分類？就是Topic的概念。一個(gè)主題分布式化后，可能會(huì)存在多個(gè)Broker上。

將Topic拆成多個(gè)段，增加并行度后，拆成的每個(gè)部分叫做Partition，分區(qū)一般平均分布在所有機(jī)器上。

那些消費(fèi)Kafka中數(shù)據(jù)的應(yīng)用程序，就叫做Consumer，我們給某個(gè)主題的某個(gè)消費(fèi)業(yè)務(wù)起一個(gè)名字，這么名字就叫做Consumer Group

Connector 連接器Task，包含Source和Sink兩種接口，給用戶提供了自定義數(shù)據(jù)流轉(zhuǎn)的可能。比如從JDBC導(dǎo)入到Kafka，或者將Kafka數(shù)據(jù)直接落地到DB。

Stream 類似于Spark Stream，能夠進(jìn)行流數(shù)據(jù)處理。但它本身沒(méi)有集群，只是在KAFKA集群上的抽象。如果你想要實(shí)時(shí)的流處理，且不需要Hadoop生態(tài)的某些東西，那么這個(gè)比較適合你。

我們的消息就是寫在主題里。有了多個(gè)Topic，就可以對(duì)消息進(jìn)行歸類與隔離。比如登錄信息寫在user_activity_topic，日志消息寫在log_topic中。

每一個(gè)topic都可以調(diào)整其分區(qū)數(shù)量。假設(shè)我們的集群有三個(gè)Broker，那么當(dāng)分區(qū)數(shù)量為1的時(shí)候，消息就僅寫在其中一個(gè)節(jié)點(diǎn)上；當(dāng)我們的分區(qū)為3，消息會(huì)根據(jù)hash寫到三個(gè)節(jié)點(diǎn)上；當(dāng)我們的分區(qū)為6，那每個(gè)節(jié)點(diǎn)將會(huì)有2個(gè)分區(qū)信息。增加分區(qū)可以增加并行度，但不是越多越好。一般，6-12最佳，最好能夠被節(jié)點(diǎn)數(shù)整除，避免數(shù)據(jù)傾斜。

每個(gè)分區(qū)都由一系列有序的、不可變的消息組成，這些消息被順序的追加。分區(qū)中的每個(gè)消息都有一個(gè)連續(xù)的序列號(hào)叫做offset。Kafka將保留配置時(shí)間內(nèi)的所有消息，所以它也是一個(gè)臨時(shí)存儲(chǔ)。在這段時(shí)間內(nèi)，所有的消息都可被消費(fèi)，并且可以通過(guò)改變offset的值進(jìn)行重復(fù)、多次消費(fèi)。

Offset一般由消費(fèi)者管理，當(dāng)然也可以通過(guò)程序按需要設(shè)置。Offset只有commit以后，才會(huì)改變，否則，你將一直獲取重復(fù)的數(shù)據(jù)。新的kafka已經(jīng)將這些Offset的放到了一個(gè)專有的主題：__consumer_offsets，就是上圖的紫色區(qū)域。

值得一提的是，消費(fèi)者的個(gè)數(shù)，不要超過(guò)分區(qū)的個(gè)數(shù)。否則，多出來(lái)的消費(fèi)者，將接收不到任何數(shù)據(jù)。

分布式系統(tǒng)保證數(shù)據(jù)可靠性的一個(gè)常用手段就是增加副本個(gè)數(shù)，ISR就是建立在這個(gè)手段上。

ISR全稱"In-Sync Replicas"，是保證HA和一致性的重要機(jī)制。副本數(shù)對(duì)Kafka的吞吐率是有一定的影響，但極大的增強(qiáng)了可用性。一般2-3個(gè)為宜。

副本有兩個(gè)要素，一個(gè)是數(shù)量要夠多，一個(gè)是不要落在同一個(gè)實(shí)例上。ISR是針對(duì)與Partition的，每個(gè)分區(qū)都有一個(gè)同步列表。N個(gè)replicas中，其中一個(gè)replica為leader，其他都為follower, leader處理partition的所有讀寫請(qǐng)求，其他的都是備份。與此同時(shí)，follower會(huì)被動(dòng)定期地去復(fù)制leader上的數(shù)據(jù)。

如果一個(gè)flower比一個(gè)leader落后太多，或者超過(guò)一定時(shí)間未發(fā)起數(shù)據(jù)復(fù)制請(qǐng)求，則leader將其重ISR中移除。

當(dāng)ISR中所有Replica都向Leader發(fā)送ACK時(shí)，leader才commit。

Kafka的ISR的管理最終都會(huì)反饋到Zookeeper節(jié)點(diǎn)上。具體位置為：/brokers/topics/[topic]/partitions/[partition]/state。當(dāng)Leader節(jié)點(diǎn)失效，也會(huì)依賴Zk進(jìn)行新的Leader選舉。Offset轉(zhuǎn)移到Kafka內(nèi)部的Topic以后，KAFKA對(duì)ZK的依賴就越來(lái)越小了。

At least once
可能會(huì)丟消息，但不不會(huì)重復(fù)

At most once
不不丟消息，但可能重復(fù)，所以消費(fèi)端要做冪等

Exactly once
消息不不會(huì)丟，且保證只投遞?一次

整體的消息投遞語(yǔ)義需要Producer端和Consumer端兩者來(lái)保證。KAFKA默認(rèn)是At most once，也可以通過(guò)配置事務(wù)達(dá)到Exactly once，但效率很低，不推薦。

當(dāng)生產(chǎn)者向leader發(fā)送數(shù)據(jù)時(shí)，可以通過(guò)request.required.acks參數(shù)來(lái)設(shè)置數(shù)據(jù)可靠性的級(jí)別：

1（默認(rèn)） 數(shù)據(jù)發(fā)送到Kafka后，經(jīng)過(guò)leader成功接收消息的的確認(rèn)，就算是發(fā)送成功了。在這種情況下，如果leader宕機(jī)了，則會(huì)丟失數(shù)據(jù)。

0 生產(chǎn)者將數(shù)據(jù)發(fā)送出去就不管了，不去等待任何返回。這種情況下數(shù)據(jù)傳輸效率最高，但是數(shù)據(jù)可靠性確是最低的。

-1 producer需要等待ISR中的所有follower都確認(rèn)接收到數(shù)據(jù)后才算一次發(fā)送完成，可靠性最高。

Cache Filesystem Cache PageCache緩存

順序?qū)?/strong> 由于現(xiàn)代的操作系統(tǒng)提供了預(yù)讀和寫技術(shù)，磁盤的順序?qū)懘蠖鄶?shù)情況下比隨機(jī)寫內(nèi)存還要快。

./kafka-producer-perf-test.sh --topic test001 --num- records 1000000 --record-size 1024 --throughput -1 --producer.config ../config/producer.properties

log.retention.bytes

log.retention.hours    
log.retention.minutes    
log.retention.ms