Kafka最佳實踐

 

1、硬件考量

1.一、內存

不建議爲kafka分配超過5g的heap，由於會消耗28-30g的文件系統緩存，而是考慮爲kafka的讀寫預留充足的buffer。Buffer大小的快速計算方法是平均磁盤寫入數量的30倍。推薦使用64GB及以上內存的服務器，低於32GB內存的機器可能會拔苗助長，致使不斷依賴堆積機器來應付需求增加。（咱們在生產環境使用的機器是64G內存的，但也看到LinkedIn用了大量28G內存的服務器。）

1.二、CPU

kafka不算是CPU消耗型服務，在主頻和CPU核數之間，選擇後者，將會得到多核帶來的更好的併發處理性能。

1.三、磁盤

毋庸置疑，RAID是優先推薦的，它在底層實現了物理磁盤的負載均衡和冗餘，雖然會犧牲一些磁盤空間和寫入性能。更進一步，咱們推薦在配置中使用多目錄，每一個目錄掛在在不一樣的磁盤（或者RAID）上。須要注意的是，NAS是不可取的，不管供應商如何吹噓他們的NAS的卓越性能。另外，咱們常常看到用戶諮詢kafka是否必定要採用SSD，答案是沒有必要。

1.4網絡

分佈式系統中，網絡的速度和可靠性異常重要，千兆甚至萬兆網絡如今應該成爲數據中心的標配。避免kafka集羣出現跨數據中心的狀況，更要避免有很大的物理空間跨度，尤爲中國還有詭異的聯通電信問題。kafka集羣中各個節點地位均等，一旦由於延時致使分佈式集羣不穩定，排錯尤爲困難。

1.五、文件系統

ext4是最佳選擇。

1.六、其它

在硬件愈來愈強大和雲計算如火如荼的今天，你須要在超高配置的服務器和IaaS供應商的數百個虛擬機之間作取捨。咱們建議使用中等配置的服務器，由於集羣規模越大，單臺超高配置的服務器運行的節點越多，集羣穩定性隨之降低，複雜度則會上升。

2、JVM的考慮

對於java應用，jvm和gc是繞不過去的坎。實踐代表，官方JDK1.7u51會是一個不錯的選擇，配合以G1來作垃圾回收。推薦配置可參考：

-Xms4g -Xmx4g -XX:PermSize=48m -XX:MaxPermSize=48m -XX:+UseG1GC-XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35

注：kafka版本更新會帶來變化。請隨時關注。咱們如今的版本是kafka_2.11-0.8.2.1

3、File descriptors

kafka會使用大量文件和網絡socket，因此，咱們須要把file descriptors的默認配置改成100000。修改方法以下：

#vi /etc/sysctl.conf

fs.file-max = 32000

#vi /etc/security/limits.conf

yourusersoftnofile10000

youruserhardnofile30000

4、關鍵配置項解讀

儘管默認配置已經很不錯，但出於性能和實際集羣部署狀況，咱們仍是須要講解一些重要的配置項。除此以外，若是對某個默認參數存在質疑，在詳細瞭解改參數的做用前，建議採用默認配置。

4.一、zookeeper.connect

必配參數，建議在kafka集羣的天天機器都配置全部zk。

4.二、broker.id

必配參數。集羣節點的標示符，不得重複。取值範圍0~n。

4.三、log.dirs

建議參照文章前面描述的磁盤配置，不要使用默認的「/tmp/kafka-logs」

4.四、advertised.host.name

註冊到zk供用戶使用的主機名。內網環境一般無需配置，而IaaS通常須要配置爲公網地址。默認爲「host.name」，能夠經過java.net.InetAddress.getCanonicalHostName()接口獲取該值。

4.五、advertised.port

註冊到zk供用戶使用的服務端口，一般在IaaS環境須要額外配置。

4.六、num.partitions

自動建立topic的默認partition數量。默認是1，爲了得到更好的性能，建議修改成更大。最優取值參考後文。

