1.2 kafka 登场

1.2.1 消息和批次

  1. Kafka 的数据单元被称为消息。
  2. 为了提高效率，消息被分批次写入 Kafka 批次就是 组消息，这些消息属于同一 主题和分区。

1.2.2 模式

可以理解是kafka的消息结构；序列化协议

1.2.3 主题和分区

主题可以被分为若干个分区 个分区就是一个提交日志。消息以追加的方式写入分区，然后以先入先出的顺序读取。由于一个主题可以被分为多个分区，所以不能保证整个主题分区的顺序性。

kafka 通过分区来实现数据冗余和伸缩性。分区可以分布在不同的服务器上，也就是说， 一个主题可以横跨多个服务器，以此来提供比
个服务器更强大的性能。

1.2.4 生产者和消费者

  1. 生产者创建消息。在默认情况下把消息均衡地分布到主题的所有分区上，而并不关心特定消息会被写到哪个分区。特殊情况先可以通过分区器将指定的消息键一致性hash；将其映射到指定的分区中。实现部分分区的有序性。
  2. 消费者读取消息。消费者可能被称为订阅者或读者 消费者订个或多个主题，并按照消息生成的顺序读取它们。消费者通过检查消息的偏移量来区分已经读取过的消息。
  3. 偏移量是另 种元数据，它是 个不断递增的整数值，在创建消息时， Kafka 会把它添加到消息里。在给定的分区里，每个悄息的偏移量都是唯 的。消费者把每个分区最后读取的悄息偏移量保存在 Zookeeper Kafka 上，如果悄费者关闭或重启，它的读取状态不会丢失。

1 .2.5 broker和集群

  1. 一个独立的 Kafka 服务器被称为 broker， broker 接收来自 生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。 broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个 broker 可以轻松处理数千个分区以及每秒百万级的消息量。
  2. broker 是集群的组成部分。每个集群都有 broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。
  3. 保留消息（在 定期限内）是 Kafka 个重要特性。 Kafka broker 默认的消息保留策略是这样的：要么保留 段时间（比如 天），要么保留到消息达到一定大小的字节数（比lGB ）；。可以通过配置把主题当作紧凑型日志， 只有最后 个带有特定键的消息会被保留下来。这种情况对于变更日志类型的数据来说比较适用，因为人们只关心最后时刻发生的那个变更。

1.2.6 多集群

随着 Kafka 部署数量的增加，基于以下几点原因，最好使用多个集群。

  • 数据类型分离
  • 安全需求隔离
  • 多数据中心（灾难恢复）

1.3 为什么选择Kafka

  1. 多个生产者
  2. 多个消费者
  3. 基于磁盘的数据存储
  4. 伸缩性
  5. 高性能

1.4 数据生态系统

使用场景

  1. 活动跟踪
  2. 传递消息
  3. 度量指标和日志记录

kafka 安装

2.3 broker配置

2.3.1 常规配置
  1. broker.id （集群id必须唯一；最好与主机id保持相关）
  2. port 默认会监听 9092 端口
  3. zookeeper.connect 用于保存broker元数据的zookeeper的地址是通过该配置参数决定的。
  4. log .dirs Kafka 把所有消息都保存在磁盘上，存放这些日志片段的目录是通过 log. dirs 指定的
  5. nu m.recovery threads.per data.dir
    对于如下 种情况， Kafka 会使用可配置的钱程 来处理日志片段(总线程数量为 log.dirs * 本参数)
    * 服务器正常启动，用于打开每个分区的日志片段
    * 服务器崩愤后重启，用于检查和截短每个分区的日志片段：
    * 服务器正常关闭，用于关闭日志片段。
  6. auto.c reate .topics.enable 自动创建topic
    默认情况下， Kafka 会在如下几种情形下自动 建主题
    * 当一个生产者开始往主题写入消息时
    * 当一个消费者开始从主题读取消息时
    * 任意 个客户端向主题发送元数据请求时。
2.3.2 主题的默认配置
  1. num.partions 参数指定了新创建的主题将包含多少个分区。

