kafka并不难学---学习笔记

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/lwglwg32719/article/details/86510029

1. 在kafka系统中，核心组件的元数据信息均存储在zookeeper中。这些元数据信息具体包含：控制器选举次数、代理节点和主题、配置、管理员操作、控制器。他们在zookeeper系统中的分布如图所示：
   1. 控制器选举次数，在kafka系统中，控制器每进行一次选举次数，都会在zk系统/controller_epoch节点下进行记录，该值作为一个数字。在kafka集群中，第一个代理节点（broker）启动时，该值为1。在kafka集群中，如果遇到代理节点宕机或者变更，则kafka集群会重新选举新的控制器。每次控制器发生变化时，zk系统/controller_epoch节点中的值就会加1。
   2. 在zk系统中，元数据存储的格式为“英文斜杠+英文名称”，例如：/admin。通常会将这种存储类型称之为节点，如“/admin 节点”
   3. 代理节点和主题
      1. 在zk系统/brokers节点中，存储着kafka代理节点和主题的元数据信息
      2. 在zk系统中/brokers/ids节点中，存储着代理节点的ID值
      3. 在zk系统/brokers/topics节点中，存储着主题和分区的元数据信息
   4. 配置，在kafka系统中，修改主题属性这类操作会被存储到zk系统/config节点中。/config节点主要包含以下三个子节点
      1. Topic：存储着kafka集群主题的额外属性，比如修改过主题的属性操作
      2. Client：存储着客户端和主题配置信息，包含消费者应用和生产者应用
      3. Changes：存储着修改信息
   5. 管理员操作，在执行管理员操作（比如删除、分配等）时，在zk系统/admin节点会生成相应的子节点
      1. Delete_topics：存储着待删除主题名的标记
      2. Reassign_partitions：存储着重新分配分区操作的命令
      3. Preferred_replica_election：存储着恢复leader分区平衡操作的命令
   6. 控制器，在kafka系统正常运行时，在zk系统/controller节点下会存储一个kafka代理节点的ID值。该ID值与kafka代理节点ID相同，标识代理节点上存在控制器功能
2. 控制器，其实就是kafka系统的一个代理节点。它除了具有一般代理节点的功能外，还具有选举主题分区leader节点的功能。只有当代理节点上存在控制器的时候才具有这种功能。在启动kafka系统时，其中一个代理节点broker会被选举为控制器，负责管理主题分区和副本状态，还会执行分区重新分配的管理任务；在kafka系统运行过程中，如果当前的控制器出现故障导致不可用，则kafka系统会从其他正常运行的代理节点重新选举出新的控制器。
   1. 控制器的启动顺序，在kafka集群中，每个代理节点（broker）在启动时会实例化一个kafkacontroller类。该类会执行一系列业务逻辑，选举出主题分区的leader节点。具体选举分区leader节点的步骤如下：
      1. 第一个启动的代理节点会在zk系统里面创建一个临时节点/controller，并写入该节点的注册信息，使该节点成为控制器
      2. 其他的代理节点陆续启动时，也会尝试在zk系统里面创建/controller节点。但是由于/controller节点已经存在，所以会抛出异常。确保kafka集群控制器的唯一性
      3. 其他代理节点，会在控制器注册相应的监听器。各个监听器负责监听各自代理节点的状态变化，当监听到节点状态发生变化时，会触发相应的监听函数进行处理
   2. 查看控制器创建的优先级，控制器创建的优先级是按照kafka系统代理节点成功启动的顺序来创建。
   3. 切换控制器所属的代理节点，当控制器被关闭或者与zk系统断开连接时，zk系统上的临时节点就会被清除。Kafka集群中的监听器会接收到变更通知，各个代理节点会尝试到zk系统中创建一个控制器的临时节点。
   4. 选举控制器的核心思想是：各个代理节点公平竞抢在zk系统中创建/controller临时节点，最先创建成功的代理节点会成为控制器，并拥有选举主题分区leader节点的功能

