丢数据

场景：

1.生产者发送时丢失(producer -> broker)

选择带有 callBack的api进行发送，并设置 acks

acks = 0，生产者发送消息之后 不需要等待服务端的任何响应，它不管消息有没有发送成功，如果发送过程中遇到了异常，导致broker端没有收到消息，消息也就丢失了。实际上它只是把消息发送到了socketBuffer(缓存)中，而socketBuffer什么时候被提交到broker端并不关心，它不担保broker端是否收到了消息，但是这样的配置对retry是不起作用的，因为producer端都不知道是否发生了错误，而且对于offset的获取永远都是-1，因为broker端可能还没有开始写数据。这样不保险的操作为什么还有这样的配置？kafka对于收集海量数据，如果在收集某一项日志时是允许数据量有一定丢失的话，是可以用这种配置来收集日志。　　　　

acks = 1(默认值)，生产者发送消息之后，只要分区的leader副本成功写入消息，那么它就会收到来自服务端的成功响应。其实就是消息只发给了leader leader收到消息后会返回ack到producer端。如果消息无法写入leader时(选举、宕机等情况时)，生产都会收到一个错误的响应，为了避免消息丢失，生产者可以选择重发消息，如果消息成功写入，在被其它副本同步数据时leader　　崩溃,那么此条数据还是会丢失，因为新选举的leader是没有收到这条消息，ack设置为1是消息可靠性和吞吐量折中的方案。　　

acks = all(或-1) ，生产者在发送消息之后，需要等待ISR中所有的副本都成功写入消息之后才能够收到来自服务端的成功响应，在配置环境相同的情况下此种配置可以达到最强的可靠性。即：在发送消息时，需要leader 向fllow 同步完数据之后，也就是ISR队列中所有的broker全部保存完这条消息后，才会向ack发送消息，表示发送成功。

retries(重试)

retries参数的值决定了生产者可以重发消息的次数，如果达到这个次数，生产者会放弃重试并返回错误。默认情况下，生产者会在每次重试之间等待100ms ，可以通过retry.backoff.ms 参数来配置时间间隔。

比如，设置了acks=all和min.insync.replicas=2。由于某种原因，所有follower都挂了，由于min.insync.replicas=2，所以生产者无法收到来自Broker端的ack。

默认情况下，Producer不会对此错误进行处理，这就会造成消息丢失，即**at-most-once **语义。我们可以通过配置重试次数来让生产者重新发送消息。比如配置retries=3，默认为0

　在kafka中错误分为2种，一种是可恢复的，另一种是不可恢复的。
　　可恢复性的错误：
　　　　　　如遇到在leader的选举、网络的抖动等这些异常时，如果我们在这个时候配置的retries大于0的，也就是可以进行重试操作，那么等到leader选举完成后、网络稳定后，这些异常就会消息，错误也就可以恢复，数据再次重发时就会正常发送到broker端。需要注意retries(重试)之间的时间间隔，以确保在重试时可恢复性错误都已恢复。
　　不可恢复性的错误：
　　　　　　如：超过了发送消息的最大值(max.request.size)时，这种错误是不可恢复的，如果不做处理，那么数据就会丢失，因此我们需要注意在发生异常时把这些消息写入到DB、缓存本地文件中等等，把这些不成功的数据记录下来，等错误修复后，再把这些数据发送到broker端。

factor等等些参数来保证

factor主要采用复制，确保集群可用性 offset topic的replicas数量（设置更高以确保可用性）。在集群大小满足此复制因子要求之前（例如set为3，而broker不足3个），内部topic创建将失败 offsets.topic.replication.factor = 3 （default）

上面说了三种防止生产者消息丢失，如何选择

1.高可用型　　配置：acks = all，retries > 0 retry.backoff.ms=100(毫秒) (并根据实际情况设置retry可能恢复的间隔时间)　　优点：这样保证了producer端每发送一条消息都要成功，如果不成功并将消息缓存起来，等异常恢复后再次发送。　　缺点：这样保证了高可用，但是这会导致集群的吞吐量不是很高，因为数据发送到broker之后，leader要将数据同步到fllower上，如果网络带宽、不稳定等情况时，ack响应时间会更长
2.折中型　　配置：acks = 1  retries > 0 retries 时间间隔设置 (并根据实际情况设置retries可能恢复的间隔时间)　　优点：保证了消息的可靠性和吞吐量，是个折中的方案　　缺点：性能处于2者中间
3.高吞吐型 　　配置：acks = 0　　优点：可以相对容忍一些数据的丢失，吞吐量大，可以接收大量请求　　缺点：不知道发送的消息是 否成功

总结：采用有callbak的api，并根据场景选择acks;失败时，设置重试次数、时间间隔;修改factor等配置，确保创建topic时，就符合高可用

2.broker之间同步丢失(broker->broker)

