Apache Kafka最佳化部署的十大最佳實踐

1. 設定日誌配置引數以保持日誌可管理
2. 瞭解Kafka的（低）硬體要求
3. 充分利用Apache ZooKeeper
4. 以正確的方式設定複製和冗餘
5. 注意主題配置
6. 使用並行處理
7. 在考慮安全性的情況下配置和隔離Kafka
8. 透過提升Ulimit避免中斷
9. 保持較低的網路延遲
10. 利用有效的監控和警報

設定日誌配置引數以保持日誌可管理

Kafka為使用者提供了大量日誌配置選項，雖然預設設定合理，但根據您的特定需求自定義日誌行為將確保它們不會長期成為管理挑戰。

這包括設定日誌保留策略，清理，壓縮和壓縮活動。可以使用log.segment.bytes，log.segment.ms和log.cleanup.policy（或主題級別等效）引數來控制日誌行為。

如果在你不需要歷史日誌，可以透過將cleanup.policy設定為“delete”來讓Kafka刪除特定檔案大小的日誌檔案或在一段設定的時間後刪除；或在需要時保留日誌還可以將其設定為“compact” 。重要的是要了解執行日誌清理會消耗CPU和RAM資源，一定要平衡壓縮的頻率和維持效能的需要。

壓縮是Kafka確保至少保留每個訊息金鑰的最後已知值（在單個主題分割槽的資料日誌內）的過程。壓縮操作適用於主題中的每個鍵，以保留其最後一個值，清除所有其他重複項。在刪除的情況下，金鑰留有'null'值（它表示為'tombstone'，因為它表示，五顏六色，刪除）。 

瞭解Kafka的（低）硬體要求

雖然許多不熟悉Kafka的團隊會高估其硬體需求，但該解決方案實際上具有較低的開銷和橫向擴充套件友好的設計。這使得可以使用廉價的商品硬體並且仍然非常成功地執行Kafka：

• CPU：除非需要SSL和日誌壓縮，否則Kafka不需要功能強大的CPU。此外，使用的核心越多，並行化就越好。在大多數情況下，壓縮不是一個因素，應使用LZ4編解碼器來提供最佳效能。

• RAM：在大多數情況下，Kafka可以使用6 GB的RAM以最佳方式執行堆空間。對於特別重的生產負載，請使用32 GB或更高的機器。額外的RAM將用於支援OS頁面快取並提高客戶端吞吐量。雖然Kafka可以使用較少的RAM執行，但是當可用記憶體較少時，其處理負載的能力受到阻礙。

• 磁碟：在RAID設定中使用多個驅動器時，Kafka蓬勃發展。由於Kafka的順序磁碟I / O範例，SSD不具備很多優勢，因此不應使用NAS。

• 網路和檔案系統：建議使用XFS，如果情況允許，則將群集保留在單個資料中心。此外，提供儘可能多的網路頻寬。

充分利用Apache ZooKeeper
Apache ZooKeeper叢集是執行Kafka的關鍵依賴項。但是當與Kafka一起使用ZooKeeper時，需要記住一些重要的最佳實踐。ZooKeeper節點的數量應最多為5。1個節點適用於開發環境，3個節點足以滿足大多數生產Kafka叢集的需求。

雖然大型Kafka部署可能需要5個ZooKeeper節點來減少延遲，但必須考慮節點上的負載。有7個或更多節點同步並處理請求，負載變得巨大，效能可能會受到顯著影響。

另請注意，最近版本的Kafka對Zookeeper的負載比早期版本低得多，後者使用Zookeeper來儲存消費者偏移。最後，正如Kafka的硬體需求一樣，為ZooKeeper提供最強大的網路頻寬。使用最好的磁碟，分別儲存日誌，隔離ZooKeeper程式和禁用交換也可以減少延遲。下表突出顯示了在不同Kafka版本中依賴於Zookeeper的一些控制檯操作。早期版本0.8.0在適當的管理意味著Kafka部署的彈性。

一個重要的做法是將Kafka的預設複製因子從2增加到3，這在大多數生產環境中都是合適的。

這樣做可以確保一個代理的丟失不會引起關注，即使不太可能丟失兩個代理也不會中斷可用性。

