Kafka消息系統基礎知識索引消息

咱們在上篇文章中，詳細說明了KAFKA是否適合用在業務系統中，但有些朋友，還不知道KAFKA爲什麼物，以及它爲什麼存在。這在工做和麪試中是比較吃虧的，由於不知道何時起，KAFKA彷佛成了一種工程師的必備技能。

消息系統是什麼

典型場景

上圖是一些小系統的典型架構。考慮訂單的業務場景，有大量的請求指向咱們的業務系統，若是直接通過複雜的業務邏輯進入業務表，將會有大量請求超時失敗。因此咱們加入了一張中間緩衝表（或者Redis），用來承接用戶的請求，而後，有一個定時任務，不斷的從緩衝表中獲取數據，進行真正的業務邏輯處理。

這種設計有如下幾個問題：

1.定時任務的輪詢間隔很差控制，業務處理容易延遲。

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

3.當其餘業務也須要這些訂單數據的時候，業務邏輯就必需要加入到定時任務裏。

當訪問量增長、業務邏輯複雜化的時候，消息隊列就呼之欲出了。

請求會暫存在消息隊列，而後實時經過推（或者拉）的方式進行處理。

在此場景下，消息隊列充當了削峯和冗餘的組件。

消息系統的做用

削峯：用於承接超出業務系統處理能力的請求，使業務平穩運行，這可以大量節約成本，好比某些秒殺活動，並非針對峯值設計容量。

緩衝：在服務層和緩慢的落地層做爲緩衝層存在，做用與削峯相似，但主要用於服務內數據流轉，好比批量短信發送。

解耦：項目尹始，並不能肯定具體需求，消息隊列能夠做爲一個接口層，解耦重要的業務流程，只須要遵照約定，針對數據編程便可獲取擴展能力。

冗餘：消息數據可以採用一對多的方式，供多個毫無關聯的業務使用。

健壯性：消息隊列能夠堆積請求，因此消費端業務即便短期死掉，也不會影響主要業務的正常進行。

消息系統要求

消息系統即然這麼重要，那麼除了可以保證高可用，對它自己的特性也有較高需求。大致有下面幾點：

性能要高：包含消息投遞和消息消費，都要快，通常經過增長分片數獲取並行處理能力。

消息要可靠：在某些場景，不能丟消息。生產、消費、MQ端都不能丟消息，通常經過增長副本，強制刷盤來解決。

擴展性要好：可以陪你把項目作大，陪你到天荒地老，增長節點集羣增大後，不能下降性能。

生態成熟：監控、運維、多語言支持、社區的活躍。

基本功能

