kafka诞生之初，它自带一个基于scala的生产者和消费者客户端。但是慢慢的我们认识到这些API有很多限制。比如，消费者有一个“高级”API支持分组和异常控制，但是不支持很多更复杂的应用场景；它也有一个“低级”API，支持对细节的完全控制，但是要求码农自己控制失败和异常。所以重新设计了它们。
这个过程的第一阶段就是在0.8.1版本的时候重写了生产者API。在最近的0.9版本中完成了第二阶段，提供了消费者的新API。建立在新的分组协议只是，新的消费者带来以下好处：
- API更加简洁：新的消费者API综合了老版本的“高级”和“低级”API的功能，同时提供了分组机制和lower level access来实现自己的消费策略；
- 减少了依赖：新的消费者API是用纯java写的。没有了scala和zk的依赖，让代码工程更轻量级；
- 更安全：新的消费者API支持kafka0.9版本的安全机制；
- 新的消费者也增加了一系列的机制来控制组消费时的容错。老的API使用大量的java代码实现的（与ZK交互过多），复杂的逻辑很难让其他语言的消费者实现。新的API使这变得更简单。现在已经有C版本的客户端了。
虽然新的消费者是被重新设计过的和新的交互机制，但很多感念没有本质区别，所以熟悉老API的码农也不会觉得新API生硬。但是，也有一些特别细微的细节相对于组管理和线程模型需要在码代码的时候注意。
还有一个注意点：新的消费者API还是测试版本。（不稳定哦，随时会有BUG冒出来，伟大的踩坑者）
Getting Started
略过旧API中的分组消费介绍。。。
旧的API强依赖ZK做分组管理，新的API使用kafka自己的分组协调机制。针对每个消费组，会从所有的broker中挑选出一个出来充当这个组的“协调员”。协调员负责管理该组的状态。它的主要任务是，当新的组成员进入、老的组成员离开和元数据改变时进行分区的协调分配。这种重新分配分区的行为称之为“重新平衡组”。
当一个组首次被初始化，每个分区的消费者一般会从最早或最近的数据开始读。然后在每个分区的消息被依次读出。在消费过程中，消费者会提交已经成功处理了的消息的偏移量。例如，在下图中，消费者正在读的消息的偏移量是6，而它最近一次提交的偏移量是1：
当一个分区被重新分配给组中的另一个消费者时，这个消费者会从上一个消费者最后一次提交的偏移量处开始读。如果上面例子中的消费者突然崩溃了，其他组成员读的时候会从1开始读。这种情况下，它会从1到6重新消费一遍。
上图中还标注了其他两个位置。Log End Offset标记了最后一条消息写入后的偏移量。High Watermark标记了最后被其他replicas同步成功了的偏移量。对于消费者来说，只能读到High Watermark处，这样为了防止未同步的消息被读了以后丢失掉。
配置和初始化
在开始使用新的消费者API之前，先把 kafka-clients 这个依赖加到工程中。
<dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-clients</artifactId> <version>0.9.0.1</version> </dependency>