Consumer是Kafka最重要的组件，也是实现Kafka离线、在线实时处理的核心。因而设计优化和比较迅速，比如Low Level Consumer、hight level Consumer、Consumer Rebalance、Consumer重新设计、镜像机制等。为了让大家对Kafka的Consumers有一个全面、深入的理解，本节从这几个方面进行详细阐述与分析。

Kafka中的Consumer是基于Pull的机制从Broker中获得消息的，换句话说，只要Broker有数据，Kafka中的Consumer就可以获得Broker中的消息，从而很好地实现了在线实时的效果。但是这也面临一些问题，例如当消息通过网络传递给消费者时，此时如果消费者没有来得及处理Broker就宕机了，但是Broker却记录了该消息已被消费，那么该消息就丢失。为了避免出现这种情况，很多消息系统会增加一个acknowledge特性，标识该消息被成功消费。然后消费者将acknowledge发送给Broker，但是Broker不一定能够获得这个acknowledge，进而导致消息被重复消费。这种方法的缺点是，由于服务器要维护这些消息的处理状态，所以该方法会产生额外的网络开销。

在Kafka系统中，Topic是由多个Partition组成的。每个Partition在任意时刻只能被一个Consumer消费。这意味着，每个Partition里面的Consumer位置是整数，标识下一个被消费消息的offset。还可以通过配置文件来配置定期的设置检查点。通过设置offset标记方式，就可以简单地维护Consumer被消费的消息。详细的Partition机制请参看前面Topic、Partitions部分。(www.daowen.com)

与其他的消息队列相比，Kafka的Consumer消费记录状态（offset），实际上被写入到了Zookeeper集群中，将Consumer消费记录状态（offset）放到另外一个地方，比如将其放置在处理结果所存放的数据中心，效率会更高。为什么这么说呢？还是用实际的实例来描述：在Kafka集群中，某Consumer只想简单地处理一些和计算，并将结果写到中心化的事务型OLTP数据库中。对于这种情景，消费者可以将状态信息写到同一个事务中，这就解决了分布式一致性问题。这种技巧还可以用在非事务性系统中，如基于Kafka的搜索系统中可以将消费者的状态存放在索引块中。虽然这些数据还不具有持久性，但这意味着索引可以和消费者状态保持同步，如果一个没有刷新的索引块在一次故障中丢失了，那么这些索引可以从最近的检查点偏移处开始重新消费。又如基于Kafka将数据并行加载到Hadoop集群中，每个Mapper在Map任务的最后，将偏移量写到HDFS中。如果一个加载任务失败了，每个Map⁃per可以简单地从存储在HDFS中的偏移量处重启消费。这个技巧还有另外一个好处，消费者可以重新消费已经消费过的数据。这违反了队列的性质，但是这样可以使多个消费者一起来消费。打个比方，如果一段Consumer代码出现了Bug，在发现Bug之前这个Consumer消费了一堆数据，那么在Bug修复之后，Consumer可以从指定的位置重新消费。