Apache Kafka 確定會像它的同名小說家同樣不負衆望，由於它能激奮新來者、挑戰深度，若能更全面的理解它還會產生豐厚的回報。拋開文學，書歸正傳。遵循 kafka 最新的最佳實踐，必定可讓這個強大的數據流平臺的管理變得很是、很是容易，並且還會至關有效。mysql
這裏有 10 個具體的技巧，能夠幫助您優化 Kafka 部署並更容易管理：ios
設置日誌配置參數以使日誌易於管理sql
瞭解 kafka 的 (低) 硬件需求apache
充分利用 Apache ZooKeeper緩存
以正確的方式設置複製和冗餘安全
注意主題配置服務器
使用並行處理微信
帶着安全性思惟配置和隔離 Kafka網絡
經過提升限制避免停機app
保持低網絡延遲
利用有效的監控和警報
讓咱們詳細分析一下這些最佳實踐。
Kafka 爲用戶提供了大量的日誌配置選項，雖然默認設置是合理的，但定製日誌行爲以知足您的特定需求將確保它們不會成爲長期的管理挑戰。這包括設置日誌保留策略、清理、壓縮和壓縮活動。
可使用 Log.segment.bytes、log.segment.ms、log.cleanup.policy (或主題級等價參數) 來控制日誌行爲。若是在應用場景中您不須要之前的日誌，那麼您可使用 Kafka 刪除某個文件大小的日誌文件，或者經過設置 cleanup.policy 在一段時間以後再「刪除」。您還能夠將其設置爲「compact」，以便在須要時保留日誌。注意，要了解運行日誌清理會消耗 CPU 和 RAM 資源；在將 Kafka 用於任什麼時候間長度的操做日誌時，必定要平衡壓縮的頻率和維持性能的須要。
壓縮是 Kafka 確保每一個消息鍵 (在單個主題分區的數據日誌中) 至少保留最後一個已知值的過程。壓縮操做處理主題中的每一個鍵，以保留其最後的值，清理全部其餘重複項。在刪除的狀況下，該 鍵保存成「null」值 (它被稱爲「墓碑（tombstone）」，由於它能生動地表示已刪除)。
圖 1 Kafka 提交日誌壓縮過程
請參考 Kafka 操做日誌文檔：
日誌：
https://kafka.apache.org/documentation/#log
壓縮基礎知識：
https://kafka.apache.org/documentation/#design_compactionbasics
雖然許多不熟悉 Kafka 的團隊會高估它的硬件需求，但其實這個解決方案的設計初衷是低開銷和友好地水平擴展。這使得使用廉價的商品硬件並仍能夠保持成功運行 Kafka 成爲可能：
CPU：除非須要 SSL 和日誌壓縮，不然 Kafka 不須要強大的 CPU。並且，使用的內核越多，並行性越好。並且在大多數狀況下，壓縮也不會產生影響，應該使用 LZ4 編解碼器來提供最佳性能。
RAM：在大多數狀況下，Kafka 能夠以 6 GB 的內存運行堆空間。對於特別重的生產負載，使用 32 GB 以上的機器。額外的 RAM 將用於支持 OS 頁面緩存和提升客戶端吞吐量。雖然 Kafka 能夠以更少的 RAM 運行，但當可用的內存較少時，它處理負載的能力就會受到限制。
磁盤：若是在 RAID 設置中使用多個驅動器，就該 Kafka 大顯身手了。因爲 Kafka 的順序磁盤 I/O 範式，因此 SSD 不會提供太多的優點，不該該使用 NAS。
網絡和文件系統：建議使用 XFS，若是條件容許，還能夠將集羣放在單個數據中心。同時，應儘量提供更多的網絡帶寬。
Apache Kafka 網站還包含一個專門的硬件和操做系統配置部分，提供了有價值的建議。
關於 Kafka 負載 / 性能測試的其餘有價值的連接：
Apache Kafka 的基準測試：每秒 200 萬次寫 (在 3 臺廉價的機器上)
https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
在 AWS 上的 Apache Kafka 負載測試
https://grey-boundary.io/load-testing-apache-kafka-on-aws/
性能測試
https://cwiki.apache.org/confluence/display/KAFKA/Performance+testing
Apache ZooKeeper 集羣的運行是 Kafka 運行的關鍵依賴項。可是當你在 kafka 旁邊使用 ZooKeeper 的時候，必定要記住一些重要的最佳實踐。
ZooKeeper 節點的數量最大應該是五個。一個節點適合於開發環境，三個節點對於大多數產品 Kafka 集羣來講就足夠了。雖然一個大型 Kafka 環境可能須要五個 ZooKeeper 節點來減小延遲，可是必須考慮節點上的負載。若是有七個或更多節點同步並處理請求，負載將變得很是大，性能可能會受到明顯的影響。還須要注意的是，與早期版本相比，近期版本的 Kafka 對 Zookeeper 的負載要低得多，早期版本使用 Zookeeper 來存儲消費者偏移。
最後一點，就像 Kafka 的硬件需求同樣，爲 ZooKeeper 提供最強大的網絡帶寬。使用最好的磁盤、分別存儲日誌、隔離 ZooKeeper 進程、禁用交換，這些也會減小延遲。
下表重點顯示了不一樣 Kafka 版本中依賴於 Zookeeper 的一些控制檯操做。早期版本 0.8.0 在控制檯沒有提供不少功能。從 0.10.0.0 開始，咱們能夠看到一些主要功能與 Zookeeper 分離開了，這就下降了 Zookeeper 的使用率。
適當的管理意味着 kafka 部署的彈性。一個重要的實踐是將 Kafka 的默認複製因子從兩個增長到三個，這一條在大多數生產環境中都合適。這樣作能夠確保一個代理出現問題不要太要緊，甚至兩個代理都出問題了也不會中斷可用性，儘管這種狀況不太可能發生。另外一個須要考慮的問題是數據中心機架區域。例如，若是使用 AWS， Kafka 服務器應該位於同一個區域，可是利用多個可用性區域來實現冗餘和彈性。以正確的方式設置複製和冗餘。
機架部署要考慮的 Kafka 配置參數是：
broker.rack=rack-id
如 Apache Kafka 文檔所述：
當一個主題被建立、修改或複製被從新分發時，將遵照機架約束，確保複製可以跨儘量多的機架，分區將盡量分佈在不一樣的機架上，在此，機架即爲複製因子。
舉個例子：
假設，9 個 Kafka 代理 (B1-B9) 分佈在三個貨架上。
圖 2 帶有機架感知的 kafka 集羣
在這裏，一個具備三個分區 (P一、P二、P3) 和三個複製因子 (R一、R二、R3) 的單一主題將在每一個機架中爲一個節點分配一個分區。這個場景中每一個分區有兩個副本，以此提供高可用性，即便一個完整的機架發生故障 (如圖所示) 也能夠保持正常運行。
主題配置對 Kafka 集羣的性能有巨大的影響。由於更改設置 (如複製因子或分區計數) 可能很困難，因此您須要在第一次以正確的方式設置這些配置，而後在須要更改時簡單地建立一個新主題 (必定要在準生產環境中測試新主題)。
使用三個複製因子，並仔細思考大型消息的處理。若是可能的話，將大的消息分解成有序的塊，或者使用指向數據的指針 (好比指向 S3 的連接)。若是這些方法不可選，則在生產者一方啓用壓縮。默認的日誌段大小是 1 GB，若是您的消息更大，就應該仔細檢查一下用例了。分區計數也是一個很是重要的設置，將在下一節詳細討論。
主題配置有一個「服務器默認」屬性。能夠在主題建立時或稍後進行重寫，以便具備特定於主題的配置。
如上所述，最重要的配置之一是複製因子。如下例子演示了從控制檯建立主題的過程，複製因子爲 3 個分區和 3 個分區，以及其餘「主題級別」配置：
bin/kafka-topics.sh --zookeeper ip_addr_of_zookeeper：2181 --create --topic my-topic –partitions 3 --replication-factor 3 --config max.message.bytes=64000 --config flush.messages=1
有關主題級別配置的完整介紹，請參閱這裏的內容:
https://kafka.apache.org/documentation/#topicconfigs
Kafka 是爲並行處理而設計的，和並行操做自己同樣，充分利用它須要操做的平衡。分區計數是一個主題級設置，分區越多，並行性和吞吐量就越大。然而，分區也意味着更多的複製延遲、重平衡和打開服務器文件。
找到您的最佳分區設置很簡單，就像計算您但願爲您的硬件實現的吞吐量，而後計算所需的分區數量就能夠了。按照保守的估計，一個主題上的一個分區能夠傳遞 10 MB/s，根據這個估計能夠推斷出您須要的總吞吐量。另外一種直接進行測試的方法是對每一個主題使用一個代理，而後看看結果，若是須要更高的吞吐量，則將分區加倍。
總的來講，這裏有條規則值得一用：主題的總分區數要低於 10，集羣的總分區數要低於 10，000。若是您不這樣作，那麼需具備很高的監控能力，而且準備好處理可能很是具備挑戰性的重平衡和中斷!
建立 Kafka 主題時設置了分區的數量，以下所示。
bin/kafka-topics.sh --zookeeper ip_addr_of_zookeeper：2181 --create --topic my-topic –partitions 3 --replication-factor 3 --config max.message.bytes=64000 --config flush.messages=1
建立分區後能夠增長分區計數。但它會影響消費者，所以建議在處理完全部結果後再執行此操做。
bin/kafka-topics.sh --zookeeper zk_host：port/chroot --alter --topic topic_name –partitions new_number_of_partitions
確保 Kafka 部署的兩個主要關注點是 1)Kafka 的內部配置，2)Kafka 運行的基礎設施。
Kafka 的.9 版本包含了許多有價值的安全特性，例如 Kafka/client 和 Kafka/ZooKeeper 認證支持，以及對具備公共互聯網客戶端的保護系統的 TLS 支持。雖然 TLS 確實爲吞吐量和性能帶來了成本，但它有效且有價值地隔離並保護了 Kafka 代理的流量。
隔離 kafka 和 ZooKeeper 對安全相當重要。除極爲罕見的狀況以外，ZooKeeper 不該該鏈接到公共互聯網，而應該只與 kafka(或它所使用的其餘解決方案) 交互。防火牆和安全組應該隔離 Kafka 和 ZooKeeper，讓代理處於一個單獨的私有網絡中，拒絕外部鏈接。中間件或負載平衡層應該將 Kafka 與公共互聯網客戶端隔離。
Kafka 的安全選項和協議：
SSL/SASL：客戶端到代理、中介代理、代理到工具的身份驗證。
SSL：客戶端到代理之間、代理到代理之間和工具到代理之間的數據加密
SASL 類型：SASL/GSSAPI (Kerberos)， SASL/PLAIN
Zookeeper 安全性：爲客戶端 (代理、工具、生產者、消費者) 進行身份驗證，使用 ACL 進行受權。
Kafka 代理客戶端：生產者、消費者、其餘工具。
ZooKeeper 客戶：kafka 代理、生產者、消費者、其餘工具。
受權是可插拔的。
一個使用 SASL_SSL 進行安全設置的配置示例：
#Broker configuration listeners=SSL://host.name:port,SASL_SSL://host.name:port advertised.listeners=SSL://host.name:port,SASL_SSL://host.name:port security.protocol=SASL_SSL security.inter.broker.protocol=SSL listener.security.protocol.map=INTERBROKER\:SSL,PUBLIC_CLIENT\: SASL_PLAINTEXT,PRIVATE_CLIENT\:SASL_PLAINTEXT ssl.keystore.location=/var/private/ssl/server.keystore.jks ssl.keystore.password=test1234 ssl.key.password=test1234 ssl.truststore.location=/var/private/ssl/server.truststore.jks ssl.truststore.password=test1234 sasl.mechanism.inter.broker.protocol=PLAIN sasl.enabled.mechanisms=PLAIN #Client Configuration (jaas file) sasl.mechanism=PLAIN sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ username="[USER NAME]" password="[USER PASSWORD]";
一種常常發生的狀況是：代理看起來從過多的負載降下來了，但其實是一個 (儘管仍然有壓力)「打開的文件太多」的良性錯誤。編輯 /etc/sysctl.conf 文件，配置 Ulimit 以容許 128，000 或更多的打開文件，能夠避免發生這個錯誤。
增長 CentOS 上限的一個例子：
建立一個新的文件：/etc/security/limits.d/nofile.conf
輸入內容：
soft nofile 128000
hard nofile 128000
從新啓動系統或從新登陸。
經過如下命令來驗證：
ulimit - a
注意，有多種方法能夠增長 ulimit。您能夠按照任何適合您本身的 Linux 發行版的方法來修改。
爲了實現 Kafka 部署的低延遲，請確保代理位於離客戶端最近的區域，並在選擇雲提供商提供的實例類型時必定要考慮網絡性能。若是帶寬阻礙了您的發展，那麼可能就值得考慮投資一個更大更強力的服務器了。
在建立 Kafka 集羣時，按照上面的作法，您能夠在之後的工做中避免不少問題，可是您仍然須要保持警戒，在出現問題以前，提早正確識別和處理任何小問題。
監視系統指標 (如網絡吞吐量、打開的文件句柄、內存、負載、磁盤使用狀況和其餘因素) 是必不可少的，同時還要密切關注 JVM 統計數據，包括 GC 暫停和堆使用狀況。儀表板和歷史回溯工具可以加速調試過程，能夠提供大量的價值。與此同時，應該配置 Nagios 或 PagerDuty 等警報系統，以便在出現延遲峯值或磁盤空間不足等症狀時發出警告，從而在小問題如滾雪球般越滾越大以前就能解決。
經過 Instaclustr 控制檯中顯示的 Kafka 監控圖示例：
https://www.infoq.com/articles/apache-kafka-best-practices-to-optimize-your-deployment
推薦閱讀：
大數據基礎系列之kafka011生產者緩存超時，冪等性和事務實現
分享給你的小夥伴吧～
本文分享自微信公衆號 - 浪尖聊大數據（bigdatatip）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。