（ 一 ）、Kafka 介绍
官方中文文档： https://kafka.apachecn.org/intro.html
3.0 文档: https://kafka.apache.org/documentation/
下载：https://kafka.apachecn.org/downloads.html
一、简介
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
二、Kafka的特性
- 高吞吐量、低延迟： kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。Kafka 在数据写入及数据同步采用了零拷贝（ zero-copy ）技术，采用sendFile()函数调用，sendFile ()函数是在两个文件描述符之间直接传递数据，完全在内核中操作，从而避免了内核缓冲区与用户缓冲区之间数据的拷贝，操作效率极高。Kafka 还支持数据压缩及批量发送，同时Kafka 将每个主题划分为多个分区，这一系列的优化及实现方法使得Kafka 具有很高的吞吐量。经大多数公司对Kafka 应用的验证， Kafka 支持每秒数百万级别的消息
- 可扩展性： kafka集群支持热扩展。Kafka 依赖ZooKeeper来对集群进行协调管理，这样使得Kafka 更加容易进行水平扩展，生产者、消费者和代理都为分布式，可配置多个。同时在机器扩展时无需将整个集群停机，集群能够自动感知，重新进行负责均衡及数据复制。
- 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。因为是顺序追加，所以Kafka 在设计上是采用时间复杂度O(1)的磁盘结构，它提供了常量时间的性能，即使是存储海量的信息（ TB 级）也如此。，性能和数据的大小关系也不大，同时Kafka 将数据持久化到磁盘上，这样只要磁盘空间足够大数据就可以一直追加，而不会像一般的消息系统在消息被消费后就删除掉， Kafka 提供了相关配置让用户自己决定消息要保存多久，这样为消费者提供了更灵活的处理方式，因此Kafka 能够在没有性能损失的情况下提供一般消息系统不具备的特性。
- 容错性： 允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）。
- 高并发：支持数千个客户端同时读写。
- 安全机制:
- 通过SSL 和SASL(Kerberos), SASL/PLA时验证机制支持生产者、消费者与代理连接时的身份认证。
- 支持代理与Zoo Keeper 连接身份验证。
- 通信时数据加密。
- 客户端读、写权限认证。
- Kafka 支持与外部其他认证授权服务的集成。
三、Kafka的使用场景：
- 消息系统：Kafka作为一款优秀的消息系统，具有高吞吐量、内置的分区、备份冗余分布式等特点，为大规模消息处理提供了一种很好的解决方案。
- 应用监控： 利用Kafka采集应用程序和服务器健康相关的指标，如CPU占用率、IO、内存、连接数、TPS、QPS等，然后将指标信息进行处理从而构建一个具有监控仪表盘、曲线图等可视化监控系统。例如，很多公司采用Kafka 与ELK (Elastic Search、Logstash和Kibana整合构建应用服务监控系统。
- 网站用户行为追踪： 为了更好地了解用户行为、操作习惯，改善用户体验，进而对产品升级改进，将用户操作轨迹、内容等信息发送到Kafka 集群上，通过Hadoop 、Spark 或Strom等进行数据分析处理，生成相应的统计报告，为推荐系统推荐对象建模提供数据源，进而为每个用户进行个性化推荐。
- 流处理： 需要将己收集的流数据提供给其他流式计算框架进行处理，用Kafka 收集流数据是一个不错的选择，而且当前版本的Kafka 提供了Kafka Streams 支持对流数据的处理。
- 持久性日志： Kafka 可以为外部系统提供一种持久性日志的分布式系统。日志可以在多个节点间进行备份， Kafka 为故障节点数据恢复提供了一种重新同步的机制。同时， Kafka很方便与HDFS 和Flume 进行整合，这样就方便将Kafka 采集的数据持久化到其他外部系统。
四、Kafka基本概念
l、主题
Kafka 将一组消息抽象归纳为一个主题（Topic），也就是说，一个主题就是对消息的一个分类。生产者将消息发送到特定主题，消费者订阅主题或主题的某些分区进行消费。
2、消息
消息是Kafka 通信的基本单位，由一个固定长度的消息头和一个可变长度的消息体构成。在老版本中，每一条消息称为Message ：在由Java 重新实现的客户端中，每一条消息称为Record 。
3、分区和副本
Kafka将一组消息归纳为一个主题，而每个主题又被分成一个或多个分区（Partition）。每个分区由一系列有序、不可变的消息组成，是一个有序队列。每个分区在物理上对应为一个文件夹，分区的命名规则为主题名称后接“一”连接符，之后再接分区编号，分区编号从0开始，编号最大值为分区的总数减l 。每个分区又有一至多个副本（Replica），分区的副本分布在集群的不同代理上，以提高可用性。从存储角度上分析，分区的每个副本在逻辑上抽象为一个日志（Log）对象，即分区的副本与日志对象是一一对应的。每个主题对应的分区数可以在Kafka启动时所加载的配置文件中配置，也可以在创建主题时指定。当然，客户端还可以在主题创建后修改主题的分区数。分区使得Kafka在井发处理上变得更加容易，理论上来说，分区数越多吞吐量越高，但这要根据集群实际环境及业务场景而定。同时，分区也是Kafka 保证消息被顺序消费以及对消息进行负载均衡的基础。Kafka 只能保证一个分区之内消息的有序性，并不能保证跨分区消息的有序性。每条消息被追加到相应的分区中，是顺序写磁盘，因此效率非常高，这是Kafka 高吞吐率的一个重要保证。同时与传统消息系统不同的是， Kafka 并不会立即删除已被消费的消息，由于磁盘的限制消息也不会一直被存储（事实上这也是没有必要的），因此Kafka提供两种删除老数据的策略，一是基于消息己存储的时间长度，二是基于分区的大小。这两种策略都能通过配置文件进行配置。
我们说 kafka 是一个分布式消息系统，所谓的分布式，实际上我们已经大致了解。消息保存在 Topic 中，而为了能够实现大数据的存储，一个 topic 划分为多个分区，每个分区对应一个文件，可以分别存储到不同的机器上，以实现分布式的集群存储。另外，每个 partition 可以有一定的副本，备份到多台机器上，以提高可用性。
总结起来就是：
- 一个 topic 对应的多个 partition 分散存储到集群中的多个 broker 上，存储方式是一个 partition 对应一个文件，每个 broker 负责存储在自己机器上的 partition 中的消息读写。
- 从整体考虑，有多少个 partition 就意味着会有多少个leader，kafka 会将 leader 分散到不同的 broker 上，确保整体的负载均衡。
4、Leader 副本和 Follower 副本
由于Kafka 副本的存在，就需要保证一个分区的多个副本之间数据的一致性，Kafka会选择该分区的一个副本作为Leader副本，而该分区其他副本即为Follower 副本，只有Leader 副本才负责处理客户端读／写请求， Follower 副本从Leader 副本同步数据。如果没有Leader 副本，那就需要所有的副本都同时负责读／写请求处理，同时还得保证这些副本之间数据的一致性，假设有n个副本则需要有n×n条通路来同步数据，这样数据的一致性和有序性就很难保证。引入Leader 副本后客户端只需与Leader 副本进行交互，这样数据一致性及顺序性就有了保证。Follower 副本从Leader 副本同步消息，对于n个副本只需n-1条通路即可，这样就使得系统更加简单而高效。副本Follower与Leader的角色并不是固定不变的，如果Leader 失效，通过相应的选举算法将从其他Follower 副本中选出新的Leader 副本。
5. 偏移量
任何发布到分区的消息会被直接追加到日志文件（分区目录下以＂.log”为文件名后缀的数据文件〉的尾部，而每条消息在日志文件中的位置都会对应一个按序递增的偏移量。偏移量是一个分区下严格有序的逻辑值，它并不表示消息在磁盘上的物理位置。由于Kafka几乎不允许对消息进行随机读写，因此Kafka 并没有提供额外索引机制到存储偏移量，也就是说并不会给偏移量再提供索引。消费者可以通过控制消息偏移量来对消息进行消费，如消费者可以指定消费的起始偏移量。为了保证消息被顺序消费，消费者己消费的消息对应的偏移量也需要保存。需要说明的是，消费者对消息偏移量的操作并不会影响消息本身的偏移量。旧版消费者将消费偏移量保存到ZooKeeper 当中，而新版消费者是将消费偏移量保存到Kafka 内部一个主题当中。当然，消费者也可以自己在外部系统保存消费偏移量，而无需保存到Kafka 中。
6、 代理
Kafka 集群就是由一个或多个Kafka 实例构成，我们将每一个Kafka 实例称为代理（ Broker ），通常也称代理为Kafka 服务器( KafkaServer ） 。每一个代理都有唯一的标识id，这个id是一个非负整数。在一个Kafka集群中，每增加一个代理就需要为这个代理配置一个与该集群中其他代理不同的id, id值可以选择任意非负整数即可，只要保证它在整个Kafka 集群中唯一，这个id 就是代理的名字，也就是在启动代理时配置的broker.id 对应的值。
7、生产者
生产者（ Producer ）负责将消息发送给代理，也就是向Kafka 代理发送消息的客户端。
8、消费者和消费组
消费者（ Comsumer ）以拉取（ pull ）方式拉取数据，它是消费的客户端。在Kafka中每一个消费者都属于一个特定消费组（ConsumerGroup ），我们可以为每个消费者指定一个消费组，以groupld 代表消费组名称，通过group.id 配置设置。如果不指定消费组，则该消费者属于默
认消费组test-consumer-group 。同时，每个消费者也有一个全局唯一的id ， 通过配置项client.id指定，如果客户端没有指定消费者的id, Kafka会自动为该消费者生成一个全局唯一的id，格式为${groupld}-${hostName}-${timestamp}-${UUID前8位字符｝。同一个主题的一条消息只能被同一个消费组下某一个消费者消费，但不同消费组的消费者可同时消费该消息。消费组是Kafka用来实现对一个主题消息进行广播和单播的手段，实现消息广播只需指定各消费者均属于不同的消费组，消息单播则只需让各消费者属于同一个消费组。
9、 ISR
Kafka 在ZooKeeper 中动态维护了一个ISR (In-sync Replica ），即保存同步的副本列表，该列表中保存的是与Leader副本保持消息同步的所有副本对应的代理节点id。如果一个Follower副本岩机，则该Follower副本节点将从ISR 列表中移除。
10、 ZooKeeper
这里我们并不打算介绍ZooKeeper 的相关知识，只是简要介绍ZooKeeper 在Kafka 中的作用。Kafka 利用ZooKeeper 保存相应元数据信息， Kafka 元数据信息包括如代理节点信息、Kafka集群信息、旧版消费者信息及其消费偏移量信息、主题信息、分区状态信息、分区副本分配方案信息、动态配置信息等。Kafka 在启动或运行过程当中会在ZooKeeper上创建相应节点来保存元数据信息，Kafka通过监昕机制在这些节点注册相应监听器来监昕节点元数据的变化，从而由ZooKeeper负责管理维护Kafka集群，同时通过ZooKeeper我们能够很方便地对Kafka集群进行水平扩展及数据迁移。
通过以上Kafka 基本概念的介绍，我们可以对Kafka 基本结构图进行完善，如图1-2 所示：
（1）数据生产过程（Produce）
对于生产者要写入的一条记录，可以指定四个参数：分别是 topic、partition、key 和 value，其中 topic 和 value（要写入的数据）是必须要指定的，而 key 和 partition 是可选的。
对于一条记录，先对其进行序列化，然后按照 Topic 和 Partition，放进对应的发送队列中。如果 Partition 没填，那么情况会是这样的：1、Key 有填。按照 Key 进行哈希，相同 Key 去一个 Partition。 2、Key 没填。Round-Robin 来选 Partition。
producer 将会和Topic下所有 partition leader 保持 socket 连接，消息由 producer 直接通过 socket 发送到 broker。其中 partition leader 的位置( host : port )注册在 zookeeper 中，producer 作为 zookeeper client，已经注册了 watch 用来监听 partition leader 的变更事件，因此，可以准确的知道谁是当前的 leader。
producer 端采用异步发送：将多条消息暂且在客户端 buffer 起来，并将他们批量的发送到 broker，小数据 IO 太多，会拖慢整体的网络延迟，批量延迟发送事实上提升了网络效率。
（2）数据消费过程（Consume）
对于消费者，不是以单独的形式存在的，每一个消费者属于一个 consumer group，一个 group 包含多个 consumer。特别需要注意的是：订阅 Topic 是以一个消费组来订阅的，发送到 Topic 的消息，只会被订阅此 Topic 的每个 group 中的一个 consumer 消费。
如果所有的 Consumer 都具有相同的 group，那么就像是一个点对点的消息系统；如果每个 consumer 都具有不同的 group，那么消息会广播给所有的消费者。
具体说来，这实际上是根据 partition 来分的，一个 Partition，只能被消费组里的一个消费者消费，但是可以同时被多个消费组消费，消费组里的每个消费者是关联到一个 partition 的，因此有这样的说法：对于一个 topic,同一个 group 中不能有多于 partitions 个数的 consumer 同时消费,否则将意味着某些 consumer 将无法得到消息。
同一个消费组的两个消费者不会同时消费一个 partition。
消息传送机制
Kafka 支持 3 种消息投递语义,在业务中，常常都是使用 At least once 的模型。
- At most once：最多一次，消息可能会丢失，但不会重复。
- At least once：最少一次，消息不会丢失，可能会重复。
- Exactly once：只且一次，消息不丢失不重复，只且消费一次