如何选定分区数 为主题选定分区数量并不是 件可有可无的事情，在进行数量选择时，需要 考虑如下几个因素。

  • 主题需要达到多大的吞吐量？例如，是希望每秒钟写入 100KB 还是1GB?
  • 从单个分区读取数据的最大吞吐量是多少？每个分区 般都会有 个消费者，如果你知道消费者将数据写入数据库的速度不会超过每秒 50MB ，那 么你也该知道，从一个分区读取数据的吞吐量不需要超过每秒 50MB
  • 可以通过类似的方法估算生产者向单个分区写入数据的吞吐量，不过生产 者的速度一般比消费者快得多，所以最好为生产者多估算 些吞吐量。
  • 每个broker 包含的分区个数、可用的磁盘空间和网络带宽。
  • 如果消息是按照不同的键采 入分区的，那么为已有的 题新增分区就会 很困难。
  • 单个broker 对分区个数是有限制的，因为分区越多，占用的内存越多，完 成首领选举需要的时间也越长。

如果不知道这些信息，那么根据经验，把分区的大小限制在 25G 以内可以得到比较理想
的效果。

  1. log.retention.ms
    Kafka 通常根据时间来决定数据可以被保留多久。默认使用 log.etentlon.hour 参数来配置时间 ，默认值为 168 小时，也就是一周。除此以外，还有其他两个参数 log.retention.ms和log.retention.minutes 这三个参数作用表示一致；都配置时优先使用较小的单位，所以建议使用log.retention.ms
  2. log.retention.bytes 通过保留的消息字节数来判断消息是否过期
    log.retention.ms 和 log.retention.bytes都指定时；只要满足任何一个都会对数据进行删除。
  3. log.segment.bytes
  4. log.segment.ms
  5. message.max.bytes
    broker 通过设置 message.max. bytes 参数来限制单个消息的大小，默认值是 1000 000 ，也就是 1MB 。

在服务端和消费端设置协调消息大小的配置： 消费者客户端设置的fetch.message.max.bytes
必须与服务器端设置的消息大小进行协调。如果这个值比 l’le ge.l’l x. ytes
小，那么消费者就无法读取比较大的消息，导致出现消费者被阻塞的情况。在为集群里的 broker
配置replica.fetch.max.bytes 参数同样遵循该原则。

2.4 硬件的选择

  1. 磁盘吞吐量
  2. 磁盘容量
  3. 内存 (主要考虑页面缓存)
  4. 网络:
    同一个生产者多个消费者、集群复制、镜像等就会造成网络饱和的情况；使得数据同步方面出现延迟，导致集群不堪一击。
  5. CPU:
    客户端为了优化网络和磁盘空间，会对消息进行压缩 服务器需对消息进行批量解压，设置偏移量，然后重新进行批量压缩，再保存到磁盘上。（不是主要考虑的因素）

2.6 Kafka 集群

2.6.3 操作系统调优
2.7.3 共享Zoo keeper

如果消费者将偏移量提交Zookeeper ，那么在每个提交时间点上 ，消费者将会为每 个消费的分区往 Zookeeper写入一次偏移量。合理的提交间隔是 分钟，因为这刚好是消费者群组的某个悄费者发生失效时能够读取到重复消息的时间。

第三章：kafka生产者，向kafka写入数据

3.1 概览

Kafka发送消息到的主要步骤：

kafka ttl_kafka

3.2 创建Kafka生产者

属性配置：

属性

解释

bootstrap.servers

该属性指定 broker 的地址清单，地址的格式为 host:po 。清单里不需要包含所有的broker 地址，生产者会从给定的 broker 里查找到其他 broker 的信息。不过建议至少要提供两个 broker 信息， 且其中某个宕机，生产者仍然能够连接到集群上。

key.serializer

键序列化器 Kafka客户端默认提供byteArraySerializer、StringSerilizer 和IntegerSerializer

value. serilizer

值序列化器

Kafka 发送消息的方式：

  1. 发送并忘记（fire and forget）
    不关心是否能正常到达，一般情况下消息会正常到达，kafka内部有重试机制。但是有可能会丢失消息
  2. 同步发送
    试用send()发送消息，返回一个Furture对象，调用get方法进行等待；
  3. 异步发送
    调用send方法；并指定一个回调函数；服务器返回响应时，通知该回调函数。
    KafKa 发送消息发生异常情况有2中：
  4. 可重试错误 类似于 连接错误、无主错误（可以通过重新选择分区）；这类错误kafkaProduce可配置成自动重试。如果多次重试仍无法解决，就会抛出异常。
  5. 不可重试错误，如消息体太大。