1. 1. 1. Kafkacontroller类的作用，kafkacontroller类在实例化zookeeperLeaderElector类时，分别设置了两个关键的回调函数----oncontrollerfailover和oncontrollerresignation。在oncontrollerfailover回调函数中初始化leader依赖模块，包括在zk系统中递增控制器选举次数。当kafka系统当前代理节点不再是leader角色时，会触发oncontrollerresignation回调函数重新进行注册选举。Kafkacontroller类启动后，会向zk系统注册会话超时监听器，并尝试选举leader
      2. Zookeeperleaderelector类实现了主题分区的leader节点选举功能，但是它并不会处理“代理节点与zk系统之间出现会话超时”这种情况。Zookeeperleaderelector类主要负责创建元数据存储路径、实例化变更监听器，并通过订阅数据变更监听器来实时监听数据的变化，进而开始执行选举leader的逻辑。Zookeeperleaderelector类完成选举前的准备工作后，开始执行startup()函数来订阅数据变化监听器，同时调用elect方法来执行选举leader的逻辑。通常情况下，触发elect方法的条件有以下几点：1.代理节点启动2.在上一次创建临时节点成功后，由于网络原因或服务器故障等导致连接中断。然后调用resign()函数并删除zk系统中的/controller节点3. 在上一次创建临时节点成功后，由于网络原因或服务器故障等导致连接中断。再次进入elect方法，发现kafka系统中已经有代理节点成了leader4.在上一次创建临时节点成功后，在执行onbecoingleader函数时抛出异常信息，执行业务逻辑后，再尝试选举leader
      3. Kafka系统的控制器主要负责管理主题、分区和副本。Kafka系统在操作主题、分区和副本时，控制器会在zk系统的/broker/topic节点，以及其子节点路径上注册一系列的监听器。使用kafka应用接口或者是kafka系统脚本创建一个主题时，服务端会将创建后的结果返回给客户端。当客户端收到创建成功的提示时，其实服务端并没有实际创建主题，而只是在zk系统的/brokers/topics节点中创建了该主题对应的子节点名称，之后服务端以异步的方式来创建主题。当服务端完成主题创建操作后，可以去￥KAFKA_HOME/data中查看实际的数据，或者访问zk系统查看元数据
2. 管理主题
   1. 在kafka系统中，kafka-topics.sh脚本用来管理主题（topic），例如创建主题、查看主题、修改主题、删除主题等
   2. Kafka系统中的数据最终还需要保存到磁盘进行持久化。为了区分不同的业务数据，数据库会有命名空间（即：数据库名），每个命名空间下又有若干个表。将不同类型的消息数据按一定的规则进行分类，最后将相同类型的业务数据存储到同一个主题中
3. 管理分区与副本
   1. 主题是一个逻辑概念，而分区则是一个物理概念
   2. 分区的背景，用户在调用生产者接口时，只需要关心将消息数据发送到哪个主题
   3. 分区的作用，从性能方面来说，如果主题内消息数据值存储在一个代理节点，那该节点将很快会成为kafka集群的瓶颈，无法实现水平扩展。主题上的每个分区可以被认为是一个无限长度的数组，新来的消息数据可以有序地追加到该数组上。从物理意义上讲，每个分区对应一个文件夹。一个kafka代理节点上可以存放多个分区。在kafka系统中，主题的分区只能增加不能减少。
4. Kafka生产者
   1. Kafka系统中有四种核心应用接口-----生产者 消费者 数据流 连接器
   2. Kafka系统支持两种不同的发送方式----同步模式（sync）和异步模式（async）
      1. 异步模式，生产者客户端在通过异步模式发送消息时，通常会调用回调函数的send（）方法发送消息。生产者端收到kafka代理节点的相应后会触发回调函数
      2. 异步模式数据写入流程，生产者客户端写入一条消息记录时，消息记录会先写入某个缓冲区，生产者客户端直接得到结果（这时，缓冲区的数据并没有写道kafka代理节点中主题的某个分区）。之后，缓冲区中的数据会通过异步模式发送到kafka代理节点中主题的某个分区中。send方法负责将缓冲池中的消息异步的发送到broker的指定topic中。异步发送是指，方法将消息存储到底层待发送的I/O缓存后，将立即返回，这可以实现并行无阻塞的发送更多消息。send方法的返回值是RecordMetadata类型，它含有消息将被投递的partition信息，该条消息的offset，以及时间戳。因为send返回的是Future对象，因此在该对象上调用get()方法将阻塞，直到相关的发送请求完成并返回元数据信息；或者在发送时抛出异常而退出。