4.七、default.replication.factor

自動建立topic的默認副本數量，官方建議修改成2；但一般一個副本就足夠了。

4.八、min.insync.replicas

ISR提交生成者請求的最小副本數。

4.九、unclean.leader.election.enable

是否容許不具有ISR資格的replicas選舉爲leader做爲不得已的措施，甚至不惜犧牲部分數據。默認容許。建議容許。數據異常重要的狀況例外。

4.十、controlled.shutdown.enable

在kafka收到stop命令或者異常終止時，容許自動同步數據。建議開啓。

5、動態調整配置

大部分kafka配置是寫死在properties文件裏的。然而，許多關於topic的參數咱們能夠動態調配，kafka-topic.sh工具提供了該功能，更改將一直生效直到服務器重啓。能夠調整的參數以下：

unclean.leader.election.enable：不嚴格的leader選舉，有助於集羣健壯，可是存在數據丟失風險。

min.insync.replicas：若是同步狀態的副本小於該值，服務器將再也不接受request.required.acks爲-1或all的寫入請求。

max.message.bytes：單條消息的最大長度。若是修改了該值，那麼replica.fetch.max.bytes和消費者的fetch.message.max.bytes也要跟着修改。

cleanup.policy：生命週期終結數據的處理，默認刪除。

flush.messages：強制刷新寫入的最大緩存消息數。

flust.ms：強制刷新寫入的最大等待時長。

還有segment.bytes、segment.ms、retention.bytes、retention.ms和segment.jitter.ms。詳見官方解釋。

6、性能優化技巧

6.一、配置合適的partitons數量。

這彷佛是kafka新手必問得問題。首先，咱們必須理解，partiton是kafka的並行單元。從producer和broker的視角看，向不一樣的partition寫入是徹底並行的；而對於consumer，併發數徹底取決於partition的數量，即，若是consumer數量大於partition數量，則必有consumer閒置。因此，咱們能夠認爲kafka的吞吐與partition時線性關係。partition的數量要根據吞吐來推斷，假定p表明生產者寫入單個partition的最大吞吐，c表明消費者從單個partition消費的最大吞吐，咱們的目標吞吐是t，那麼partition的數量應該是t/p和t/c中較大的那一個。實際狀況中，p的影響因素有批處理的規模，壓縮算法，確認機制和副本數等，然而，屢次benchmark的結果代表，單個partition的最大寫入吞吐在10MB/sec左右；c的影響因素是邏輯算法，須要在不一樣場景下實測得出。

這個結論彷佛太書生氣和不實用。咱們一般建議partition的數量必定要大於等於消費者的數量來實現最大併發。官方曾測試過1萬個partition的狀況，因此不須要太擔憂partition過多的問題。下面的知識會有助於讀者在生產環境作出最佳的選擇：

a、一個partition就是一個存儲kafka-log的目錄。

b、一個partition只能寄宿在一個broker上。

c、單個partition是能夠實現消息的順序寫入的。

d、單個partition只能被單個消費者進程消費，與該消費者所屬於的消費組無關。這樣作，有助於實現順序消費。

e、單個消費者進程可同時消費多個partition，即partition限制了消費端的併發能力。

f、partition越多則file和memory消耗越大，要在服務器承受服務器設置。

g、每一個partition信息都存在全部的zk節點中。

h、partition越多則失敗選舉耗時越長。

k、offset是對每一個partition而言的，partition越多，查詢offset就越耗時。

i、partition的數量是能夠動態增長的（只能加不能減）。

咱們建議的作法是，若是是3個broker的集羣，有5個消費者，那麼建議partition的數量是15，也就是broker和consumer數量的最小公倍數。固然，也能夠是一個大於消費者的broker數量的倍數，好比6或者9，還請讀者自行根據實際環境裁定。

 

本文摘自：http://www.jianshu.com/p/8689901720fd