3.4 生产者的配置

配置项

配置参数

acks

0：不等待响应直接返回； 1：等待leader节点响应；all：等待所有复制节点全部接收消息

buffer.memory

该参数用来设置生产者内存缓冲区的大小，生产者用它缓冲要发送到服务器的消息。如果应用程序发送消息的速度超过发送到服务器的速度，会导致生产者空间不足。这个 候，send（）方法调用要么被阻塞，要么抛出异常，取决于如何设置 block.on.buffer. full 参数（在 0. 9.0.0 版本里被替换成了 max .block.ms ，表示在抛出异常之前可以阻塞一段时间）。

compression.type

发送消息的压缩方式

retries

发送者的重试次数

batch.size

同一个批次使用内存大小

linger.ms

发送批次之前，等待其他消息加入批次的时间

client.id

该参数可以是任意的字符串，服务器会用它来识别消息的来橱，还可以用在日志和配额指标里。

max.in.flight.requests.per.connection

该参数指定了生产者在 到服务器晌应之前可以发送多少个消息。它的值越高，就会占用越多的内存，不过 会提升吞吐量。 它设为 可以保证消息是按照发送的序 入服器的，即使发生了重试。

如果把retries 设为非零整数，同时把 Max.flight.requests.per.connection 设为比1大的数，那么，如果第 个批次消息写入失败，而第 个批次写入 成功， broker 会重试写入第 个批次。如果此时第 个批次也写入成功，那
么两个批次的顺序就反过来了。一般来说，如果某些场景要求消息是有序的，那么消息是否写入成功很关键的，所以不建议把 retries 设为
0。可以 Max.flight.requests.per.connection 设为 1，这样在生产者尝试发送第一批悄息时，就不会有其他的消息发送给 broker 。不过这样会严重影响生产者的吞吐量 ，所以只有在对消息的顺序有严格要求的情况下才能这么做。

5. 深入kafka

前言：本章不会涵盖kafka的设计和细节，而是集中围绕三个话题进行阐述。

  1. kafka 是如何进行复制的
  2. kafka是如何处理来自生产者和消费者的请求
  3. kafka的存储细节，比如文件格式和索引

5.1 集群成员关系

  1. kafka通过zk来维护broker集群信息；
  2. 每个broker拥有一个唯一标识broker ID（可以配置或者自动生成）
  3. kafka组件订阅zk的brokers/ids 路径
  4. 通过将自己的broker ID注册在zk临时节点中（相同的brokerID 会导致无法注册成功）

broker 停机、出现网络分区或长时间垃圾回收停顿时， broker 会从 Zookeeper 上断开连
接，此时 broker 在启动时创建的临时节点会自动从 Zookeeper 上移除。监听 broker 列表的
Kafka 组件会被告知该 broker 已移除。
在关闭 broker 时，它对应的节点也会消失，不过它的 ID 会继续存在于其他数据结构中
例如，主题的副本列表（下面会介绍）里就可能包含这些白。在完全关闭一个 broker
后，如果使用相同的 启动另一个全新的 broker ，它会立即加入集群，井拥有与旧 broker
相同的分区和主题。

5.2 控制器

控制器其实就是一个broker；但是除了普通的broker，它还负责分区首领的选取。
控制器的功能：

  1. 负责分区首领的选取
  2. 集群里第一个启动的broker；负责在zk上面创建一个/controller节点；并让自己成为controller
  3. 其他broker也会尝试创建/controller；不过无法创建成功；所以它们会在/controller节点上创建监听器，监听这个节点的变更通知。
  4. 如果控制器断开与zk的连接；那么其他broker会重新注册/controller，执行2、3的流程；并且通过zk’的条件递增操作获得一个更大的controller epoch；当broker知道当前的controller epoch之后，就会忽略旧版的controller epoch发送的消息。
  5. 控制器使用epoch 来避免“脑裂” 。“脑裂”是指两个节点同时认为自己是当前的控制器。