1. 1. 1. 同步模式的数据写入流程，生产者客户端写入一条消息记录到生产者服务端，生产者服务端接收到数据后会立马将其发送到主题的某个分区，然后才将结果返回给生产者客户端

1. 1. 1. 多线程发送消息，在kafka系统中，为了保证生产者客户端应用程序的独立运行，通常使用线程的方式发送消息。如果希望发送完消息后获取一些返回消息（比如获取消息的偏移量、分区索引值、提交的时间戳等），则可以通过回调函数callback返回的recordmetadata对象来实现。由于kafka系统的生产者对象是线程安全的，所以，可通过增加生产者对象的线程数提高kafka系统的吞吐量
2. 保存对象的各个属性-----序列化
   1. 在分布式环境下，无论哪种格式的数据都会被分解成二进制，以便存储在文件中或者在网络上传输。序列化就是，将对象以一连串的字节进行描述，用来解决对象在进行读写操作时所引发的问题。序列化可以将对象的状态写成数据流，并进行网络传输或者保存在文件或数据库中，在需要时再把该数据流读取出来，重新构造一个相同的对象。
3. 自定义主题分区
   1. 在分布式应用场景中，kafka系统默认的分区策略并不能很好地满足业务需求，这时需根据kafka系统提供的应用接口来定义主题分区，以满足具体的业务场景需求
4. Kafka消费，kafka消费者可以理解成，外界从kafka系统中获取消息数据的一种应用接口。消费者应用接口的主要作用是读取消息数据
   1. 消费者和消费者组的区别，
      1. 一个消费者组，可以有一个或者多个消费者程序
      2. 消费者组名（groupid）通常由一个字符串表示，具有唯一性
      3. 如果一个消费组订阅了主题，那么该主题中的每个分区只能分配给某一个消费组中的某一个消费者程序
   2. 消费者和分区的对应关系。Kafka消费者是消费者组中的一部分。当一个消费者组中存在多个消费者程序来消费主题中的消息数据时，每个消费者程序会读取不同分区上的消息数据
   3. 消费者客户端可以通过消费者组中消费者程序的个数来进行水平扩展，提升读取主题消息数据的能力。因此在kafka系统生产环境中，建议在创建主题时给主题分配多个分区，这样可以提高读取的性能。消费者程序的数量尽量不要超过主题的最大分区数，因此，多出来的消费者程序是空闲的，不仅没有任何帮助，反而浪费系统资源
   4. 在kafka系统中，消费者组是一个全局概念，具有唯一性。在kafka0.10.0.x之前的版本中，kafka系统默认的消费方式是将消费实例产生的元数据信息存储到zk集群中，而之后的版本中，kafka系统默认将消费实例产生的元数据信息存储到一个名为“__consumer_offsets”的内部主题中
   5. Kafka0.10.0.x之前的版本中，使用zk集群来存储元数据信息是存在比较大的风险的：
      1. 虽然java虚拟机帮助系统完成一些优化操作，但是消费者程序频繁地与zk机器发生写交互，不仅性能低，而且后期水平扩展也比较困难
      2. 如果写元数据期间zk机器的性能降低，则kafka集群的吞吐量也跟着受影响
   6. 消费者新接口的实现原理
      1. 利用kafka系统的内部主题，以消费组（group）、主题（topic）和分区（partition）作为组合键，所有消费者程序产生的偏移量（offsets）都会提交到该内部主题中进行存储
      2. 由于消费者程序产生的这部分数据非常重要，不能丢失，所以将消息数据的应答（acks）级别设置为-1.这样，数据安全性虽然极好，但是其读取速度却有所下降。为了解决读取速度慢的问题，kafka系统又在内存中构建了一个三元数组来维护最新的偏移量信息，这个三元数组由 组、主题、分区组成。消费者程序可以直接从内存中获取最新的偏移量值
   7. 消费者新接口的协调器
      1. 在kafka0.10.0.x及之后的版本中，消费者程序不再依赖zk系统，启动后的消费者程序由消费者组协调器（groupcoordinator）统一管理。每个消费者组只负责管理一部分消费者组，而不是全部消费者组
      2. 消费者组协调器的主要作用
         1. 记录消费者组的信息
         2. 通过心跳消息检测消费者的状态
         3. 按照joingrouprequest请求和syncgrouprequest请求来制定消费者组中的分配策略
         4. 维护消费者程序产生的偏移量信息

