kafka 資料丟失和速度優化 問題的幾點思考：

producer端：

1，首先巨集觀上看保證資料的可靠安全性，肯定是依據分割槽數做好資料備份，設立副本數。
2，push資料的方式：同步非同步推送資料：權衡安全性和速度性的要求，選擇相應的同步推送還是非同步推送方式。
1)同步就能較準確的保證資料的安全性，但是在速度上就會略遜一籌；
=>若資料的安全級別較高，可採用同步寫入的方式，並設定acks引數為-1確保資料寫入到leader和各個follows中
2)非同步要考慮到partition leader在未完成副本數follows的備份時就宕機的情況，即使選舉出了新的leader但是已經push的資料因為未備份就丟失了！
a.不能讓記憶體的緩衝池太滿，如果滿了記憶體溢位，也就是說資料寫入過快，kafka的緩衝池資料落盤速度太慢，這時肯定會造成資料丟失。
b.儘量保證生產者端資料一直處於執行緒阻塞狀態，這樣一邊寫記憶體一邊落盤。
c.非同步寫入的話還可以設定類似flume回滾型別的batch數，即按照累計的訊息數量，累計的時間間隔，累計的資料大小設定batch大小。
設定合適的方式，增大batch 大小來減小網路IO和磁碟IO的請求，這是對於kafka效率的思考。
=>不過非同步寫入丟失資料的情況還是難以控制
=>還是得穩定整體叢集架構的執行，特別是zookeeper，當然正對非同步資料丟失的情況儘量保證broker端的穩定運作吧
3.在producer端可以對push的訊息做壓縮處理
kafka不像hadoop更致力於處理大量級資料，kafka的訊息佇列更擅長於處理小資料。針對具體業務而言，若是源源不斷的push大量的資料（eg：網路爬蟲），可以考慮訊息壓縮。但是這也一定程度上對CPU造成了壓力,還是得結合業務資料進行測試選擇
*4.結合上游的flume架構，每一個flume分支對應一個producer，避免在flume-collector機器上一次性往broker推送，一方面造成flume-collector的io壓力，一方面可能存在資料丟失的情況。（OS：這是我在離線轉實時升級flume架構時考慮的一個點）

broker端：
1，topic設定多分割槽，分割槽自適應所在機器，為了讓各分割槽均勻分佈在所在的broker中，分割槽數要大於broker數。
（eg:我們實時的7臺機器中，broker3臺，分割槽數設為6，同時保證大於spark-Streaming消費數量（5個works）保證每個consumer都能讀到partition）
分割槽是kafka進行並行讀寫的單位，是提升kafka速度的關鍵。
2，kafka訊息持久化到磁碟，採用線性讀寫到硬碟上，速度是可以得到保障的。
這邊提一個自己的構想，在持久化硬碟上再多做個分散式快取，將kafka持久化目錄整合到alluxio中。
(eg:在我的畢業設計中清洗資料寫到hbase後，hive在整合hbase建外部表時，hbase的目錄整合到alluxio中做了一個快取讀取，由於本人電腦配置有限並且畢業設計弄的是偽分散式，所以效能上讀取資料上可能沒有體現出來。所以這個想法的可行性還待測試...)
3，broker的幾個引數：
a)broker能接收訊息的最大位元組數的設定一定要比消費端能消費的最大位元組數要小，否則broker就會因為消費端無法使用這個訊息而掛起。
b)broker可賦值的訊息的最大位元組數設定一定要比能接受的最大位元組數大，
否則broker就會因為資料量的問題無法複製副本，導致資料丟失

comsumer端：
1，關閉自動更新offset，等到資料被處理後再手動跟新offset。
（OS：相信都是用的手動提交的方式吧~）
*2，在消費前做驗證前拿取的資料是否是接著上回消費的資料，不正確則return先行處理排錯。
*3，一般來說zookeeper只要穩定的情況下記錄的offset是沒有問題，除非是多個consumer group 同時消費一個分割槽的資料，其中一個先提交了，另一個就丟失了。

JVM調優：

*1，scala語言同樣是執行在jvm上的，kafka的原始碼也是用scala編寫的，優化的話也可以從jvm上入手。

（OS：jvm可控引數太多了，每一個引數的調整應該經過一系列的測試，我在這邊總結不出來）

2，留意底層GC的時間，若GC阻塞導致kafka丟失了zookeeper會話，需要對jvm引數進行調整配置更大的heap size,或者配置zookeeper更大的超時時間 =》保證資料安全性可靠性勢必會犧牲一些速度效能
=》以上是我參考部落格及結合自己使用情況的一些思考
BLOG URL:
http://www.sohu.com/a/151179123_463989
http://blog.csdn.net/john2522/article/details/64555065
若是我有說錯理解錯的地方，可以參看原始部落格，另外煩請指正！！