5.3 复制

  1. kafka的复制保证了kafka的可用性和持久性
  2. kafka使用主题来组织数据；主题被分为多个分区；不同的分区在broker上保存着多个副本。每个broker都可以保存成千上万个不同的主题分区副本。
  3. 副本可以分为：
    首领副本：
    * 每个分区都有一个首领副本 为了保证 致性，所有生产者请求和消费者请求都会经过这个副本。
    * 首领的另 个任务是搞清楚哪个跟随者的状态与自己是一致的。
    * 除了当前首领之外，每个分区都有一个首选首领；创建主题时，选定的首领就是分区的首选首领
    跟随者副本：
    首领以外的副本都是跟随者副本。跟随者副本不处理来自客户端的请求，它们唯 的任务就是从首领 那里复制消息，保持与首领一致的状态。如果首领发生崩渍，其中的跟随者会被提升为新首领。

为了与首领保持同步，跟随者向首领发送获取数据的请求，这种请求与悄费者为了读取悄
息而发送的请求是 样的。首领将响应消息发给跟随者。请求消息里包含了跟随者想要获
取消息的偏移量，而且这些偏移量总是有序的

5.4 处理请求

  1. broker 的大部分工作是处理客户端、分区副本和控制器发送给分区首领的请求。
  2. broker 按照请求到达的顺序来处理它们一一这种顺序保证让Kafka 具有了消息队列的特性，同时保证保存的消息也是有序的。
  3. 请求消息的标准请求头：
  • Request type （也就是 API key)
  • Request version (broker 可以处理不同版本的客户端请求，井根据客户端版本作出 不同的响应）
  • Correlation ID 个具有唯一性的数字， 用于标识请求消息，同时也会出现在响应消息和错误日志里（用于诊断问题）
  • Client ID 用于标识发送请求的客户端
  1. broker 会在它所监听的每 个端口上运行一个 Acceptor 线程，这个钱程会创建 个连接，
    并把它交给 processor 线程去处理。网络线程负责从客户端获取请求悄息，把它们放进请求队列，然后从晌应队列获取响应消息，把它们发送给客户端。

请求类型分为两种：

  • 生产请求
    生产者发送的请求，它包含客户端要写入 broker 的消息。
  • 获取请求
    在消费者和跟随者副本需要从 roker 读取消息时发送的请求。
  • 元数据请求

生产请求和获取请求都必须发送给分区的首领副本。如果 broker 收到 个针对特定分区的请求，而该分区的首领在另 broker 上，那么发送请求的客户端会收到 个“非分区首领”的错误响应。当针对特定分区的获取请求被发送到一个不含有该分区首领的 broker上，也会出现同样的错误。 Kafka 客户端要自己负责把生产请求和获取请求发送到正确的broker 上。

  1. 客户端会发送一种元数据请求；这种请求包含了客户端感兴趣的主题列表。元数据请求可以发送给任意一个 broker ，因为所有 broker 都缓存了这些信息。

kafka ttl_kafka ttl_02

5.4.1 生产请求

  1. 包含首领副本的 broker 在收到生产请求时，会对请求做一些验证。
  • 发送数据的用户是否有写入数据的主题权限
  • 请求里包含的acks是都有效
  • 如果acks=all 是否能保证足够多的同步副本能安全的写入消息。
  1. 接下来消息会被写入磁盘的文件系统缓存中；依赖系统的复制特性保证消息的持久性。

在消息被写入分区的首领之后， broker 开始检 acks 配置参数一一如果 acks 被设为 0或者1,
那么 broker 立即返回响应；如果 ac 被设为 all ，那么请求会被保存在 个叫作炼狱的缓冲
区里，直到首领发现所有跟随者副本都复制了消息，晌应才会被返回给客户端。

5.4.2 获取请求

broker 处理获取请求的方式与处理生产请求的方式很相似。客户端发送请求，向 broker
求主题分区里具有特定偏移量的消息，好像在说 “请把主题 Test 分区 偏移量从 53 开始
的消息以及主题 Test 分区 偏移量从 64 开始的消息发给我。”客户端还可以指定 broker
多可以从一个分区里返回多少数据。这个限制是非常重要的，因为客户端需要为 broker
回的数据分配足够的内存。如果没有这个限制， broker 返回的大量数据有可能艳尽客户端
的内存。如果客户端请求的数据不存在或者是已经被删除的数据，则直接返回一个错误。

  2. 客户端向kafka设置请求数据具有上下限的设置；设置上限能够管理好客户端的内存；设置好下限，能提高获取消息的效率。

    3. kafka ttl_kafka_03

  3. Kafka 使用零复制技术向客户端发送消息一一也就是说， Kafka 直接把消息从文件（或者更确切地说是 Li ux 文件系统缓存）里发送到网络通道，而不需要经过任何中间缓冲区。
  4. 大部分客户端只能读取已经被 入所有同步副本的悄息（跟随者副本也不行，尽管它们也是消费者
    则复制功能就无陆工作）。分区首领知道每个消息会被复制到哪个副本上，在消息还没有被写入所有同步副本之前，是不会发送给消费者的一一尝试获取这些消息的请求会得到空的响应而不是错误
  5. 消费者只有等到同步副本复制了消息以后才会获取到该数据；复制会发生延迟，延迟时间可以通过参数replica. lag. time. max.ms 来配置，它指定了副本在复制消息时可被允许的最大延迟时间。

kafka ttl_kafka_04

  1. Kafka 的基本存储单元是分区。分区无法在多 broker 间进行再细分，也无法在同broker 的多个磁盘上进行再细分。但是分区是由多个片段组成；默认情况下；每个片段大小为1G；ttl为1周。

5.5.1 分区分配

  1. 在创建主题时， Kafka 首先会决定如何在 broker 间分配分区。
  3. 确定分区位置：
    * broker未分配机架信息：分区首领随机选择一台从0-N编号的机器 i ；follower则会分配为i+1，i+2。。。；
    * broker已分配机架信息：分区按照交替机架的方式选择broker。

    4. kafka ttl_kafka ttl_05

  4. 为分区分配目录：计算每个目录里的分区数量，新的分区总是被添加到数量最小的那个目录里。但是并不会考虑磁盘空间的大小。

6. 可靠的数据传递

6.5.1 消费者的可靠性配置

  1. auto.offset.reset 一种是earlist可能重复数据较多；latest可能丢失数据。
  2. enable.auto.commit 自动提交消息；优点是避免业务入侵；缺点是不能很好的控制数据的重复消费
  3. auto.commit.interval.ms 自动提交的频率，默认每5秒提交一次；频繁提交会增加额外开销。

6.6 验证系统可靠性

6.6.1 配置验证

org.apache.kafka.tools 里的 Verifiable.Produce 和VerifiableConsume 这两个类;可以打印对应事件的事情。

测试选项：

  1. 首领选举；停掉首领选举，首领选举需要的时间
  2. 控制器选举
  3. 依次重启
  4. 不完全首领选举测试

应用程序验证

  1. 客户端网络从服务器断开
  2. 首领选取
  3. 一次重启broker
  4. 一次重启消费者
  5. 一次重启生产者
    你对每 个测试场景都会有期望的行为 ，也就是在开发应用程序时所期望看到的行为，然
    后运行测试看看真实的结果是否符合预期。

7. 构建数据管道

通常使用kafka构建数据管道的时候有两种场景：

  1. kafka作为数据管道的两个端点之一；如：把kafka的数据移动到s3上；或者把db的数据移动到kafka上
  2. 把kafka作为两个端点之间的媒介

Kafka 为数据管道带来的主要价值在于，它可以作为数据管道各个数据段之间的大型缓冲区， 有效地解桐管道数据的生产者和消费者。 Kafka 的解藕能力以及在安全和效率方面的可靠性 ，使它成为构建数据管道的最佳选择。

构建管道时需要考虑的问题

  1. 及时性；Kafka 在这里扮演了 个大型缓冲区的角色，降低了生产者和消费者之间的时间敏感度。可以及时响应，也可以缓存大量数据之后批处理；完全由开发人员根据不同场景定义。
  2. 可靠性；实现了至少一次传递；根据消费端的业务，可以实现仅一次传递。
  3. 高吞吐量和动态吞吐量；kafka的作为一个缓冲区+压缩机制+connect API的并行处理 可以实现高吞吐和动态吞吐。
  4. 数据格式
  5. 转换；数据管道的构建可以分为两大阵营，即 ETL ELT
  • ETL 表示提取一转换一加载（Extract-Transform-Load ）
  • ELT 表示提取－加载－转换 Extract-Load-Transform ）
  1. 安全性；Kafka 支持加密传输数据，从数据糠到 Kafka ，再从 Kafka 到数据池。
  2. 故障处理能力；
  3. 糯合性和灵活性；
  1. 临时数据管道：当有新的系统加入肘，他们需要构建额外的数据管道，从而增加了采用新技术的成本，同时遏制了创新。
  2. 元数据丢失：允许 sc ema 发生变更，应用程序各方就可以修改自己的代码，无需担心对整个系统造成破坏。
  3. 未端处理：更为灵活的方式是尽量保留原始数据的完整性，让下游应用自己决定如何处理和聚合数据。

如何在Connect API 和客户端API 之间作出选择

如果你是开发人员，你会使用 Kafka 客户端将应用程序连接到
Kafka ，井修改应用程序的代码，将数据推送到 Kafka 者从 Kafka 读取数据。如果要将 Kafka 连接到数据存储系统，可以使用 Connect ，因为这些系统不是你开发的。
如果你要连接的数据存储系统没有相应的连接器，那么可以考虑使用客户端 API或Connect AP 开发一个应用程序。我们建议首选connect ，因为它提供了 些开箱即用的特性，比如配置管理、偏移量存储、井行处理、错误处理，而且支持多种数据类型和标准的REST 管理 API 。开发 个连接 Kafka 和外部数据存储系统的小应用程序看起来很简单，但其实还有很多细节需要处理，比如数据类型和配置选项，这些无疑加大了开发的复杂
一一 connect 处理了大部分细节，让你可以专注于数据的传输。

深入理解Connect

  1. 连接器和任务；连接器插件实现了 Connector API, API 包含了两部分内容。
  • 连接器
  1. 决定需要运行多少个任务。
  2. 按照任务来拆分数据复制。
  3. 从worker 进程获取任务配置并将其传递下去。
  • 任务；任务负责将数据移入或移出 Kafka 。
  1. worker 进程；worker 进程是连接器和任务的“容器”。它们负责处理HTTP 请求，这些请求用于定义连接器和连接器的配置。

为了更好地理解 worker 进程，我们可以将其与连接器和任务进行简单的比较。连接器和任务负责“数据的移动”， 而 worker 进程负责 REST API 、配置管理、可靠性、高可用性、伸缩性和负载均衡。
这种关注点分离是 Connect API 给我们带来的最大好处，而这种好处是普通客户端 API不具备 。有经验的开发人员都知道，编写代码从 Kafka 读取数据并将其插入数据库只需一到两天的时间，但是如果要处理好配置、异常、 REST API 、监控、部署、伸缩、失效等问题，可能需要几个月 如果你使用连接器来实现数据复制，连接器插件会为你处理掉大堆复杂的问题

  1. 转化器和 Connect 的数据模型；Connect 提供了 一组数据API---- 它们包含了数据对象和用于描述数据的 schema。例如， JDBC 连接器从数据库读取了一 字段，并基于这个字段的数据类型创建了 Connect Schema 对象。
  2. 偏移量管理； worker 进程还提供了偏移量管理服务。

跨集群数据镜像

跨集群镜像的使用场景

  1. 区域集群和 中心集群
  2. 冗余（DR) （备份）
  3. 云迁移