1. 1. 消费kafka集群中的主体消息
      1. Kafkaconsumer是非多线程并发安全的：如果多个线程公用一个kafkaconsumer实例，则抛出异常错误信息
      2. 自动获取分区，如果调用subscribe函数订阅主题，则消费者组中的消费者程序会被动态分配到分区，同时被指定一个comsumerrebalancelistener接口。当用户分配给消费者程序的分区集合发生变化时，可以通过回调函数的接口来触发自定义操作
      3. 手动分配分区，手动分配分区的方式可以通过assign函数来实现，assign函数与subscribe函数的底层实现逻辑类似，也是先做一系列的检查工作，比如，是否含有并发操作、请求的参数是否合法（分区是否为空）等。消费者接口提供的两种订阅主题的方法是互斥的，用户只能选择其中的一种
      4. 序列化和反序列化
      5. 如何提交消息的偏移量
         1. 自动提交，enable.auto.commit设置为true，另外可以设置auto.commit.interval.ms属性来控制自动化提交的时间间隔，流程如下：

1. 1. 1. 1. 手动提交，同步提交和异步提交
2. 存储及管理数据
   1. Kafka系统存储有关的6个概念
      1. 代理节点（broker）kafka机器组件的最小单位，消费中间件的代理节点
      2. 主题（topic）：用来区分不同的业务消息，类似于数据库中的表
      3. 分区：是主体物理意义上的分组。一个主题可以分为多个分区，每个分区是一个有序的队列
      4. 片段（segment）每个分区又可以分为多个片段文件
      5. 偏移量（offset）每个分区都由一系列有序的、不可修改的消息组成，这些消息被持续追加到分区中，分区中的每条消息记录都有一个连续的序号，即offset值，offset值用来表示这条消息的唯一性
      6. Message 是kafka系统中文件的最小存储单位
   2. 分区文件存储，在kafka系统中，一个主题下包含多个不同分区，每个分区为单独的一个目录。分区的命名规则为：主题名+有序序号。第一个分区的序号从0开始，序号最大值等于分区总数减一
      1. 每个分区相当于一个超大的文件被均匀分割成的若干个大小相等的片段，但是每个片段的消息数据量不一定相等，因此，过期的片段数据才能被快速地删除
      2. 片段文件存储，片段文件由所有文件和数据文件组成：后缀为”.index”的是索引文件，后缀为”.log“的数据文件。Kafka系统中，索引文件并没有给数据文件中的每条消息记录都建立索引，而是采用了稀疏存储的方式----每隔一定字节的数据建议一个索引
      3. 消息的格式，普通日志中的每一条记录以”\n“结尾（或者通过其他特殊的分隔符来拆分）。这种方式对于文本来说比较适合，但对kafka系统来说，需要的是一种二进制格式。Kafka系统使用了一种经典的消息格式----消息中的前几个固定长度的字节用来记录这条消息的大小（单位为byte）

