記一次kafka數據丟失問題的排查

數據丟失爲大事，針對數據丟失的問題咱們排查結果以下。
第一：是否存在數據丟失的問題？
    存在，且已重現。

第二：是在什麼地方丟失的數據，是不是YDB的問題？
    數據丟失是在導入階段，數據並無寫入到Kafka裏面，因此YDB也就不會從Kafka裏面消費到缺失的數據，數據丟失與延雲YDB無關。

第三：是如何發現有數據丟失？
    1.測試數據會一共建立365個分區，每一個分區均是9億數據，若是最終每一個分區仍是9億（多一條少一條均不行），則數據完整。
    2.測試開始次日，開始有丟失數據的現象，且丟失的數據愈來愈多。

第四：如何定位到是寫入端丟失數據的，而不是YDB消費丟失數據的？
    kafka支持數據的從新回放的功能(換個消費group)，咱們清空了ydb的全部數據，從新用kafka回放了原先的數據。
    若是是在ydb消費端丟失數據，那麼第二遍回放數據的結果，跟第一次消費的數據在條數上確定會有區別,徹底如出一轍的概率很低。
    數據回放結果爲：與第一次回放結果徹底同樣，能夠確認爲寫入段丟失。

第五：寫入kafka數據爲何會丟失？
    導入數據咱們採用的爲kafka給的官方的默認示例，官方默認並無處理網絡負載很高或者磁盤很忙寫入失敗的狀況（網上遇到同類問題的也不少）
    一旦網絡中斷或者磁盤負載很高致使的寫入失敗，並無自動重試重發消息。
    而咱們以前的測試，
    第1次測試是在共享集羣環境上作的測試，因爲有其餘任務的影響，網絡與負載很不穩定，就會致使數據丟失。
    第2次測試是在獨立集羣，並無其餘任務干預，可是咱們導入程序與kafka不在一臺機器上，而咱們又沒有作限速處理（每小時導入5億條數據）
    千兆網卡的流量常態在600~800M左右，若是此時忽然又索引合併，瞬間的網絡跑盡是很正常的，丟包也是很正常的。
    延雲以前持續壓了20多天，確實一條數據沒有丟失，究其緣由是導入程序與kafka在同一個機器上，且啓用了限速。

第六：這個問題如何解決？
    官方給出的默認示例並不可靠，並無考慮到網絡繁忙的狀況，並不適合生產。
    故kafka必定要配置上消息重試的機制，而且重試的時間間隔必定要長一些，默認1秒鐘並不符合生產環境（網絡中斷時間有可能超過1秒）。
    延雲認爲，增長以下參數會較大幅度的減小kafka寫入數據照成的數據丟失，在公司實測，目前還沒遇到數據丟失的狀況。
         props.put("compression.type", "gzip");
         props.put("linger.ms", "50");
         props.put("acks", "all");
         props.put("retries ", 30);
         props.put("reconnect.backoff.ms ", 20000);
         props.put("retry.backoff.ms", 20000);