数据丢失为大事，针对数据丢失的问题我们排查结果如下。
第一：是否存在数据丢失的问题？
存在，且已重现。
第二：是在什么地方丢失的数据，是否是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);
参数介绍：
compression.type：producer用于压缩数据的压缩类型。默认是无压缩。正确的选项值是none、gzip、snappy。压缩最好用于批量处理，批量处理消息越多，压缩性能越好。
linger.ms：producer组将会汇总任何在请求与发送之间到达的消息记录一个单独批量的请求。通常来说，这只有在记录产生速度大于发送速度的时候才能发生。然而，在某些条件下，客户端将希望降低请求的数量，甚至降低到中等负载一下。这项设置将通过增加小的延迟来完成--即，不是立即发送一条记录，producer将会等待给定的延迟时间以允许其他消息记录发送，这些消息记录可以批量处理。这可以认为是TCP种Nagle的算法类似。这项设置设定了批量处理的更高的延迟边界：一旦我们获得某个partition的batch.size，他将会立即发送而不顾这项设置，然而如果我们获得消息字节数比这项设置要小的多，我们需要“linger”特定的时间以获取更多的消息。 这个设置默认为0，即没有延迟。设定linger.ms=5，例如，将会减少请求数目，但是同时会增加5ms的延迟。
acks：
producer需要server接收到数据之后发出的确认接收的信号，此项配置就是指procuder需要多少个这样的确认信号。此配置实际上代表了数据备份的可用性。以下设置为常用选项：
（1）acks=0： 设置为0表示producer不需要等待任何确认收到的信息。副本将立即加到socket buffer并认为已经发送。没有任何保障可以保证此种情况下server已经成功接收数据，同时重试配置不会发生作用（因为客户端不知道是否失败）回馈的offset会总是设置为-1；
（2）acks=1： 这意味着至少要等待leader已经成功将数据写入本地log，但是并没有等待所有follower是否成功写入。这种情况下，如果follower没有成功备份数据，而此时leader又挂掉，则消息会丢失。
（3）acks=all： 这意味着leader需要等待所有备份都成功写入日志，这种策略会保证只要有一个备份存活就不会丢失数据。这是最强的保证。
（4）其他的设置，例如acks=2也是可以的，这将需要给定的acks数量，但是这种策略一般很少用。
retries ：设置大于0的值将使客户端重新发送任何数据，一旦这些数据发送失败。注意，这些重试与客户端接收到发送错误时的重试没有什么不同。允许重试将潜在的改变数据的顺序，如果这两个消息记录都是发送到同一个partition，则第一个消息失败第二个发送成功，则第二条消息会比第一条消息出现要早。
reconnect.backoff.ms：连接失败时，当我们重新连接时的等待时间。这避免了客户端反复重连
retry.backoff.ms：在每次重试之前，producer会更新相关topic的metadata，以此进行查看新的leader是否分配好了。因为leader的选择需要一点时间，此选项指定更新metadata之前producer需要等待的时间。
参考：https://www.cnblogs.com/rilley/p/5391268.html
转载至https://blog.csdn.net/qq_33160722/article/details/52903380
