本文要點

• Kafka 低開銷和友好水平擴充套件的設計使它可以使用廉價的日用硬體仍能保持成功執行。

• 使用最好的磁碟、分別儲存日誌、隔離 ZooKeeper 程序，以及禁用交換以減少延遲，從而為 ZooKeeper 提供強大的網路頻寬。

• 將 Kafka 的預設複製因子從兩個增加到三個，這適用於大多數生產環境。

• 更多的分割槽意味著更好的並行化和吞吐量，但分割槽也意味著更多的複製延遲、平衡，以及開啟更多伺服器檔案。

• 監控系統網路吞吐量、開啟檔案控制代碼、記憶體、負載、磁碟使用情況等指標，以及像垃圾回收暫停和堆使用情況等 JVM 統計資料。

Apache Kafka 肯定會像它的同名小說家一樣不負眾望，因為它能激奮新來者、挑戰深度，若能更全面的理解它還會產生豐厚的回報。拋開文學，書歸正傳。遵循 kafka 最新的最佳實踐，一定可以讓這個強大的資料流平臺的管理變得非常、非常容易，而且還會相當有效。

這裡有 10 個具體的技巧，可以幫助您優化 Kafka 部署並更容易管理：

• 設定日誌配置引數以使日誌易於管理

• 瞭解 kafka 的 (低) 硬體需求

• 充分利用 Apache ZooKeeper

• 以正確的方式設定複製和冗餘

• 注意主題配置

• 使用並行處理

• 帶著安全性思維配置和隔離 Kafka

• 通過提高限制避免停機

• 保持低網路延遲

• 利用有效的監控和警報

讓我們詳細分析一下這些最佳實踐。

設定日誌配置引數以使日誌易於管理

Kafka 為使用者提供了大量的日誌配置選項，雖然預設設定是合理的，但定製日誌行為以滿足您的特定需求將確保它們不會成為長期的管理挑戰。這包括設定日誌保留策略、清理、壓縮和壓縮活動。

可以使用 Log.segment.bytes、log.segment.ms、log.cleanup.policy (或主題級等價引數) 來控制日誌行為。如果在應用場景中您不需要以前的日誌，那麼您可以使用 Kafka 刪除某個檔案大小的日誌檔案，或者通過設定 cleanup.policy 在一段時間之後再“刪除”。您還可以將其設定為“compact”，以便在需要時保留日誌。注意，要了解執行日誌清理會消耗 CPU 和 RAM 資源；在將 Kafka 用於任何時間長度的操作日誌時，一定要平衡壓縮的頻率和維持效能的需要。

壓縮是 Kafka 確保每個訊息鍵 (在單個主題分割槽的資料日誌中) 至少保留最後一個已知值的過程。壓縮操作處理主題中的每個鍵，以保留其最後的值，清理所有其他重複項。在刪除的情況下，該 鍵儲存成“null”值 (它被稱為“墓碑（tombstone）”，因為它能生動地表示已刪除)。

請參考 Kafka 操作日誌文件：

日誌

壓縮基礎知識

瞭解 kafka(低) 硬體需求

雖然許多不熟悉 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 臺廉價的機器上)

• 在 AWS 上的 Apache Kafka 負載測試

• 效能測試

充分利用 Apache ZooKeeper

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) 分佈在三個貨架上。

在這裡，一個具有三個分割槽 (P1、P2、P3) 和三個複製因子 (R1、R2、R3) 的單一主題將在每個機架中為一個節點分配一個分割槽。這個場景中每個分割槽有兩個副本，以此提供高可用性，即使一個完整的機架發生故障 (如圖所示) 也可以保持正常執行。

注意主題配置

主題配置對 Kafka 叢集的效能有巨大的影響。因為更改設定 (如複製因子或分割槽計數) 可能很困難，所以您需要在第一次以正確的方式設定這些配置，然後在需要更改時簡單地建立一個新主題 (一定要在準生產環境中測試新主題)。

