kafka消费者api分为high api和low api，目前上述demo是都是使用kafka high api，高级api不用关心维护消费状态信息和负载均衡，系统会根据配置参数，
定期flush offset到zk上，如果有多个consumer且每个consumer创建了多个线程，高级api会根据zk上注册consumer信息，进行自动负载均衡操作。
注意事项：
1.高级api将会内部实现持久化每个分区最后读到的消息的offset，数据保存在zookeeper中的消费组名中(如/consumers/push-token-group/offsets/push-token/2。
其中push-token-group是消费组，push-token是topic，最后一个2表示第3个分区)，每间隔一个(默认1000ms)时间更新一次offset，
那么可能在重启消费者时拿到重复的消息。此外，当分区leader发生变更时也可能拿到重复的消息。因此在关闭消费者时最好等待一定时间（10s）然后再shutdown()
2.消费组名是一个全局的信息，要注意在新的消费者启动之前旧的消费者要关闭。如果新的进程启动并且消费组名相同，kafka会添加这个进程到可用消费线程组中用来消费
topic和触发重新分配负载均衡，那么同一个分区的消息就有可能发送到不同的进程中。
3.如果消费者组中所有consumer的总线程数量大于分区数，一部分线程或某些consumer可能无法读取消息或处于空闲状态。
4.如果分区数多于线程数(如果消费组中运行者多个消费者，则线程数为消费者组内所有消费者线程总和)，一部分线程会读取到多个分区的消息
5.如果一个线程消费多个分区消息，那么接收到的消息是不能保证顺序的。
备注：可用zookeeper web ui工具管理查看zk目录树数据： xxx/consumers/push-token-group/owners/push-token/2其中
push-token-group为消费组，push-token为topic,2为分区3.查看里面的内容如：
push-token-group-mobile-platform03-1405157976163-7ab14bd1-0表示该分区被该标示的线程所执行。
总结：
producer性能优化:异步化，消息批量发送，具体浏览上述参数说明。consumer性能优化:如果是高吞吐量数据，设置每次拿取消息(fetch.min.bytes)大些，
拿取消息频繁(fetch.wait.max.ms)些(或时间间隔短些)，如果是低延时要求，则设置时间时间间隔小，每次从kafka broker拿取消息尽量小些。
