一、简介
1.1 介绍
Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。
Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。
特性：
1.通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
2.高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。
3.支持通过Kafka服务器和消费机集群来分区消息。
4.支持Hadoop并行数据加载。
1.2 优点
1）持续的消息：为了从大数据中派生出有用的数据，任何数据的丢失都会影响生成的结果，kafka提供了一个复杂度为O(1)的磁盘结构存储数据，即使是对于TB级别的数据都是提供了一个常量时间性能。
2）高吞吐量：keep big data in mind，kafka采用普通的硬件支持每秒百万级别的吞吐量
3）分布式：明确支持消息的分区，通过kafka服务器和消费者机器的集群分布式消费，维持每一个分区是有序的。
4）支持多种语言：java、.net、php、ruby、python。
5）实时性：消息被生成者线程生产就能马上被消费者线程消费，这种特性和事件驱动的系统是相似的。
1.3 使用场景
1）用户的行为数据
2）应用工程的性能数据
3）日志的用户活动数据等
二、通信方式
2.1 名词解释【重要】
Producer：生产者，用于将流数据发送到kafka消息队列上，它的任务是向Broker发送数据。
Customer：消费者，与其它消息中间件不同，它主动向broker拉message
Customer Group：消费者组，每个customer属于一个特定的customer group，可以为每个customer指定一个group name。
Broker：代理，即一个kafka实例，即一个kafka进程，可以把Message持久化到本地磁盘；
多个Broker即多个kafka实例构成kafka集群；
每个Cluster当中会选举出一个Broker来担任Controller，负责处理Partition的Leader选举，协调Partition迁移等工作。Broker是无状态的，消费状态靠消费者维护的offset偏移量。
Topic：类别，主题
每条发布到kafka集群的消息都属于一个类别，这个类别被称为Topic；
物理上：不同Topic的消息分开存储、
逻辑上：一个Topic的消息虽然保存于一个或多个Broker上，但用户只需指定消息的Topic，即可生产或消费数据，而不用关心数据存于何处。
用于划分message的逻辑概念，可以理解为message的类别，一个topic可以分布于多个broker上，其信息存于注册中心。
Partition：分区
每个topic至少有一个partion（即每个类别至少有一个分区），
这个topic在每个broker上有多个分区partion（或无分区partion）都是ok的，即随意。
生产环境中分区数只能增不能
Offset：偏移量，offset是message在partition中的编号，offset编号不跨partition。
partition中的消息是有序的，
偏移量记录在注册中心。
Topic和Partition
该图可以看到，消息是按照类别topic来提交到partition当中的。
Partition当中的消息是有序的，consumer从一个有序的分区消息队列中顺序获取消息。
相关名次定义如下：
1.Topic：用于划分Message的逻辑概念，一个Topic可以分布在多个Broker上。
2.Partition：是Kafka中横向扩展和一切并行化的基础，每个Topic都至少被切分为1个Partition。
3.offset:消息在Partition中的编号，编号顺序不跨Partition。
Replication：备份机制，每个分区partition都有自己的镜像分区来保证高可用，该分区和备份分区不在同一台物理机上。
其中一个分区为leader，若leader挂了则会选举新的leader。
Replica个数为所有分区的份数，如下4个partition，2个replica。
AR(Assigned Replicas)：所有已注册副本，AR = ISR + OSR。为保证高可用，参数offsets.topic.replication.factor设置大于1，比如3。
ISR(In-Sync Replicas)：副本同步队列，由leader维护，follower从leader同步数据有一些延迟(包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度,版本0.10.x中只支持replica.lag.time.max.ms这个维度) ，任意一个超过阈值都会把follower剔除出ISR, 存入OSR。
注：Kafka 0.10.x版本后移除了replica.lag.max.messages参数，只保留了replica.lag.time.max.ms作为ISR中副本管理的参数。为什么这样做呢？replica.lag.max.messages表示当前某个副本落后leaeder的消息数量超过了这个参数的值，那么leader就会把follower从ISR中删除。假设设置replica.lag.max.messages=4，那么如果producer一次传送至broker的消息数量都小于4条时，因为在leader接受到producer发送的消息之后而follower副本开始拉取这些消息之前，follower落后leader的消息数不会超过4条消息，故此没有follower移出ISR，所以这时候replica.lag.max.message的设置似乎是合理的。但是producer发起瞬时高峰流量，producer一次发送的消息超过4条时，也就是超过replica.lag.max.messages，此时follower都会被认为是与leader副本不同步了，从而被踢出了ISR。但实际上这些follower都是存活状态的且没有性能问题。那么在之后追上leader,并被重新加入了ISR。于是就会出现它们不断地剔出ISR然后重新回归ISR，这无疑增加了无谓的性能损耗。而且这个参数是broker全局的。设置太大了，影响真正“落后”follower的移除；设置的太小了，导致follower的频繁进出。无法给定一个合适的replica.lag.max.messages的值，故此，新版本的Kafka移除了这个参数。
OSR(Outof-Sync Replicas)：副本未同步队列，ISR中超过阈值的flower会被踢出ISR加入OSR，新加入的flower也会先存放在OSR。
HW(High Watermark)：高水位，每个replica都有自己的HW，replica中各partition对应ISR最小(越小越旧)的LEO作为HW，即最后commit的offset，consumer最多只能消费到HW所在的位置。
LEO(log end offset)：日志尾部偏移量，每个partition都有自己的LEO，是每个partition日志中的最后的offset，可能未被commit。
Coordinator：中心协调器，0.10.x版本及之后才有，为所有Consumer Group的子集选举出一个Broker作为Coordinator，由它来管理Consumer的增减，然后生成Rebalance命令，并检查是否这些Rebalance。
2.2 拓扑图
以下的组件在分布式环境中均可以是多个，
ZK仅和Broker和Customer有关。
Broker是无状态的，消费的状态依靠消费者维护partition的offset偏移量，message依靠消费者主动拉取。
Brokers中的Controller，主要负责Partition管理和副本状态管理，也会执行类似重分配partition之类的管理任务，如处理Partition的Leader选举等。
2.3 局部有序性
Producer从0开始生产，进入不同的分区按进入顺序从0开始排列，消费者从0开始消费，这就保证了单个分区的消息有序性，但无法保证全局有序性。
2.4 ZK存储结构
说明： 本人原创，后续会继续更新增加内容；
如有错误之处，敬请指出，不胜感谢，共同学习共同进步