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

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

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

Kafka不僅僅是一個隊列，而且是一個存儲，有超強的堆積能力。

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

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

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

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

這種設(shè)計有以下幾個問題：

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

無法橫向擴容處理能力，且會引入分布式鎖、順序性保證等問題。

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

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

請求會暫存在消息隊列，然后實時通過推（或者拉）的方式進行處理。
在此場景下，消息隊列充當(dāng)了削峰和冗余的組件。

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

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

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

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

健壯性 消息隊列可以堆積請求，所以消費端業(yè)務(wù)即使短時間死掉，也不會影響主要業(yè)務(wù)的正常進行。

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

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

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

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

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

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

你在一臺機器上安裝了Kafka，那么這臺機器就叫Broker，KAFKA集群包含了一個或者多個這樣的實例。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1（默認(rèn)） 數(shù)據(jù)發(fā)送到Kafka后，經(jīng)過leader成功接收消息的的確認(rèn)，就算是發(fā)送成功了。在這種情況下，如果leader宕機了，則會丟失數(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ù)情況下比隨機寫內(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