记一次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);