kafka消息丢失和重复消费问题

先梳理下kafka的相关概念
  
    Broker：消息中间件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。

    Topic：一类消息，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。

    Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。

    Segment：partition物理上由多个segment组成，下面2.2和2.3有详细说明。

    offset：每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息.

消息如何保证可靠，是消息队列使用过程中非常重要的问题。我们都知道，在分布式系统中可用性是不可能达到百分百的，即使是阿里这样的顶尖公司也不例外，如何尽可能的让系统可用、数据可靠是一个经久不衰的问题。

    kafka消息在在流式数据的处理过程中发挥着非常关键的作用，它能同时接收百万级的消息写入。但是，如何保证消息不丢失、并且不被重复消费呢。这就要从kafka的架构以及核心机制进行分析。 

消息是如何被消费的

   在消费者不断的消费消息时，kafka对应的消息position也在不断的变化，而offset是受提交的position影响的，因此，正确的提交position即可保证消息不被重复消费。假设在处理消息之前就将当前消息的 position 保存到 zk 上即 offset，这就是只多一次消费，因为我们可能保存成功后，消息还没有消费机器就挂了，当机器再打开时此消息就丢失了；假设先消费消息然后保存 position 到 zk 上即 offset，此时我们就是至少一次，因为我们可能在消费完消息后offset 没有保存成功。

    首先，根据实际业务需求，尽量减少每次取出的量，从而尽可能避免数据的丢失了，但这毕竟是治标不治本的事，比较好的是在设计消息的内容时做标识，从而实现数据操作的幂等。当然对于一些数据可靠不是特别严格的，可以直接忽略掉这一点，比如大数据场景中，报表系统或者日志信息丢失几条都无所谓，不会影响最终的统计分析结果，毕竟只要设计合理，Kafka集群的可用性还是非常高的，出现故障的几率非常小