最新版（0.8.2.1）Kafka的Consumer Rebalance控制策略，用在基于Kafka目前的Con⁃sumer结构中，存在很多缺陷，原理已经在Consumer Rebalance控制策略中进行了详细的分析，这就迫使Kafka开发者实现另外一种解决方案，来解决上面的缺陷，这就是Consumer重新设计的原因，Kafka开发者计划在未来的0.9.∗中实现该功能，其核心思想是用中心协调器（Coordinator），本节将详细阐述重新设计的Consumer。

新的Cosumer从很多地方进行了修改，如简化消费者客户端、中心调度器（Coordinator）、允许手工管理offset、Rebalance后触发用户指定的回调、非阻塞式Consumer API等。下面对这些新的设计功能进行总结。

简化消费者客户端：部分用户希望开发和使用non－java的客户端。现阶段使用non－java开发SimpleConsumer比较方便，但想开发High Level Consumer并不容易。因为High Lev⁃el Consumer需要实现一些复杂但必不可少的失败探测和Rebalance。如果能将消费者客户端更精简，使依赖最小化，将会极大地方便non－java用户实现自己的Consumer。

中心调度器（Coordinator）：由于当前版本的High Level Consumer存在Herd Effect和Split Brain等问题。如果将失败探测和Rebalance的逻辑放到一个高可用的中心Coordinator，那么这两个问题即可解决。同时还可大大减少Zookeeper的负载，有利于Kafka Broker的水平扩展。(www.daowen.com)

允许手工管理offset：一些系统希望以特定的时间间隔在自定义的数据库中管理Offset。这就要求Consumer能获取到每条消息的Metadata，例如Topic、Partition、Offset，同时还需要在Consumer启动时得到每个Partition的Offset。实现这些功能，需要提供新的Consumer API。同时有个问题不得不考虑，即是否允许Consumer手工管理部分Topic的Offset，而让Kafka自动通过Zookeeper管理其他Topic的Offset。一个可能的选项是让每个Consumer只能选取一种Offset管理机制，这可以极大地简化Consumer API的设计和实现。

Rebalance后触发用户指定的回调：一些应用可能会在内存中为每个Partition维护一些状态，Rebalance时，它们可能需要将该状态持久化。因此希望支持用户实现并指定一些可插拔的并在Rebalance时触发的回调。也就是说，如果用户希望使用Kafka提供的自动Offset管理，则需要Kafka提供该回调机制。

非阻塞式Consumer API：源于那些实现高层流处理操作，如filter by、group by、join等系统。现阶段的阻塞式Consumer几乎不可能实现Join操作。