摘要:一些觀念的修正從版本開始,的標語已經從一個高吞吐量,分布式的消息系統改為一個分布式流平臺。不僅用在吞吐量高的大數據場景,也可以用在有事務要求的業務系統上,但性能較低。消息系統的作用削峰用于承接超出業務系統處理能力的請求,使業務平穩運行。
我們在《360度測試:KAFKA會丟數據么?其高可用是否滿足需求?》這篇文章中,詳細說明了KAFKA是否適合用在業務系統中。但有些朋友,還不知道KAFKA為何物,以及它為何存在。這在工作和面試中是比較吃虧的,因為不知道什么時候起,KAFKA似乎成了一種工程師的必備技能。
一些觀念的修正從 0.9 版本開始,Kafka 的標語已經從“一個高吞吐量,分布式的消息系統”改為"一個分布式流平臺"。
Kafka不僅僅是一個隊列,而且是一個存儲,有超強的堆積能力。
Kafka不僅用在吞吐量高的大數據場景,也可以用在有事務要求的業務系統上,但性能較低。
Kafka不是Topic越多越好,由于其設計原理,在數量達到閾值后,其性能和Topic數量成反比。
引入了消息隊列,就等于引入了異步,不管你是出于什么目的。這通常意味著業務流程的改變,甚至產品體驗的變更。
消息系統是什么 典型場景
上圖是一些小系統的典型架構。考慮訂單的業務場景,有大量的請求指向我們的業務系統,如果直接經過復雜的業務邏輯進入業務表,將會有大量請求超時失敗。所以我們加入了一張中間緩沖表(或者Redis),用來承接用戶的請求。然后,有一個定時任務,不斷的從緩沖表中獲取數據,進行真正的業務邏輯處理。
這種設計有以下幾個問題:
定時任務的輪詢間隔不好控制。業務處理容易延遲。
無法橫向擴容處理能力,且會引入分布式鎖、順序性保證等問題。
當其他業務也需要這些訂單數據的時候,業務邏輯就必須要加入到定時任務里。
當訪問量增加、業務邏輯復雜化的時候,消息隊列就呼之欲出了。
請求會暫存在消息隊列,然后實時通過推(或者拉)的方式進行處理。
在此場景下,消息隊列充當了削峰和冗余的組件。
削峰 用于承接超出業務系統處理能力的請求,使業務平穩運行。這能夠大量節約成本,比如某些秒殺活動,并不是針對峰值設計容量。
緩沖 在服務層和緩慢的落地層作為緩沖層存在,作用與削峰類似,但主要用于服務內數據流轉。比如批量短信發送。
解耦 項目尹始,并不能確定具體需求。消息隊列可以作為一個接口層,解耦重要的業務流程。只需要遵守約定,針對數據編程即可獲取擴展能力。
冗余 消息數據能夠采用一對多的方式,供多個毫無關聯的業務使用。
健壯性 消息隊列可以堆積請求,所以消費端業務即使短時間死掉,也不會影響主要業務的正常進行。
消息系統要求消息系統即然這么重要,那么除了能夠保證高可用,對它本身的特性也有較高需求。大體有下面幾點:
性能要高 包含消息投遞和消息消費,都要快。一般通過增加分片數獲取并行處理能力。
消息要可靠 在某些場景,不能丟消息。生產、消費、MQ端都不能丟消息。一般通過增加副本,強制刷盤來解決。
擴展性要好 能夠陪你把項目做大,陪你到天荒地老。增加節點集群增大后,不能降低性能。
生態成熟 監控、運維、多語言支持、社區的活躍。
KAFKA名詞解釋 基本功能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生態的某些東西,那么這個比較適合你。
Topic我們的消息就是寫在主題里。有了多個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 拉模式 使用拉模式進行消息的獲取消費,與消費端處理能力相符。
使用場景傳遞業務消息
用戶活動日志 ? 監控項等
日志
流處理,比如某些聚合
Commit Log,作為某些重要業務的冗余
下面是一個日志方面的典型使用場景。
壓測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,又會是另一番折騰了。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/72745.html
閱讀 2672·2019-08-30 15:55
閱讀 1804·2019-08-30 15:53
閱讀 2656·2019-08-29 18:38
閱讀 928·2019-08-26 13:49
閱讀 502·2019-08-23 15:42
閱讀 3114·2019-08-22 16:33
閱讀 1004·2019-08-21 17:59
閱讀 1083·2019-08-21 17:11