1. 1. Kafka系统提供了两种清除过期消息数据的策略
      1. 基于时间和大小的删除策略
      2. 压缩（compact）清理策略，压缩清楚只能针对特定的主题应用，即，写的消息数据都包含key，他会合并相同key的消息数据，只留下最新的消息数据
   2. Kafka系统作为一个消息队列，设计的网络通信主要包含以下两个方面
      1. Pull 消费者从消息队列中拉取消息数据
      2. Push生产者网消息队列中推送数据
      3. Kafka采用TCP协议作为服务间的通信协议
      4. 基本数据类型：
         1. 定长性数据类型 int8 int16 int32 int64 对应java就是byte short int long
         2. 可变数据类型  如map list
         3. 数组 int[] string[]
      5. 通信模型，采用的是reactor模型多线程模型，即通过一个acceptor线程处理所有的新连接，通过多个processor线程对请求进行处理（如解析协议、封装请求、转发等）。Reactor是一种事件模型，可以将请求提交到一个或者多个服务程序中进行处理，当收到客户端请求后，服务端处理程序使用多路分发策略，有一个非阻塞的线程来接受所有的请求，然后将这些请求转发到对应的工作线程中进行处理

1. 1. 1. 通信过程，在0.10.0.x版本之前，以NIO作为网络通信的基础。通过将多个socker连接注册到一个selector上进行监听，只用一个线程就管理多个连接，这极大地节省了多线程的资源开销；以后的版本依然是以NIO作为网络通信的基础，也使用了reactor多线程模型，但是不同的是，新版本将具体的业务处理模块独立出去了，并且用单独的线程池进行控制，具体如下

1. 1. 1. 1. 客户端向服务器发送请求时，acceptor负责接收tcp请求，连接成功后传递给processor线程；
         2. Processor线程接收到新连接后，将其注册到自身的selector中，并监听read事件
         3. 当客户端在当前连接对象上写入数据时，会触发read时间，根据tco协议调用handler进行处理
         4. Handler处理完成后，可能会有返回值给客户端，并将handler返回的结果绑定到响应端进行发送
         5. 将handler模块独立出来的好处：能够单独指定handler的线程数，便于调优和管理；防止一个过大的请求阻塞一个processor线程；请求、handler、响应之间都是通过队列来进行连接的，这样他们彼此不存在耦合现象，对提升系统的性能有帮助
2. Kafka安全机制
   1. 身份验证，在kafka系统中，身份验证是指，客户端在连接服务端时需要确认身份，整个认证范围包括：
      1. 客户端和kafka代理节点之间的连接认证
      2. 代理节点与代理节点之间的连接认证
      3. 代理节点与zk系统之间的连接认证
      4. 当前kafka系统支持多种认证机制：SSL、SASL/Kerberos、SASL/PLAIN、SASL/SCRAM
   2. 权限控制，是指对客户端操作（如读、写、删、改等）kafka集群主题进行权限控制。Kafka系统中的权限控制是可插拔的，并且支持与外部授权服务进行集成
   3. SSL协议进行加密和身份验证

1. 1. 1. SSL协议（secure socket layer），主要为网络通信提供安全保障。SSL协议利用数据加密技术，确保数据在网络中传输数据不会被截取和窃听。SSL协议介于传输层协议和应用层协议之间，分为两层：
         1. 记录协议：建立在可靠的传输层协议之上，提供数据封装、压缩、加密等功能
         2. 握手协议：建立在记录协议之上，用于在实际传输数据之前，确认通信双方的身份
      2. SSL协议提供的主要服务如下：
         1. 认证客户端和服务端，确保数据发送到正确的客户端和服务器上
         2. 对数据进行加密，防止数据在传输中被窃取
         3. 确保数据的完整性，保证数据在传输的过程中不被篡改
      3. Kerberos一个用于安全认证的第三方协议。它采用了传统共享密钥的方式，实现了在网络环境中（并不要求所处的网络环境是安全的）客户端与服务端之间的通信，适用于C/S模型
      4. PLAIN一种简单的用户名/密码认证机制，通常使用TLS（transport layer security）来加密实现安全认证
      5. SCRAM:SASL协议的一种，通过执行用户名和密码认证来解决安全问题
      6. JCE javaCryptography extension是一个框架包，其中提供了用于实现加密、密钥创建、消息认证码算法的框架
   2. 权限控制
      1. Kafka系统自带一个可插拔的授权程序，并使用zk系统来存储所有的ACL（access control list，访问控制表，一般用于限制网络流量、提高网络性能和网络安全）。授权程序通过在kafka系统文件server.properties中设置相关属性来进行权限控制
