kafka0.8新特性小结

      通过两张图可以一目了然地对比0.8版本和0.7版本的不同：

                                                        kafka0.7架构图

                                                kafka0.8架构图

0.7版：
1）对于0.7版本，我们要写入数据时（producer）必须显性地指定写入的broker和partition，负载均衡必须自己处理；
2）对于同一个topic的同一个partition 序号，在不同的broker（假设为n个broker）上，被表现为多个partition（最多为n个）

0.8版本：
1）基于leader-follower以及冗余备份的方案，一个partition可以在多个server上备份，那么其中一个server作为此partiton的leader，leader负责此partition所有的读写操作,如果leader失效，那么将会有其他follower来接管(成为新的leader)，follower只是单调的和leader跟进,同步消息即可。 由此可见作为leader的server承载了全部的请求压力，因此从集群的整体考虑,有多少个partitions就意味着有多少个"leader"，kafka会将"leader"均衡的分散在每个实例上，来确保整体的性能稳定。 （kafka提供了一些有效的工具来对集群的leader进行均衡以及在线添加partition，参考官方wiki）

2) 集群概念，主要体现在producer方面（不过对于0.8版本提供的高级API，在consumer端也进行了抽象，读取消息也可以不care broker和partition, 0.7版本很蛋疼地需要自己记录下读取到哪个broker 、partition、offset ），kafka在发布消息到kafak cluster的过程中，也提供了一层抽象，即Partitoner的接口，对发布消息到哪个partition进行自定义策略，用户可以自己实现该接口来控制消息写入到哪个partition；