使用三個複製因子，並仔細思考大型訊息的處理。如果可能的話，將大的訊息分解成有序的塊，或者使用指向資料的指標 (比如指向 S3 的連結)。如果這些方法不可選，則在生產者一方啟用壓縮。預設的日誌段大小是 1 GB，如果您的訊息更大，就應該仔細檢查一下用例了。分割槽計數也是一個非常重要的設定，將在下一節詳細討論。

主題配置有一個“伺服器預設”屬性。可以在主題建立時或稍後進行重寫，以便具有特定於主題的配置。

如上所述，最重要的配置之一是複製因子。以下例子演示了從控制檯建立主題的過程，複製因子為 3 個分割槽和 3 個分割槽，並配置吧其他“主題級別”配置：

有關主題級別配置的完整介紹，請參閱這裡的內容。

使用並行處理

Kafka 是為並行處理而設計的，和並行操作本身一樣，充分利用它需要操作的平衡。分割槽計數是一個主題級設定，分割槽越多，並行性和吞吐量就越大。然而，分割槽也意味著更多的複製延遲、重平衡和開啟伺服器檔案。

找到您的最佳分割槽設定很簡單，就像計算您希望為您的硬體實現的吞吐量，然後計算所需的分割槽數量就可以了。按照保守的估計，一個主題上的一個分割槽可以傳遞 10 MB/s，根據這個估計可以推斷出您需要的總吞吐量。另一種直接進行測試的方法是對每個主題使用一個代理，然後看看結果，如果需要更高的吞吐量，則將分割槽加倍。

總的來說，這裡有條規則值得一用：主題的總分割槽數要低於 10，叢集的總分割槽數要低於 10，000。如果您不這樣做，那麼需具有很高的監控能力，並且準備好處理可能非常具有挑戰性的重平衡和中斷!

建立 Kafka 主題時設定了分割槽的數量，如下所示。

建立分割槽後可以增加分割槽計數。但它會影響消費者，因此建議在處理完所有結果後再執行此操作。

出於安全性考慮配置和隔離 Kafka

確保 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 進行安全設定的配置示例：

通過提高 Ulimit 避免停機

一種經常發生的情況是：代理看起來從過多的負載降下來了，但實際上是一個 (儘管仍然有壓力)“開啟的檔案太多”的良性錯誤。編輯 /etc/sysctl.conf 檔案，配置 Ulimit 以允許 128，000 或更多的開啟檔案，可以避免發生這個錯誤。

增加 CentOS 上限的一個例子：

• 注意，有多種方法可以增加 ulimit。您可以按照任何適合您自己的 Linux 發行版的方法來修改。

保持低網路延遲

為了實現 Kafka 部署的低延遲，請確保代理位於離客戶端最近的區域，並在選擇雲提供商提供的例項型別時一定要考慮網路效能。如果頻寬阻礙了您的發展，那麼可能就值得考慮投資一個更大更強力的伺服器了。

利用有效的監控和警報

在建立 Kafka 叢集時，按照上面的做法，您可以在以後的工作中避免很多問題，但是您仍然需要保持警惕，在出現問題之前，提前正確識別和處理任何小問題。

監視系統指標 (如網路吞吐量、開啟的檔案控制代碼、記憶體、負載、磁碟使用情況和其他因素) 是必不可少的，同時還要密切關注 JVM 統計資料，包括 GC 暫停和堆使用情況。儀表板和歷史回溯工具能夠加速除錯過程，可以提供大量的價值。與此同時，應該配置 Nagios 或 PagerDuty 等警報系統，以便在出現延遲峰值或磁碟空間不足等症狀時發出警告，從而在小問題如滾雪球般越滾越大之前就能解決。

通過 Instaclustr 控制檯中顯示的 Kafka 監控圖示例：



轉載自：
https://mp.weixin.qq.com/s?__biz=MzA5MTc0NTMwNQ==&mid=2650716178&idx=1&sn=9f537e9ee81a30e08c70a0314cd60e80&chksm=887da564bf0a2c721d240859a3cf7705bdaaf387d600c9e041f758f57d9da9c1a1f923360dab&mpshare=1&scene=1&srcid=1220eNAddUO1ePke3ybAYuZl#rd