另一個考慮因素是資料中心機架區。例如，如果使用AWS，Kafka伺服器應該位於同一區域，但利用多個可用區域來實現冗餘和彈性。以正確的方式設定複製和冗餘要考慮機架rack部署的Kafka配置引數是：broker.rack=rack-id如Apache Kafka 文件中所述：建立主題，重新分配修改或副本時，將遵循機架rack約束，確保副本儘可能多地複製到rack機架（分割槽將跨越 min(racks，複製因子) 不同的機架）。

 注意主題Topic配置
主題配置對Kafka叢集的效能產生巨大影響。由於對複製因子或分割槽計數等設定的更改可能具有挑戰性，因此您需要在第一次時以正確的方式設定這些配置，然後在需要更改時簡單地建立新主題（在臨時環境中測試新主題）。

使用複製因子為3，並對處理大型訊息時要周到。

如果可能，將大型訊息分解為有序的部分，或者僅使用指向資料的指標（例如指向S3的連結）。如果這些方法不是選項，請在生產者端啟用壓縮。預設日誌段大小為1 GB，如果您的訊息較大，則應該仔細檢視用例。

分割槽計數也是一個至關重要的設定，將在下一節中詳細討論。

主題配置具有“伺服器預設”屬性。這些可以在主題建立時或稍後的時間被覆蓋，以便具有特定於主題的配置。如上所述，最重要的配置之一是複製因子。該示例演示了從控制檯建立主題的複製因子為三個和三個分割槽以及其他“主題級別”配置：

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 

使用並行處理
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
確保Kafka部署的兩個主要問題是：
1）Kafka的內部配置，
2）Kafka執行的基礎設施。

Kafka的.9版本中包含許多有價值的安全功能，例如Kafka /客戶端和Kafka / ZooKeeper身份驗證支援，以及TLS支援以保護具有公共Internet客戶端的系統。

雖然TLS確實為吞吐量和效能帶來了成本，但它有效且有價值地隔離並保護了Kafka經紀商的流量。隔離Kafka和ZooKeeper對安全至關重要。除了極少數情況，ZooKeeper永遠不應該連線到公共網際網路，並且只應與Kafka（或其他用於其的解決方案）進行通訊。防火牆和安全組應該隔離Kafka和ZooKeeper，而代理駐留在拒絕外部連線的單個專用網路中。中介軟體或負載平衡層應該使Kafka與公共Internet客戶端隔離。Kafka的安全選項和協議：

• SSL / SASL：對經紀人，經紀人，經紀人和工具的客戶認證。
• SSL：客戶端與代理之間，代理與工具之間的資料加密
• SASL型別：SASL / GSSAPI（Kerberos），SASL / PLAIN，SASL / SCRAM-SHA-512 / SCRAM-SHA-256，SASL_AUTHBEARER
• Zookeeper安全性：客戶端（經紀人，工具，生產者，消費者）的身份驗證，使用ACL進行授權。

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]";

透過提升Ulimit避免中斷

這種情況經常發生：經紀人經常會因為負載太大而當機，但實際上是一種良性（儘管仍然有壓力）“太多開啟檔案”錯誤。

透過編輯/etc/sysctl.conf並配置Ulimit以允許128,000或更多開啟的檔案，您可以避免發生此錯誤。增加CentOS上的ulimit的一個例子：

1. 建立一個新檔案 /etc/security/limits.d/nofile.conf

1. 輸入內容：

1. 重新啟動系統或重新登入。

1. 透過發出以下命令驗證。

保持較低的網路延遲
為了實現Kafka部署的低延遲，請確保代理在地理位置最靠近客戶端的區域，並確保在選擇雲提供商提供的例項型別時考慮網路效能。如果頻寬阻礙了你，那麼更大更強大的伺服器可能是值得的投資。

利用有效的監控和警報
按照上述做法，在建立Kafka群集時可以避開許多問題，但是您仍然需要保持警惕，以便在問題出現之前認識並妥善解決任何打嗝問題。監控系統指標（如網路吞吐量，開啟檔案控制程式碼，記憶體，負載，磁碟使用情況和其他因素）至關重要，因為要密切關注JVM統計資訊，包括GC暫停和堆使用情況。能夠加速除錯過程的儀表板和歷史工具可以提供很多價值。同時，應該配置Nagios或PagerDuty等警報系統，以便在出現延遲峰值或磁碟空間不足等症狀時發出警告，以便在問題出現之前解決小問題。