1.replication-factor 3，在创建topic时会通过replication-factor来创建副本的个数，它提高了kafka的高可用性，同时，它允许n-1台broker挂掉，设置好合理的副本因子对kafka整体性能是非常有帮助的，通常是3个，极限是5个，如果多了也会影响开销。
2.min.insync.replicas = 2，分区ISR队列集合中最少有多少个副本，默认值是1
3.unclean.leander.election.enable = false,是否允许从非ISR队列中选举leader副本，默认值是false,如果设置成true,则可能会造成数据丢失。
4.min.insync.replica，在一个topic中，1个分区 有3个副本，在创建时设置了min.insync.replica=2,假如此时在ISR中只有leader副本(1个)存在，在producer端生产数据时,此时的acks=all,这也就意味着在producer向broker端写数据时，必须保证ISR中指定数量的副本(包含leader、fllow副本)全部同步完成才算写成功，这个数量就是由min.insync.replica来控制的，这样producer端向broker端写数据是不成功，因为ISR中只有leader副本，min.insync.replica要求2个副本，此时的producer生产数据失败(异常)，当然consumer端是可以消费数据的，只不过是没有新数据产生而已.这样保证了数据的一致性，但这样会导致高可用性降低了。一般的配置是按： n/2 +1 来配置min.insync.replicas 的数量的，同时也要将unclean.leader.election.enable=false

总结：保证创建了副本；保证最少有两个副本在ISR中；不允许从非ISR中选举leader；保证向多少ISR节点同步成功才算成功

3.broker内刷盘丢失(broker->磁盘)

场景：Broker丢失消息是由于Kafka本身的原因造成的，kafka为了得到更高的性能和吞吐量，将数据异步批量的存储在磁盘中。消息的刷盘过程，为了提高性能，减少刷盘次数，kafka采用了批量刷盘的做法。即，按照一定的消息量，和时间间隔进行刷盘。这种机制也是由于linux操作系统决定的。将数据存储到linux操作系统种，会先存储到页缓存（Page cache）中，按照时间或者其他条件进行刷盘（从page cache到file），或者通过fsync命令强制刷盘。数据在page cache中时，如果系统挂掉，数据会丢失。

上图简述了broker写数据以及同步的一个过程。broker写数据只写到PageCache中，而pageCache位于内存。这部分数据在断电后是会丢失的。pageCache的数据通过linux的flusher程序进行刷盘。刷盘触发条件有三： 1.主动调用sync或fsync函数 2.可用内存低于阀值 3.dirty data时间达到阀值。dirty是pagecache的一个标识位，当有数据写入到pageCache时，pagecache被标注为dirty，数据刷盘以后，dirty标志清除。

Broker配置刷盘机制，是通过调用fsync函数接管了刷盘动作。从单个Broker来看，pageCache的数据会丢失。

理论上，要完全让kafka保证单个broker不丢失消息是做不到的，只能通过调整刷盘机制的参数缓解该情况。比如，减少刷盘间隔，减少刷盘数据量大小。时间越短，性能越差，可靠性越好（尽可能可靠）。这是一个选择题。

4.消费者丢失数据

enable.auto.commit = true/false(默认true)
　　是否开启自动提交消费位移的功能,默认开启.
　　当设置为true时，意味着由kafka的consumer端自己间隔一定的时间会自动提交offset，如果设置成了fasle，也就是由客户端(自己写代码)来提交，那就还得控制提交的时间间隔auto.commit.interval.ms

重复消费

1.分布式锁 生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。

2.唯一键防重。基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。

3.先查后写 要写数据库前，先根据主键查一下，如果这数据都有了，你就别插入了，update一下好了。

4. 关闭重试机制如果把重试机制关掉的话不显示，虽然解决了重复消费的问题，但是可能会造成丢失消息，不建议这么做。

消息堆积

1）生产端：一般当生产端发生积压（Broker正常的情况下）就要查看你的业务逻辑是否有异常的耗时步骤导致的，是否需要改并行化操作等。

Broker端：当Broker端发生积压我们首先要查看，消息队列内存使用情况，如果有分区的的话还得看每个分区积压的消息数量差异。当每个分区的消息积压数据量相对均匀的话，我们大致可以认为是流量激增。需要在消费端做优化，或者同时需要增加Broker节点（相当于存储扩容），如果分区加压消息数量差异很大的话（有的队列满了，有的队列可能还是空闲状态），我们这时候就要检查我们的路由转发规则是否合理。

2） 增加消费者，多部署几台消费者机器（横向扩展），提升消费者的消费能力。

3）此种情况可以将这些消费不成功的消息转发到其它队列里去(类似死信队列)，后面再慢慢分析死信队列里的消息处理问题。

总之，上面说到消息积压的问题，我们需要查看是否有无限重发的消息或者有进入死锁的程序等等，当确定是流量激增的话，我们需要评估是否需要增加资源还是通过限流的方式解决，当短时间大量消息需要处理时，在资源允许的情况下，我们可以新启一批消费者与消息队列，将原来的消费者中的消息直接作为生产者转发到临时应急队列中，这样大概率的能够快速解决消息积压。与其事后处理不如我们在设计之初就要把积压考虑进来，对于数据量非常大，但是实时性要求不高的场景，可以设计出批量消息发送，当队列积累到一定阀值再做批量消费消费，这里需要注意的就是重复消费带来的影响，设计不好就是一场灾难。

顺序消费

未完...