多集群的架构

跨数据中心通信的一些现实情况

  1. 高延迟
  2. 有限的带宽
  3. 高成本
  5. hub和Spoke架构
    这种架构适用于 个中心 Kafka 集群对应多个本地 Kafka 集群的情况

    6. kafka ttl_客户端_06

  6. 双活架构
    当有两个或 个数据中心 要共 数据并且每个数据中心都可以生产和读取数据时 可以使用双活（ Active-Active ）架构;这种架构需要考虑数据冲突和循环复制的问题。

kafka ttl_kafka ttl_07

  1. 主备架构；这种架构的不足在于，它浪费了备份的集群。
    失效备援都包含哪些内容：
  • 数据丢失和不一致性
  • 失效备握之后的起始偏移量
  • 在失效备援之后
  • 关于集群发现

管理kafka

主题操作

  1. 创建主题
  2. 增加分区
  • 调整基于键的主题；创建基于键的主题时很难创建新的分区；建议在开始就创建好完整的分区
  • 忽略主题不存在的错误
在使用，－ alte 「命令修改主题时，如果指定了…if-exists 参数，主题不存在的错误就会被忽略。如果要修改的 题不存在，该命令并不会返回任何错误。在主题不存在的时候本应该创建主题，但它却把错误隐藏起来，因此不建议使用这个参数。

