文章目录
基本结构
Zookeeper是Kafka用来负责集群元数据的管理、控制器的选举等操作，Producer将消息发送到Broker，Broker负责将收到的消息存储到磁盘中，Consumer负责从Broker订阅并消费消息。
#基本概念
主题（Topic）
Kafka将一组消息抽象归纳为一个主题，一个主题是对消息的一个分类，生产者将消息发送到特定主题，消费者订阅主题或主题的某些分区进行消费。
主题是一个存储消息的逻辑概念，可以认为是一个消息的集合，每条消息发送到Kafka集群的消息都有一个类别。物理上，不同的主题消息是分开存储的，每个主题可以有多个生产者向他发送消息，也可以有多个消费者去消费其中的消息。
消息
消息是Kafka通信的基本单位，由固定长度的消息头和一个可变长度的消息体构成。
分区和副本
Kafka将一组消息归纳为一个主题，而每个主题又被分为一个或多个分区，每个分区由一系列有序不可变的消息组成，是一个有序队列。
每个分区在物理上对应一个文件夹，分区的命名规则为主题名称后接-连接符，之后在接分区编号，分区编号从0开始，编号最大值为分区的总数减1。每个分区又有一至多个副本，分区的副本分布在集群的不同代理商，提高可用性。
从存储角度上分析，分区的每个副本在逻辑上抽象为一个日志对象，即分区的副本与日志对象是一一对应，每个主题对应的分区可以在Kafka启动是所加载的配置文件中配置，也可以在穿件主题时指定，也可以在客户端主题创建后修改主题分区数。
分区使Kafka在并发处理上变得更加容易，理论上来说，分区数越多吞吐量越高，这要根据集群实际环境及业务场景而定，同时，分区也是Kafka保证消息被顺序消费以及对消息进行负载均衡的基础。
Kafka只能保证一个分区之内消息的有序性，并不能保证扩分区消息的有序性，没跳消息被追加到响应的分区中是顺序写磁盘，因此效率非常高，这是Kafka高吞吐量的一个重要保证。同时与传统消息系统不同的是，Kafka并不会立即删除已被消费的消息，由于磁盘的限制消息也不会一直被存储，因此Kafka提供两种删除老数据的策略。一是基于消息一存储的时间长度，二十基于分区的大小。这两种策略能通过配置文件进行配置。
Leader副本和Follower副本
由于Kafka副本的存在，就需要保证一个分区的多个副本之间数据的一致性，Kafka会选择该分区的一个芬苯作为Leader副本，而该分区其他副本既为Follower副本，只有Leader副本才负责处理客户端读写请求，Follower副本从Leader副本同步数据。如果没有Leader副本，那么久需要所有的副本都同时负责读写请求处理，同时还得保证这些副本之间数据的一致性，假设有n个副本则需要有nXn条通路来同步数据，这样数据的一致性和有序性就很难保证。
引入Leader副本后客户端只需与Leader副本进行交互，这样数据一致性与顺序性就有了保证。Follower副本从Leader副本同步消息，对于n个副本秩序n-1条通路即可这样就是的系统更加简单而高效。副本Follower与Leader的角色并不是固定不变的，如果Leader失效，通过响应的选举算法将从其他Follower副本中选出新的Leader副本。
偏移量
任何发布到分区的消息会被直接追加到日志文件（分布目录下以.log为文件名后缀的数据文件）的尾部，而每条消息在日志文件中的位置都会对应一个按序递增的偏移量。偏移量是一个分区下严格有序的逻辑值，它并不表示消息在磁盘上的物理位置。由于Kafka几乎不允许对消息进行随机读写，因此kafka并没有提供额外索引机制到存储偏移量，也就是说并不会给偏移量在提供索引。消费者可以通过控制消息偏移量来对消息进行消费，如果消费者可以指定消费的起始偏移量。为了保证消息被顺序消费，消费者已消费的消息对应的偏移量也需要保存。消费者对消息偏移量的操作并不会影响消息本身的偏移量。旧版消费者将消费偏移量保存到ZooKeeper当中，而新版本消费者将消息偏移量保存到Kafka内部一个主题当中。
日志段（LogSegment）
一个日志又被划分为多个日志段，日志段是kafka日志对象分片的最小单位。与日志对象一样，日志段也是一个逻辑概念，一个日志段对应磁盘上一个具体日志文件和两个索引文件。日志文件以.log为文件名后缀的数据文件，用于保存消息实际数据。两个索引文件分为以.index和.timeindex作为文件名后缀，分别表示消息偏移量索引文件和消息时间戳索引文件。
代理（Broker）
Kafka集群是由一个或多个Kafka实例构成，我们将每一个Kafka实例称为代理。在生产环境中Kafka集群一般包括一台或多台服务器，我们可以在一台服务器上配置一个或多个代理。每一个代理都有唯一的标识id，这个id是一个非负数证书。在一个Kafka集群中，没增加一个dialing就需要在这个代理配置一个与该急群众其他代理不同的id，id值可以选择任意非负数证书即可，只要保证他在整个Kafka急群众唯一，这个id就是代理的名字，也就是在启动代理时配置的broker.id对应的值。由于给每个代理分配了不同的brokerId，这样对代理进行迁移就变得更方便，从而对消费者来说是同名的，不会影响消费者对消息的消费。
生产者（Producer）
生产者负责将消息发送给代理，也就是想Kafka代理发送消息的客户端。
消费者和消费组
消费者以拉取方式拉取数据，他是消费的客户端。每一个消费者都属于一个特定的消费组，可以为每个消费者指定一个消费组，以groupid代表消费组名称，通过group.id配置设置。如果不指定消费组，则该消费者属于默认消费组test-consumer-group。每个消费者也有一个全局唯一的id，通过配置项client.id指定，如果客户端没有指定消费者的id，Kafka会自动为该消费者生成一个全局唯一的id，格式为${groupId}-${hostName}-${timestamp}-${UUID钱8位字符}。同一个主题的一条细细只能被同一个消费组下某一个消费者消费，单不同消费组的消费者可同时消费该消息。消费组是kafka用来实现对一个主题消息进行广播和单播的手段，实现消息刚播只需指定各消费者均属于不同的消费组，消息单播则只需让各消费者属于同一个消费组。
ISR
Kafka在ZooKeeper中动态维护一个ISR，即保存同步的副本列表，该列表中保存的是Leader副本保持消息同步的所有副本对应的代理节点id。如果一个Follower副本宕机或是落后太多，则该Follower副本节点将从ISR列表中一出。
ZooKeeper
Kafka利用Zookeeper保存响应预案数据信息，Kafka元数据信息包括代理节点信息、Kafka集群信息、旧版消费者信息以及其消费偏移量信息、主题信息、分区状态信息、分区副本分配方案信息、动态配置信息等。Kafka通过监听机制在这些节点注册响应监听器来监听节点元数据变化，从而由ZooKeeper负责管理维护Kafka集群，同事通过Zookeeper能够很方便的对Kafka集群进行水平扩展及数据迁移。
特性
消息持久化
消息系统数据持久化一般采用为每个消费者队列提供一个B树或其他通用的随机访问数据结构来维护消息的元数据，B树操作的时间复杂度为O(log n)，O(log n)的时间复杂度可以看成是一个常量时间，而且B树可以支持各种各样的事务性和费事务性语义消息的传递。尽管B树具有这些优点，单这并不适合磁盘操作。目前的磁盘寻道时间一般在10ms以内，堆一块磁盘来说，在同一时刻只能有一个磁头来读写磁盘，这样在并发IO能力上就有问题。同时，对树结构性能的观察结果表明：其性能会随着数据的增长而线性下降。鉴于消息系统本身的作用考虑，数据的持久化队列可以建立在简单地对文件进行追加的实现方案上。因为是顺序追加，所以Kafka在设计上是采用时间复杂度O(1)的磁盘结构，他提供了常量时间的性能，即使是存储海量的信息(TB级)也如此，性能和数据的大小关系也不大，同事Kafka将数据持久化到磁盘上，这样只要磁盘空间足够大数据就可以一直追加，而不会像一般的消息系统在消息被消费后删除，Kafka提供了相关配置让用户自己决定消息要保存多久，这样为消费者提供了更灵活的处理方式。
由于Kafka将消息进行持久化，使得kafka在机器重启后，已存储的消息可继续回复使用。同时Kafka能够很好地支持在线或离线处理、与其他存储及流处理框架的集成。
高吞吐量
高吞吐量是Kafka设计的主要目标，Kafka将数据卸载磁盘，充分利用磁盘的顺序读写。同时，Kafka在数据写入及数据同步采用了零拷贝技术，采用sendFile()函数调用，sendFile()函数是在两个文件描述符之间直接传递数据，完全在内核中操作，从而避免了内核缓冲区与用户缓冲区之间数据的拷贝，操作效率极高。Kafka还支持数据压缩及批量发送，同事Kafka将每个主题划分为多个分区，这一系列的游湖及实现方法使得Kfaka具有很高的吞吐量。
扩展性
Kafka要支持对大规模数据的处理，就必须能够对集群进行扩展，分布式必须是其特性之一，这样就可以将多台廉价的PC服务器搭建成一个大规模的消息系统。Kafka依赖ZooKeeper来对集群进行协调管理，这样使得Kafka更加容易进行水平扩展，生产者、消费者和代理都为分布式，可以配置多个。同事在机器扩展时无需将整个集群停机，集群能够自动感知，重新进行负责均衡及数据复制。
多客户端支持
Kafka核心模块用Scala语言开发，单Kafka支持不同语言开发生产者和消费者客户端应用程序。Kafka提供了多种开发语言的接入，如Java、Scala、C、C++、Python、Go、Erlang、Ruby、Nodejs等。Kafka支持多用连接器的接入，也提供了Connector API供开发者调用。Kafka与当前主流的大数据框架都能够很好的集成。
Kafka Streams
Kafka Streams是一个用Java语言实现的用于流处理的jar文件。
安全机制
- 通过SSL和SASL，SASL/PLAIN验证机制支持生产者、消费者和代理连接时的身份认证。
- 支持代理与ZooKeeper连接身份验证。
- 通信时数据加密。
- 客户端读、写权限认证。
- Kafka支持与外部其他认证授权服务集成。
数据备份
Kafka可以为每个主题指定副本数，对数据进行持久化备份，这可以易订程度上防止数据丢失，提高可用性。
轻量级
Kafka的代理是无状态的，即代理不记录消息是否被消费，消息偏移量的管理交由消费者自己活组协调器来维护。同事集群本身几乎不需要生产者和消费者的状态信息，这就使得Kafka非常清凉，同事生产者和消费者客户端实现也非常轻量级。
消息压缩
Kafka支持Gzip、Snappy、LZ4这三种压缩方式，通常把多条消息放在一起组成MessageSet，然后在把MessageSet放在一条消息里面去，从而提高压缩比率进而提高吞吐量。
应用场景
- 消息系统。Kafka作为一款优秀的消息系统，具有高吞吐量、内置的分区、备份冗余分布式等特点，为大规模消息处理提供了一种很好的解决方案。
- 用用监控。利用Kafka采集应用程序和服务器健康相关的指标，如CPU占用率、IO、内存、连接数、TPS、QPS等，然后将指标信息进行处理，从而构建一个具有监控仪表盘、曲线图等可视化监控系统。
- 网站用户行为追踪。为了更好的了解用户行为、操作习惯，改善用户体验，进而对产品升级改进，将用户操作轨迹、内容等信息发送到Kafka集群上，通过Hadoop、Spark或Strom等进行数据分析处理，生成响应的统计报告，为推荐系统推荐对象建模提供数据源，进而为每个用户进行个性化推荐。
- 流处理。需要将已收集的流数据提供给其他流式计算框进行处理。
- 持久化日志。Kafka可以为外部系统提供一种持久化日志的分布式系统。日志可以在多个节点间进行备份，Kafka为故障节点数据恢复提供了一种重新同步的机制。同事Kafka很方便与HDFS和Flume进行整合，这样就方便将Kafka采集的数据持久化道其他外部系统。