Broke

1. 消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能
2. 直接使用linux 文件系统的cache，来高效缓存数据。
3. 即使消息被消费,消息仍然不会被立即删除.日志文件将会根据broker中的配置要求,保留一定的时间之后删除
4. 采用linux Zero-Copy提高发送性能。
5. Topic划分为多个partition，提高parallelism
6. 可以通过实现Partitioner接口来定制Partition的分区规则
7. At least one 消息绝不会丢，但可能会重复传输
   
8. 通过冗余机制来保证信息的安全
9. 一个Broke可以包含多个Topic的Part,一个Topic也可以将多个Part分布到不同的不同的Broke上
10. 数据压缩：支持GZIP和Snappy压缩协议

Consumer 公共特性

1. Consumer根据消费能力自主控制消息拉取速度
2. Consumer根据自身情况自主选择消费模式，例如批量，重复消费，从尾端开始消费等

Lower Level Consumer

1. Consumer从kafka集群pull数据
2. Consumer负责维护消息的消费记录,控制获取消息的offset
3. Consumer可将offset设成一个较小的值，重新消费一些消息
4. 必须找出指定Topic Partition中的lead broker
   
5. 添加事务管理机制以保证消息被处理且仅被处理一次
   
6. 在一个处理过程中只消费Partition其中的一部分消息
   

High Level Consumer 

1. High Level模式下的Group Name 是整个Kafka集群的全局变量
2. 消息消费以Consumer Group为单位，每个Consumer Group中可以有多个consumer，每个consumer是一个线程，topic的每个partition同时只能被某一个consumer读 取，Consumer Group对应的每个partition都有一个最新的offset的值，存储在zookeeper上的。所以在正常情况下不会出现重复消费的情况。
3. 因为consumer的offerset并不是实时的传送到zookeeper（通过配置来制定更新周期），所以Consumer如果突然Crash，有可能会读取重复的信息

4. High Level Consumer 可以并且应该被使用在多线程的环境，线程模型中线程的数量(也代表group中consumer的数量)和topic的partition数量有关，下面列举一些规则：

   1. 当提供的线程数量多于partition的数量，则部分线程将不会接收到消息；
   2. 当提供的线程数量少于partition的数量，则部分线程将从多个partition接收消息；
   3. 当某个线程从多个partition接收消息时，不保证接收消息的顺序；可能出现从partition3接收5条消息，从partition4接收6条消息，接着又从partition3接收10条消息；
   4. 当添加更多线程时，会引起kafka做re-balance, 可能改变partition和线程的对应关系。

Consumer Group