Producer 生产者
Consumer 消费者
Server （broker） 实例 多个 实例构成了kafka集群
zookeeper 配置信息的保存的地方
Topic 主题 承载消息的 一种集合
partition 一个或者多个p组成一个Topic 里面存放的都是一种信息
replicas 备份 partition的备份数量；
offset 偏移量 简单的理解为消息在partition中存放的地址 是一个Long类型的
kafka对消息能不能进行随机读取？
因为offset是唯一的标识消息地址的 索引，所以kafka中不存在随机的读取；
kafka对消息日志的管理
kafka的broker 会按配置 比如两天保存 这条消息的的日志，无论这条消息是否被消费；对于consumer来说，它需要保存的是消息的offset，对于offset的控制和使用，由consumer来控制，每当消费者消费一条信息后，offset会向前推进一个，消息是依次被消费的；
生产者和消费者的信息是由zookeeper来维护不需要由broker来操心；
一个Topic 可以分成若干个partition，保证了多个consumer可以对其进行消费，北欧整了并发性能；
kafka的对于partition的备份
p1 p2 p3 p4
s1 s2 s3 s4 （都是leader）
f11 f21 f31 f41 （剩下的都是follow 也是server 帮助备份的）
f21 f22 f32 f42
f31 f43
一个leader下面有几个follow 有多有少吧，follow不进行消息的传递，知识起一个备份作用，并且以s4举例，如果s4挂掉了，那么就会从f41 f42 f43中 选一个当成leader；由此可见，leader承载了server的所有负载，有多少个partition就会有多少个leader，kafka会将partition均衡地分发到server 上去；
每个consumer都有唯一的一个分组group，每个group可以由一个或者多个consumer组成；
发送到Topic的消息 一种Topic消息只会被 一个group 中的一个consumer消费，也就是说每个group只能有一个consumer指向partition；
每个group之间又是相互独立的 g1中c3消费了p2 ，g3中的c3同样也可以消费p2，但是g2中的c2消费了p1，那么g2中其他的c就不能再消费p1了；
随便找了三张图解释上面的
如上图，向test2发送消息1，2，3，4，5，6，7，8，9
消息被g3组的消费者均分，g4组的消费者在接收到了所有的消息。
g3组：
C1接收到了：2，5，8
C2接收到了：3，6，9
C3接收到了：1，4，7
g4组：
C1接收到了：1，2，3，4，5，6，7，8，9
启动多个组，则会使同一个消息被消费多次
——————————————————————————————————————
kafka 能够保证p中消息的消费是顺序的，但是从Topic 的角度来看 消息的消费是无序的；
此外每个group中的c不能多于p，因为这样就会存在不工作的c，图一只是举例；
kafka的应用场景
普通的消息传递，不能保证事务，没有消息的反馈机制，也就是说c端消费不消费，s端都不知道；
kafka可以作为"网站活性跟踪"的最佳工具;可以将网页/用户操作等信息发送到kafka中.并实时监控,或者离线统计分析等；
kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统；
消息传输机制
1) at most once: 最多一次,这个和JMS中"非持久化"消息类似.发送一次,无论成败,将不会重发；
2) at least once: 消息至少发送一次,如果消息未能接受成功,可能会重发,直到接收成功；
follow和leader的关系
一个leader可以有或者没有follow 一个或者多个follow，消息被消费的日志也会被follow保存，每一次消息来和消费都会被leader和follow记录保存，只有负责p的leader和follow都commited好了，consumer才能开始消费这个p中的消息；follow要实时跟踪leader信息的变化，如果f落后太多，那么就会被删除；
日志的一点处理方式
p的信息会保存到zookeeper中，有一个默认值，就是1g超过了就会flush
