独特的设计：消息被消费和消息被删除互不干扰
目的：减少消息被消费后，对文件内容改动的IO开支
消息被删除只和broker配置的时间有关
producer：向topic发布消息
consumer：预定topics并消费
kafka集群：每个服务叫做broker
broker：
topic：基本单位，消息的归纳
partition区：每个topic被分成多个区，每个区在存储方面是append log，append log在文件中的位置叫做offset，唯一标示消息
partition目的：避免单个文件过大
leader：分区中消息的读写
follower：同步leader，随时准备接替leader
consumers and consumer group:
队列模式：每个consumer属于一个consumer group
发布-订阅：每个consumer属于不同的group
guarantees担保：
发送到partitions中的消息将会按照它接受的顺序追加到日志中
对于消费者而言，他们消费消息的顺序和日志中消息顺序一致
如果topic的replicationfactor为N，那么允许N-1个kafka实例失效
2.设计原理
持久性：1.文件存储，日志文件append操作，检索较小。
2.broker将消息暂时buffer起来，消息个数达到一定阀值，fkush将入磁盘。减小写入次数
性能：kafka吞吐量 --->网络IO和磁盘IO
方案：开启消息压缩机制
生产者：负载均衡 到达哪个分区算法决定
异步发送：消息buffer起来，批量发送到broker
消费者：向broker发送fetch请求，并告知其获取消息的offset，此后获取一定数量的消息
pull or fetch：主动索取，保持主动权
push：JMS 被动获取
3.消息传送机制
至少一次
至多一次
恰巧一次
建议：消息重复总比消息丢失好
4.复制备份
leaderr处理读写请求，follower保持同步
folower和consumer一样消费消息，并保存本地日志中
leader负责跟踪所有folower状态，
followers 替代 leader
5.日志
topic的名称"my_topic",它有2个patitions，
每个partition在物理存储层面，有多个log file组成，segmentfile命名规则："最小offset"."kafka"
日志的创建策略
日志的删除策略
日志的追加策略
6.分配
zookeeper存储kafka原信息，并使用zookeeper watch机制发现原信息并作出相应的动作
1）broker注册：当一个kafka启动后，首先向zookeeper注册自己的节点信息，同时当broker和zookeeper断开连接时，此znode被删除
格式：/broker/ids/[0...N] -->host:port;
2）broker topic registry：当一个broker启动时,会向zookeeper注册自己持有的topic和partitions信息,仍然是一个临时znode.
格式：: /broker/topics/[topic]/[0...N] 其中[0..N]表示partition索引号.
3） Consumer 信息，id注册、offset追踪、区域持有的追踪
1) Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partition leader建立socket连接并发送消息.
2) Broker端使用zookeeper用来注册broker信息,已经监测partitionleader存活性.
3) Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息.集群中的每个服务都会同时扮演两个角色：作为它所持有的一部分分区的leader，同时作为其他分区的followers，这样集群就会据有较好的负载均衡。
总结：。。。
原文：http://blog.51cto.com/13496382/2162510