kafka 集群搭建鏈結
單個 kafka伺服器足以滿足本地開發或 poc要求，使用集群的最大好處是可以跨伺服器進行負載均衡，再則就是可以使用複製功能來避免因單點故障造成的資料丟失。在維護 kafka 或底層系統時，使用集群可以確保為客戶端提供高可用性。
乙個 kafka 需要多少個 broker取決於以下幾個因素：
需要多少磁碟空間來保留資料，以及單個broker 有多少空間可用。如果整個集群需要保留 10tb（每天2千萬的資料，夠用2年）的資料，每個 broker可以儲存 2tb，那麼至少需要 5個broker。如果啟用了複製，那麼至少還需要至少一倍的空間，不過還要取決於複製係數是多少。也就是說如果啟用了資料複製，那麼這個集群至少需要 10個 broker。
集群處理請求的能力。這通常與網路介面處理客戶端流量的能力有關，特別是當有多個消費者存在或者在資料保留期間流量發生波動（比如高峰時段流量爆發）時。如果單個 broker 的網路介面在高峰時段可以達到80%的使用量，並且有兩個消費者，那麼消費者就無法保持峰值。除非有兩個 broker。如果集群啟動了複製功能，則需要把額外的消費者考慮在內。因磁碟吞吐量低和系統記憶體不足造成的效能問題，也可以通過擴充套件多個 broker來解決。
要把乙個 broker 加入到集群裡，只需要修改兩個配置引數。首先，所有 broker都必須配置相同的zookeeper.connect該引數指定了用於儲存元資料的 zookeeper群組和路徑。其次，每個 broker 都必須為broker.id引數設定唯一的值。如果兩個 broker使用相同的 broker.id，那麼第二個 broker就無法啟動。在執行集群時，還可以配置其他一些引數，特別是那些用於控制資料複製的引數。
垃圾**器選項：j**a7 帶來的 g1垃圾**器，g1會自動根據工作負載情況進行自我調節，而且它的停頓時間是恆定的。它可以輕鬆地處理大塊的堆記憶體，把堆記憶體分為若干小塊的區域，每次停頓時並不會對這個堆空間進行**。g1只需要很少的配置就能完成這些工作。以下是 g1的兩個調整引數：
maxgcpausemillis：該引數指定每次垃圾**預設的停頓時間。該值不是固定的，g1可以根據需要使用更長的時間。它的預設值是200ms。也就是說，g1會決定垃圾**的頻率以及每一輪需要**多少個區域，這樣算下來，每一輪垃圾**大概需要200ms的時間。
initiatingheapoccupancypercent：該引數指定了在 g1啟動新一輪垃圾**之前可以使用的推記憶體百分比，預設值是45。也就是說，在堆記憶體的使用率達到45%之前，g1不會啟動垃圾**。這個百分比包括新生代和老年代的記憶體。
kafka 對堆記憶體的使用率非常高，容易產生垃圾物件，所以可以把這些值設定的小一些。如果一台伺服器有 64gb記憶體，並且使用 5gb來執行 kafka，那麼可以參考一下配置：maxgcpausemillis可以設定為20ms；initiatingheapoccupancypercent可以設定為35，這樣可以讓垃圾**比預設的要早一些啟動。kafka啟動指令碼並沒有啟用g1**器，而是使用 parallel new 和 cms（concurrent mark-sweep，併發標記和清除）垃圾**器。不過它可以通過環境變數來修改。
export kafka_jvm_performance_opts="-server -xx:+useg1gc -xx:maxgcpausemillis=20 -xx:initiatingheapoccupancypercent=35 -xx:+disableexplicitgc -dj**a.awt.headless=true
"
資料中心布局：生產環境伺服器不可用意味著金錢的損失，使用 kafka集群的複製功能就顯得尤為重要，而伺服器在資料中心所處的物理位置也變得重要起來。在為 broker增加新分割槽的時候，broker並無法獲知機架的資訊。也就是說，兩個 broker有可能是同乙個機架上，或者在同乙個可用區域（如果執行在像 aws這樣的雲服務上），所以，在為分割槽新增副本的時候，這些副本很可能被分配給同乙個機架的broker，他們使用相同的電源和網路連線。如果機架出了問題，這些分割槽就會離線，客戶端就無法訪問它們。更糟糕的是，如果發生不完整的主節點擊舉，那麼在恢復時就可能丟失資料。
所以，最好把集群的 broke安裝在不同的機架上，至少不要讓它們共享可能出現單點故障的基本設施，比如電源和網路。也就是說，部署伺服器需要至少兩個電源連線（兩個不同的迴路）和兩個網路交換機（保證可以進行無縫的故障切換）。除了這些以外，最好還要把 broker安放在不同的機架上。因為隨著時間的推移，機架也需要進行維護，而這會導致機器離線（比如移動機器或者重新連線電源）
kafka 使用 zk來儲存 broker、主題和分割槽的元資料資訊。對於乙個包含多個節點的 zk群組來說，kafka集群的這些流量並不算多，那些寫操作只是用於構造消費者群組和集群本身。實際上，在很多部署環境裡，會讓多個 kafka集群共享乙個 zk群組（每個集群使用乙個 chroot路徑）kafka0.9版本後引入新的消費者介面，允許 broker直接維護消費者群組的資訊，主題資訊，消費者分割槽的偏移量。
消費者可以選擇將偏移量提交到zk或kafka，還可以選擇提交偏移量的時間間隔。如果消費者將偏移量提交到zk，那麼到每個提交時間點，消費者將會為每乙個消費的分割槽往zk寫入一次偏移量。合理的提交間隔是1分鐘，因為這剛好是消費者群組的某個消費者發生失效時能夠讀取到重複訊息的時間。值得注意的是，這些提交對於 zk來說流量不算小，特別是當集群裡有多個消費者的時候。如果 zk群組無法處理太大的流量，就有必要使用長一點的提交時間間隔。建議使用最新版的kafka，將偏移量提交到broker上。
雖然多個 kafka集群可以共享乙個 zk群組，但是如果可能的話，不建議把 zk共享給其它應用程式。kafka對 zk的延遲和超時比較敏感，與 zk群組之間的乙個通訊就可能導致 kafka伺服器出現無法**的行為。這樣很容易讓多個 broker同時離線，如果它們與zk 之間斷開連線，也會導致分割槽離線。這也會給集群控制器帶來壓力，在伺服器離線一段時間之後，當控制器嘗試關閉乙個伺服器時，會表現出一些細小的錯誤。其他的應用程式因重度使用或進行不恰當的操作給zk群組帶來壓力，所以最好讓它們使用自己的 zk群組。
kafka效能調優
1 網路和io操作執行緒配置優化 broker處理訊息的最大執行緒數 預設為3 num.network threads cpu核數 1 broker處理磁碟io的執行緒數 num.io threads cpu核數 2 2 log資料檔案刷盤策略 每當producer寫入10000條訊息時，刷資料到磁...
kafka效能調優
2 vim bin kafka server start.sh 調整kafka heap opts xmx16g xms16g 的值 2 3 4 broker處理訊息的最大執行緒數 num.network.threads 9 broker處理磁碟io的執行緒數 num.io.threads 16 s...
HBase集群調優
2.5.2.1.zookeeper.session.timeout 這個預設值是3分鐘。這意味著一旦乙個server宕掉了，master至少需要3分鐘才能察覺到宕機，開始恢復。你可能希望將這個超時調短，這樣master就能更快的察覺到了。在你調這個值之前，你需要確認你的jvm的gc引數，否則乙個長時...