一、消息丢失的时机？

1. 生产端消息丢失
   问题：因为网络异常导致消息发送失败，此时可能会产生消息丢失的情况，重试后可能产生消息重复生产的情况。
   解决：超时重试，并在消费端保证幂等性。

2. 消息队列中消息丢失
   问题：如kafka是将数据存储在磁盘，如果每条消息写入时都立马存储在磁盘中会产生很多随机IO，随机IO耗时很高，因此数据是先写入缓冲区中，再根据特定的时机刷新到磁盘中，减少随机IO的开销。假设还未刷新到磁盘就出现宕机情况，则会产生消息丢失的情况。
   解决：可以考虑以集群方式部署Kafka服务，通过部署多个副本备份数据保证消息尽量不丢失。

3. 消费端消费时丢失
   问题：消费者消费消息的进度是记录在消息队列集群中的，而消费的过程分为三步：接收消息、处理消息、更新消费进度。消费端网络抖动或者消费端业务逻辑异常导致中断，此时会产生消息丢失的情况。
   解决：一定要等到消息接收和处理完成后才能更新消费进度，但是这也会造成消息重复的问题，比方说某一条消息在处理之后消费者恰好宕机了，那么因为没有更新消费进度，所以当这个消费者重启之后还会重复地消费这条消息。

二、如何避免重复消费？

1. 生产端重复发送
   kafka支持生产端幂等，这种特性保证消息虽然可能在生产端产生重复，但是最终在消息队列存储时只会存储一份。
   它的做法是给每一个生产者一个唯一的ID，并且为生产的每一条消息赋予一个唯一ID，消息队列的服务端会存储<生产者ID，最后一条消息ID>的映射。当某一个生产者产生新的消息时，消息队列服务端会比对消息ID是否与存储的最后一条ID一致，如果一致就认为是重复的消息，服务端会自动丢弃。

2. 消费端幂等
   解决1：在生产时定义一个全局的唯一id，在消费端判断id是否被处理过。
   解决2：数据库增加版本字段，执行sql时会有乐观锁。

三、减少消息延迟的方式？

1. 优化消费端耗时逻辑。
2. 增加消费者数量，在kafka中一个partition只能被一个消费者消费，所以单纯增加消费者数量对kafka来说是无用的，可以增加partition。