2. 用kafka连接器建立数据通道
   1. Kafka连接器是kafka系统与其他系统之间实现功能扩展、数据传输的工具
   2. Kafka连机器通常用来构建数据管道，一般有两种使用场景
      1. 开始和结束的端点，将kafka系统作为数据管道的开始和结束的端点

1. 1. 1. 数据传输的中间介质

1. 1. 特性和优势
      1. Kafka包含以下特性：
         1. 是一种处理数据的通用框架
         2. 提供单机模式和分布式模式
         3. 提供rest接口
         4. 自动管理偏移量
         5. 分布式和可扩展
         6. 数据流和批量集成
      2. 优势
         1. 连接器分为两种：source连接器：负责将数据导入到kafka系统；sink连接器：负责将数据从kafka系统中导出
         2. 在处理数据时，source连接器和sink连接器会初始化各自的任务，并将数据结构进行标准化的封装。在实际应用中，不同业务的数据格式是不一样的，kafka连接器可以通过注册数据结构来解决数据格式验证和兼容性的问题。当数据源发生变化时，kafka连接器会生成新的数据结构，通过不同处理策略来完成数据格式的兼容
   2. 连接器的几个核心概念
      1. 连机器实例，在kafka连接器中，连接器实例决定了消息数据的流向，即，消息数据从何处复制，以及将复制的消息写入何处。连接器实例负责kafka系统与其他系统之间的逻辑处理。连接器实例通常以jar包形式存在，通过实现kafka系统应用接口来完成
      2. 任务数，在分布式模式下，每一个连接器实例可以将一个作业切分成多个任务，然后再将任务分发到各个事件线程中去执行。任务不会保存当前的状态信息，通常由特定的kafka主题来保存。在分布式模式中存在一个”任务均衡“的概念。当一个连接器实例首次提交到kafka集群时，所有的事件线程都会执行任务均衡的操作，来保证每一个事件线程都运行差不多数量的任务，避免所有任务集中到某一个事件线程
      3. 事件线程，在kafka系统中，连接器实例和任务数都是逻辑层面的，需要由具体的线程来执行。在kafka连接器中，事件线程用来执行具体的任务。事件线程包含两种模式—单机模式和分布式模式
      4. 转换器，转换器能就爱那个字节数转换成kafka连接器内部的格式，也能将kafka连机器内部存储的数据格式转换成字节数据
2. Kafka流处理，
   1. 流处理是一种用来处理无穷数据集的数据处理引擎，通常无穷数据集具有以下几个特点
      1. 无穷数据：持续产生的数据，他们通常会被称为流数据
      2. 低延时：流数据通常都是实时处理，数据实时产生，然后流处理引擎实时处理流数据，因此延时很短
   2. kafka流处理特性
   3. 流式计算
      1. 流式计算的实现流程

1. 1. 1. 批处理计算的实现流程

1. 1. 流处理架构

