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

第二：是在什么地方丟失的數據，是否是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);