Kafka是一個分佈式消息(存儲）系統。分佈式系統經過分片增長並行度，經過副本增長可靠性，kafka也不例外。咱們來看一下它的結構，順便解釋一下其中的術語。

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

負責往KAFKA寫入數據的組件就叫作Producer，消息的生產者通常寫在業務系統裏。

發送到KAFKA的消息可能有多種，如何區別其分類？就是Topic的概念，一個主題分佈式化後，可能會存在多個Broker上。

將Topic拆成多個段，增長並行度後，拆成的每一個部分叫作Partition，分區通常平均分佈在全部機器上。

那些消費Kafka中數據的應用程序，就叫作Consumer，咱們給某個主題的某個消費業務起一個名字，這麼名字就叫作Consumer Group。

擴展功能

Connector 鏈接器Task，包含Source和Sink兩種接口，給用戶提供了自定義數據流轉的可能，好比從JDBC導入到Kafka，或者將Kafka數據直接落地到DB。

Stream 相似於Spark Stream，可以進行流數據處理。但它自己沒有集羣，只是在KAFKA集羣上的抽象。若是你想要實時的流處理，且不須要Hadoop生態的某些東西，那麼這個比較適合你。Java架構交流學習圈：87481116八、面向1-3年經驗、Java開發人員、幫助突破瓶頸 提高思惟能力

咱們的消息就是寫在主題裏。有了多個Topic，就能夠對消息進行歸類與隔離，好比登陸信息寫在user_activity_topic，日誌消息寫在log_topic中。

每個topic均可以調整其分區數量。假設咱們的集羣有三個Broker，那麼當分區數量爲1的時候，消息就僅寫在其中一個節點上；當咱們的分區爲3，消息會根據hash寫到三個節點上；當咱們的分區爲6，那每一個節點將會有2個分區信息。增長分區能夠增長並行度，但不是越多越好。通常，6-12最佳，最好可以被節點數整除，避免數據傾斜。

每一個分區都由一系列有序的、不可變的消息組成，這些消息被順序的追加。分區中的每一個消息都有一個連續的序列號叫作offset。Kafka將保留配置時間內的全部消息，因此它也是一個臨時存儲。在這段時間內，全部的消息均可被消費，而且能夠經過改變offset的值進行重複、屢次消費。

Offset通常由消費者管理，固然也能夠經過程序按須要設置。Offset只有commit之後，纔會改變，不然，你將一直獲取重複的數據。新的kafka已經將這些Offset的放到了一個專有的主題：__consumer_offsets，就是上圖的紫色區域。

值得一提的是，消費者的個數，不要超過度區的個數。不然，多出來的消費者，將接收不到任何數據。

ISR

分佈式系統保證數據可靠性的一個經常使用手段就是增長副本個數，ISR就是創建在這個手段上。

ISR全稱"In-Sync Replicas"，是保證HA和一致性的重要機制。副本數對Kafka的吞吐率是有必定的影響，但極大的加強了可用性。通常2-3個爲宜。

副本有兩個要素，一個是數量要夠多，一個是不要落在同一個實例上。ISR是針對與Partition的，每一個分區都有一個同步列表。N個replicas中，其中一個replica爲leader，其餘都爲follower, leader處理partition的全部讀寫請求，其餘的都是備份。與此同時，follower會被動按期地去複製leader上的數據。

若是一個flower比一個leader落後太多，或者超過必定時間未發起數據複製請求，則leader將其重ISR中移除。

當ISR中全部Replica都向Leader發送ACK時，leader才commit。

Kafka的ISR的管理最終都會反饋到Zookeeper節點上。具體位置爲：/brokers/topics/[topic]/partitions/[partition]/state。當Leader節點失效，也會依賴Zk進行新的Leader選舉。Offset轉移到Kafka內部的Topic之後，KAFKA對ZK的依賴就愈來愈小了。

可靠性

消息投遞語義

At least once

可能會丟消息，但不不會重複

At most once

不不丟消息，但可能重複，因此消費端要作冪等

Exactly once

消息不不會丟，且保證只投遞⼀一次

總體的消息投遞語義須要Producer端和Consumer端二者來保證。KAFKA默認是At most once，也能夠經過配置事務達到Exactly once，但效率很低，不推薦。

ACK

當生產者向leader發送數據時，能夠經過request.required.acks參數來設置數據可靠性的級別：

1（默認） 數據發送到Kafka後，通過leader成功接收消息的的確認，就算是發送成功了。在這種狀況下，若是leader宕機了，則會丟失數據。

0 生產者將數據發送出去就無論了，不去等待任何返回。這種狀況下數據傳輸效率最高，可是數據可靠性確是最低的。

-1 producer須要等待ISR中的全部follower都確認接收到數據後纔算一次發送完成，可靠性最高。

KAFKA爲何快

Cache：Filesystem Cache PageCache緩存

順序寫：因爲現代的操做系統提供了預讀和寫技術，磁盤的順序寫大多數狀況下比隨機寫內存還要快。

Zero-copy：零拷⻉，少了一次內存交換。

Batching of Messages：批量量處理。合併小的請求，而後以流的方式進行交互，直頂網絡上限。

Pull 拉模式：使用拉模式進行消息的獲取消費，與消費端處理能力相符。

使用場景

1.傳遞業務消息

2.用戶活動日誌 • 監控項等

3.日誌

4.流處理，好比某些聚合

5.Commit Log，做爲某些重要業務的冗餘

6.針對當前互聯網公司的技術需求以及結合主流技術，我整理了一份系統的架構技術體系，但願對在提高進階的程序員們有所幫助。你們能夠進羣Java資源分享羣：（854601507）下載資料，羣裏有阿里大牛，也有一線互聯網的資深HR，或是關注微信公衆號：Java資訊庫，免費領取架構資料。

下面是一個日誌方面的典型使用場景。

壓測

KAFKA自帶壓測工具，以下：

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

--producer.config ../config/producer.properties

配置管理

關注點

應用場景：不一樣的應用場景有不同的配置策略和不同的SLA服務水準。須要搞清楚本身的消息是否容許丟失或者重複，而後設定相應的副本數量和ACK模式。

Lag：要時刻注意消息的積壓。Lag過高意味着處理能力有問題。若是在低峯時候你的消息有積壓，那麼當大流量到來，必然會出問題。

擴容：擴容後會涉及到partition的從新分佈，你的網絡帶寬可能會是瓶頸。

磁盤滿了：建議設置過時天數，或者設置磁盤最大使用量。

log.retention.bytes

過時刪除：磁盤空間是有限的，建議保留最近的記錄，其他自動刪除。

log.retention.hours

log.retention.minutes

log.retention.ms 

監控管理工具

KafkaManager：雅虎出品，可管理多個Kafka集羣，是目前功能最全的管理工具。可是注意，當你的Topic太多，監控數據會佔用你大量的帶寬，形成你的機器負載增高。其監控功能偏弱，不知足需求。

KafkaOffsetMonitor：程序一個jar包的形式運行，部署較爲方便。只有監控功能，使用起來也較爲安全。

Kafka Web Console：監控功能較爲全面，能夠預覽消息，監控Offset、Lag等信息，不建議在生產環境中使用。

Burrow：是LinkedIn開源的一款專門監控consumer lag的框架。支持報警，只提供HTTP接口，沒有webui。

Availability Monitor for Kafka：微軟開源的Kafka可用性、延遲性的監控框架,提供JMX接口，用的不多。

Rebalance

消費端Rebalance

消費端的上線下線會形成分區與消費者的關係從新分配，形成Rebalance。業務會發生超時、抖動等。

服務端reassign

服務器擴容、縮容，節點啓動、關閉，會形成數據的傾斜，須要對partition進行reassign。在kafka manager後臺能夠手動觸發這個過程，使得分區的分佈更加平均。

這個過程會形成集羣間大量的數據拷貝，當你的集羣數據量大，這個過程會持續數個小時或者幾天，謹慎操做。

linkedin開源了其自動化管理工具cruise-control，有自動化運維需求的不妨一看。

結尾

本文是KAFKA相關的最基礎的知識，基本涵蓋了大部分簡單的面試題。

爲了達到Exactly once這個語義，KAFKA作了不少努力，努力的結果就是幾乎不可用，吞吐量實在是過低了。若是你真要將「高可靠」掛在嘴上，不如作好「補償策略」。性能不成，最終的結果多是總體不可用；而數據丟失，僅是極端狀況下的一部分小數據而已。你會如何權衡呢？

大流量下的KAFKA是很是嚇人的，數據常常將網卡打滿。而一旦Broker當機，若是單節點有上T的數據，光啓動就須要半個小時，它還要做爲Follower去追趕其餘Master分區的數據。因此，不要讓你的KAFKA集羣太大，故障恢復會是一場災難。啓動之後，若是執行reassign，又會是另外一番折騰了。

原文出處：https://www.jianshu.com/p/abc10b7275d7