kafka ttl_java_08


* 减少分区数;我们无法减少分区数量；如果删除分区，则分区数据会被删除；如果将数据分配给其他分区，那么数据的顺序性无法保证。

建议先删除topic再重建。
  1. 删除主题；如果一个主题不再被使用，只要它还存在于集群里，就会占用一定数量的磁盘空间和文件句柄。
  1. 删除主题的配置：broker的delete.topic.enable设置为true

监控kafka

broker 的度量指标

非同步分区

  1. 集群级别的问题
  • 不均衡的负载
  • 资源过度消耗
    定位该类型问题需要用到一下broker指标：
  1. 分区的数量
  2. 首领分区的数量
  3. 主题流入字节的速率
  4. 主题流入消息的速率
  1. Kafka 集群的另 个性能问题是容量瓶颈。
  • CPU使用
  • 网络输入吞吐量
  • 网络输出吞吐量
  • 磁盘平均等待时间
  • 磁盘使用百分比
    上述任何 种资掘出现过度消耗，都会表现为分区的不同步。
  1. 主机级别的问题
  • 硬件问题
  • 进程冲突
  • 本地配置不一致

broker其他度量指标

  1. 活跃控制器数量；任何时候一个集群里面有且仅有一个控制器；
  2. 请求处理器空闲率；