1. 1. 1. 流分区和任务，kafka流处理通过流分区来处理数据，内容包含存储和传输数据。Kafka流处理使用分区和任务概念来作为并发模型中的逻辑单元。在并发环境中，通过分区数据来保证灵活性、可扩展性、高效性和容错性
         1. 流分区的作用，在kafka流处理中，每个流分区是完全而有序的数据队列。这些有序数据记录会映射到kafka系统主题分区中
         2. 任务的作用，一个应用程序可以被拆分为多个任务来执行。Kafka流处理会根据输入流分区来创建固定数量的任务，每个任务分配一个输入流分区列表
         3. Kafka刘处理不是一个资源管理器，而是一个类库；kafka流处理可以运行在任何刘处理应用程序中。应用程序的多个实例可以运行在同一个主机上，也可以分发到不同的主机进行执行。如果一个应用程序实例发生异常导致不可用，则该任务将会自动地在其他的实例上重新创建，并从相同的分区中继续读取数据
      2. 线程模型，kafka流处理允许用户配置多个线程，并通过多线程来均衡应用程序中的任务数。每个线程的处理流程可以执行一个或者多个任务。线程模型的优点：
         1. 易扩展：对kafka流处理应用程序进行扩展是很容易的，只需要运行应用程序的实例即可
         2. 自动分配分区：kafka流处理会监听任务数量的变化，并自动给任务分配分区
         3. 多线程：用户在启动应用程序时，可以根据kafka系统输入主题中的分区数来设置线程数。每个线程至少对应一个分区
      3. 本地存储状态，刘处理提供的状态存储机制，可用来保存和查询应用程序产生的状态数据。例如，在执行连接、聚合操作时，kafka流处理会自动创建和管理这些状态存储
         1. 在kafka流处理应用程序中，每个流任务可以集成一个或多个本地状态存储，这些本地状态存储可以通过应用接口来进行存储和查询。同时，kafka流处理也为本地状态存储提供了容错机制和自动恢复功能
      4. 容错性 failover
         1. Kafka流处理继承了kafka系统主题分区的两大能力------高可用能力、副本故障自动转移能力。因而，在流数据持久化到kafka系统主题时，即使应用程序失败也会自动重新处理
         2. Kafka流处理中的任务利用kafka系统客户端提供的容错机制来处理异常问题。如果某个任务在发生故障的主机上执行，则kafka流处理会自动在应用程序的其他运行实例中重新启动该任务
         3. 每个状态存储都会维护一个更改日志主题的副本，用来跟踪状态的更新。这些更改日志主题也进行了分区，以便每个本地状态存储实例和访问存储的任务都有器专属的更改日志主题分区。在更改日志主题上启用日志压缩，可以方便、安全地清理无用数据，避免主题数据无线增长
         4. 如果任务在一台主机上运行失败，之后在另一台主机上重新启动，则kafka流处理在恢复对新启动的任务之前，通过回滚机制将关联的状态存储恢复到故障之前，整个过程对于用户来说是完全透明
      5. 操作KStream和KTable，kafka流处理定义了三个抽象概念
         1. KStream 它是一个消息流的抽象，消息记录由键-值对构成，其中每条消息记录代表无界数据中的一条消息记录
         2. KTable 它是一个变更日志流的抽象，其中每条消息记录代表一次更新。如果消息记录中的键不存在，则更新操作被认为是创建
         3. GlobalKTable它和KTable类似，也是一个变更日志流的抽象，其中每条消息记录代表一次更新
      6. 流处理的核心概念，kafka流处理是一个客户端类库，用于处理和分析kafka系统主题中的数据；kafka流处理能够准确区分事件事件和处理时间；另外，它支持窗口操作，能够简单而有效地管理和查询应用程序的状态
         1. 时间，是kafka流处理中一个比较重要的概念，它定义了kafka流处理如何进行建模和集成。例如窗口操作就是基于时间边界来定义
            1. 事件时间，事件或消息记录产生的时间，都包含在消息记录中。产生的时间由生产者实例在写入数据时指定一个时间戳字段
            2. 处理时间，kafka流处理应用程序开始处理时间的时间点，即消息记录存入kafka代理节点的时间。一般情况下，处理时间迟于事件时间，他们之间的时间间隔单位可能是毫秒、秒或小时
            3. 摄取时间，消息被处理后存储到kafka系统主题的时间点。如果消息没有被处理，而是直接存储到kafka系统中，则这个阶段就没有处理时间只有存储时间
         2. 状态，某些流处理应用程序是不需要状态信息的，kafka流处理引入状态存储的概念，流处理应用程序可以对状态存储进行读/写。每个流处理任务都可以集成一个或者多个状态存储。状态存储支持持久化键值对存储、内存哈希表存储或者其他形式的存储
         3. 处理保障。1.11.0.0版本之后，kafka系统开始支持生产者实例以事务性和幂等性向主题分区发送消息数据。通过这一特性kafka流处理可以准确地支持一次性处理
         4. Kafka流处理框架与其他实时处理框架不同之处是，kafka流处理和底层kafka存储机制紧密集成，确保是原子性操作，其操作内容包括：对主题偏移量的提交、对状态存储的更新、对输出主题的写入等
      7. 窗口操作，流数据属于时间无界的数据集，而在某些特定的场景下需要处理有界的数据集，这时可以通过窗口来实现
         1. 翻滚时间窗口，大小固定、不重叠、无间隙的一类窗口模型。闭区间到开区间，第一个窗口值必须从0开始
         2. 跳跃时间窗口，基于时间间隔的窗口模型，是一个大小固定、可能会出现重叠的窗口模型。跳跃现象由窗口大小和时间间隔两个属性决定，如果时间间隔小于窗口大小，就会出现这种现象
         3. 滑动时间窗口，是大小固定、沿着时间轴连续滑动的窗口模型。如果两条消息记录的时间戳之差在窗口大小范围之内，则这两条消息记录属于同一个窗口。因此滑动时间窗口不会和某个时间点对齐，而是和消息记录的时间戳进行对齐，他的窗口大小取值范围为闭区间到闭区间
         4. 会话窗口，会话窗口需要先对消息记录的键做分组，然后根据实际的业务需求为分组后的数据定义一个起始点和结束点的窗口
      8. 连接操作，连接操作是通过消息记录键将两个流数据记录进行合并，生成一个新的流数据。Kafka流处理提供了三种连接操作----内连接 左连接 外连接
      9. 转换操作，在kafka流处理中，KStream和KTable支持一系列的转换操作。这些转换操作都可以被转换为一个或者多个连接，这些转换后的连接组合在一起形成了一个复制的流处理关系
         1. Kstream产生一个或者多个kstream对象，另外一些则产生一个ktable对象；ktable对象来说，所有转换操作都只能产生一个ktable对象
         2. 无状态转换，这种转换不依赖任何状态（如过滤、分组等）就可以完成，不要求kafka流处理器去关联状态存储
         3. 有状态转换，需要依赖某些状态信息。例如，在执行聚合操作时，会使用状态存储来保存上一个窗口的聚合结果；在执行连接操作时，会使用状态存储保存窗口边界内部的所有记录。状态存储默认支持容错。如果出现异常，kafka流处理会先恢复所有的状态存储，然后在进行后续的处理
      10. 聚合操作，聚合操作是一种有状态的转换。聚合操作基于键来完成，这意味着，操作的流数据会先按照相同的键来进行分组，然后对消息记录进行聚合，而在执行聚合操作时可以选择使用窗口或不使用窗口
          1. 无窗口，按照消息记录键进行分组，然后使用count()函数来统计消息记录数
          2. 有窗口，按照消息记录键进行分组，然后设置窗口大小为5min，并使用count()函数来统计消息记录数
2. ELK：
   1. Elasticsearch 负责分布式存储日志数据，为kibana提供进行可视化的数据源
   2. Logstash负责消费kafka消息队列中的原始数据，并将消费的数据上报到elasticsearch进行存储
   3. Kibana负责对elasticsearch中存储的数据进行可视化，并提供查询、聚合、图表和导出等功能
   4. Kafka负责集中管理日志信息，并作数据分流
   5. 体系架构如下：

1. 1. 数据源的收集可以采用不同的方式：
      1. 使用Flume Agent采集数据，则省略了额外的编码工作
      2. 使用javaAPI读取日志信息，则需要额外的编写代码
2. Kafka与Spark的结合
   1. Spark是一种基于内存的分布式计算引擎，其核心为弹性分布式数据集（Resilient Distributed Datasets,RDD）,它支持多种数据来源，拥有容错机制，支持并行操作
3. Kafka eagle