请求处理器平均空闲百分比这个度量指标表示请求处理器空闲时间的百分比。数值越低，
说明 broker 的负载越高 经验表明，如果空闲百分比低于 20% ，说明存在潜在的问题，如果低于 10% ，说明出现了性能问题。除了集群的规模太小之外，还有其 两个原因会增大这个个线程地的使用量。首先，线程池里没有足够的线程。一般来说，请求处理器线程的数量应该与系统的处理器核数 样（包括多线程处理器）。

  1. 主题流入字节
  2. 主题流出字节
  3. 主题流入的消息
  4. 分区数量
  5. 离线分区

主题和分区的度量指标

  1. 题实例的度量指标
  2. 分区实例的度量指标

Java虚拟机监控

操作系统监控

流式处理

什么是数据流？

  1. 事件流是有序的
  2. 不可变的数据记录
  3. 事件流是可重播的

什么是流处理？
流处理是指实时的处理一个或多个事件流。对比请求响应和批处理：
请求响应：
这是延迟最小的一种范式，响应时间处于亚毫秒到毫秒之间，而且响应时间 般非常稳
定。这种处理模式 般是阻塞的，应用程序向处理系统发出请求，然后等待响应。

批处理：
这种范式具有高延迟和高吞吐量的特点。处理系统按照设定的时间启动处理进程，比如
每天的下午两点开始启动，每小时启动 次等。

流式处理：
只要持续地从 个无边界的数据集读取数据，然后对它们进行处理并生成结果，那就是在进行流式处理。

流式处理的概念

  1. 时间（事件时间、日志追加时间、处理时间）
  2. 状态（本地状态或内部状态、外部状态）
  3. 流和表的二元性

在将表与流进行对比时，可以这么想：流包含了变更一一流是 系列事件，每个事件就是一个变更。表包含了当前的状态，是多个变更所产生的结果。所以说， 表和流是同一个硬币的两面 - - 世界总是在发生变化，用户有时候关注变更事件，有时候则关注世界 当前状态。如果一个系统允许使用这两种方式来查看数据，那么它就比只支持 种方式的系统强大。

  1. 时间窗口

流式处理的设计模式

实在是看不下去了，感觉这个流应该是设计模式的一种。。。。等到遇见具体场景的时候再看看吧