《深入浅出》Apache Kafka实战

2011年年初，美国领英公司(LinkedIn) 开源了一款基础架构软件，以奥地利作家弗兰兹.卡夫卡(Franz Kafka)的名字命名，之后LinkedIn 将其贡献给Apache基金会，随后该软件于2012年10月成功完成孵化并顺利晋升为Apache项目---这 便是大名鼎鼎的ApacheKafka。历经7年发展，2017年 11月，Apache Kafka正式演进到1.0时代，本书就是基于1.00版本来展开介绍Kafka的设计原理与实战的。

kafka有这一篇就够了_kafka用法

kafka有这一篇就够了_kafka用法

给大家分享一篇Apache Kafka实战的PDF

第1章：认识Apache Kafka

Kafka快速入门

消息引擎系统

Kafka概要设计

Kafka基本概念与术语

Kafka使用场景.

本章小结

第二章:Kafka发展历史

Kafka的历史

Kafka版本变迁

如何选择Kafka版本

Kafka与Confluent

本章小结

第3章：Kafka线上环境部署

集群环境规划

伪分布式环境安装

多环境安装

验证部署

参数设置

本章小结

第4章：producer开发

producer概览

构造producer

消息分区机制

消息序列化

producer

无消息丢失配置

消息压缩.

多线程处理

旧版本producer

本章小结

第五章：consumer开发

consumer概览

构建consumer

topic

消息轮询.

位移管理

重平衡

解序列化

多线程消费实例

consumer

旧版本consumer

本章小结

第六章：Kafka设计原理

broker端设计架构

producer端设计

consumer 端设计

实现一次处理语义

本章小结

第七章：管理Kafka集群

集群管理

topic管理

topic动态配置管理

cosumer相关管理

topic分区管理

Kafka常见脚本工具.

..........

常见问题

本章小结

第八章：Katka集群

集群健康度检查

MBean

broker端JMX

clients端JMX

JVM

Os.

主流框架

本章小结

第九章：调优Kafka集群

引言

确定调优目标

集群基础调优

调优吞吐量

调优延时

调优持久性

调优可用性

本章小结

第十章：Kafka Connect与Kafka Streams

引言

Kafka Connect

Kafka Streams

本章小结

这篇PDF的内容太多了我没有办法一一展示出来，我已经把这篇 PDF整理好了，需要免费领取的朋友麻烦转发这篇文章，然后私信【学习或者JVM】即可。

微服务想搞好，消息中间件不能少，Kafka基础入门介绍

现在微服务流行，很多公司起项目都是分布式微服务，但是你想过没有，不是把一个单体拆开了，用域名去相互调就叫微服务。好的微服务架构设计模式里要求每个服务的自治性，这样服务拆分成微服务后才能稳定。

怎么才能让每个服务尽量达到自治性呢？这就需要领域、溯源、CQRS、Saga这些设计模式，不好意思一下子说了很多概念，以后慢慢给大家解释。

这几个模式里边有个关键点—需要通过把领域发布给远程的其他服务，完成数据同步。这就需要消息中间件了，消息中间件这块我了解的也不深，公司里用RocketMQ，不过付费版和开源版别很大。

听说Rocket MQ很多概念也来自Kafka，学会它其他的消息中间件基本也大不的都会了，今天分享一篇Kafka的基础入门文章给大家

Kafka 是一个分布式的基于发布/模式的消息队列（Message Queue），主要应用与大数据实时处理领域。其主要设计目标如下：

Kafka 本质上是一个 MQ（Message Queue），使用消息队列的好处？

下面给出 Kafka 一些重要概念，让大家对 Kafka 有个整体的认识和感知

Kafka分区

Kafka和Zookeeper的关系

在了解kafka集群之前, 我们先来了解下kafka的工作流程, Kafka集群会将消息流存储在 Topic 的中，每条记录会由一个Key、一个Value和一个时间戳组成。

Kafka的工作流程

Kafka 中消息是以 Topic 进行分类的，生产者生产消息，消费者消费消息，读取和消费的都是同一个 Topic。但是Topic 是逻辑上的概念， Partition 是物理上的概念，每个 Partition 对应一个 log 文件，该 log 文件中存储的就是 Producer 生产的数据。 Producer 生产的数据会不断顺序追加到该 log 文件末尾，并且每条数据都会记录有自己的 Offset 。而消费者组中的每个消费者，也都会实时记录当前自己消费到了哪个 Offset，方便在崩溃恢复时，可以继续从上次的 Offset 位置消费。

Kafka存储机制

此时 Producer 端生产的消息会不断追加到 log 文件末尾，这样文件就会越来越大, 为了防止 log 文件过大导致数据定位效率低下，那么Kafka 采取了分片和索引机制。它将每个 Partition 分为多个 Segment，每个 Segment 对应4个文件：“.index” 索引文件, “.log” 数据文件, “.snapshot” 快照文件, “.timeindex” 时间索引文件。这些文件都位于同一文件夹下面，该文件夹的命名规则为：topic 名称-分区号。例如, heartbeat心跳上报服务 这个 topic 有三个分区，则其对应的文件夹为 heartbeat-0，heartbeat-1，heartbeat-2这样。

index, log, snapshot, timeindex 文件以当前 Segment 的条消息的 Offset 命名。其中 “.index” 文件存储大量的索引信息，“.log” 文件存储大量的数据，索引文件中的元数据指向对应数据文件中 Message 的物理偏移量。

下图为index 文件和 log 文件的结构示意图：

index 文件和 log 文件的结构示意图

kafka中的 Partition 为了保证数据安全，每个 Partition 可以设置多个副本。此时我们对分区0,1,2分别设置3个副本（注:设置两个副本是比较合适的）。而且每个副本都是有"角色"之分的，它们会选取一个副本作为 Leader 副本，而其他的作为 Follower 副本，我们的 Producer 端在发送数据的时候，只能发送到Leader Partition里面 ，然后Follower Partition会去Leader那自行同步数据, Consumer 消费数据的时候，也只能从 Leader 副本那去消费数据的。

Kafka集群副本

Kafka集群副本

Kafka Controller，其实就是一个 Kafka 集群中一台 Broker，它除了具有普通Broker 的消息发送、消费、同步功能之外，还需承担一些额外的工作。Kafka 使用公平竞选的方式来确定 Controller ，在 ZooKeeper 成功创建临时 /controller 的Broker会成为 Controller ，一般而言，Kafka集群中台启动的 Broker 会成为Controller，并将自身 Broker 编号等信息写入ZooKeeper临时/controller。

Consumer 在消费过程中可能会出现断电宕机等故障，在 Consumer 恢复后，需要从故障前的 Offset 位置继续消费。所以 Consumer 需要实时记录自己消费到了哪个 Offset，以便故障恢复后继续消费。在 Kafka 0.9 版本之前，Consumer 默认将 Offset 保存在 ZooKeeper 中，但是从 0.9 版本开始，Consumer 默认将 Offset 保存在 Kafka 一个内置的 Topic 中，该 Topic 为 __consumer_offsets, 以支持高并发的读写。

上面和大家一起深入探讨了 Kafka 的, 基础知识和集群架构，下一篇会从Kafka 三高(高性能, 高可用, 高并发)方面来详细阐述其巧妙的设计思想。大家期待.....

4.一文搞定：Flink与Kafka之间的精准一次性

在上一篇文章当中，也算是比较详细且通俗的聊了聊Flink是如何通过checkpoint机制来完成数据精准一次性的实现的。并且也在上一章的结尾表示，要在接下来聊一聊Flink与它的铁哥们Kafaka之间，是如何实现数据的精准一次性消费的。

本次的聊法，还是要通过以kafka（source）->Flink,Flink(source)->Kafka来分别展开讨论。

kafka是一个具有数据保存、数据回放能力的消息队列，说白了就是kafka中的每一个数据，都有一个专门的标记作为标识。而在Flink消费kafka传入的数据的时候，source任务就能够将这个偏移量以算子状态的角色进行保存，写入到设定好的检查点中。这样一旦发生故障，Flink中的FlinkKafkaProduce连接器就i能够按照自己保存的偏移量，自己去Kafka中重新拉取数据，也正是通过这种方式，就能够确保Kafka到Flink之间的精准一次性。

在上一篇文章当中，已经表明了，如果想要让输出端能够进行精准一次性消费，就需要使用到幂等性或者是事务。而事务中的两阶段提交是所有方案里面的实现。

其实Flink到Kafak之间也是采用了这种方式，具体的可以看一下ctrl进到FlinkKafkaProduce连接器内部去看一看：

这也就表明了，当数据通过Flink发送给sink端Kafka的时候，是经历了两个阶段的处理的。阶段就是Flink向Kafka中插入数据，进入预提交阶段。当JobMar发送的Ckeckpoint保存成功信号过来之后，才会提交事务进行正式的数据发送，也就是让原来不可用的数据可以被使用了。

这个实现过程到目前阶段就很清晰了，它的主体流程无非就是在开启检查点之后，由JobMar向各个阶段的处理逻辑发送有关于检查点的barrier。所有的计算任务接收到之后，就会根据自己当前的状态做一个检查点保存。而当这个barrier来到sink任务的时候，sink就会开启一个事务，然后通过这个事务向外预写数据。直到Jobmar来告诉它这一次的检查点已经保存完成了，sink就会进行第二次提交，数据也就算是成功写出了。

1.必须要保证检查点被打开了，如果检查点没有打开，那么之前说的一切话都是空谈。因为Flink默认检查点是关着的。

2.在FlinkKafakProducer连接器的构造函数中要传入参数，这个参数就是用来保证状态一致性的。就是在构造函数的后一个参数输入如下：

3.配置Kafka读取数据的隔离级别

在kafka中有个配置，这个配置用来管理Kafka读取数据的级别。而这个配置默认是能够读取预提交阶段的数据的，所以如果你没改这个配置，那两阶段提交的阶段就是白费了。所以需要改一下这个配置，来更换一下隔离级别：

4.事务超时时间

这个配置也很有意思，大家试想一下。如果要进行两阶段提交，就要保证sink端支持事务，Kafka是支持事务的，但是像这个组件对于很多机制都有一个超时时间的概念，也就是说如果时间到了这个界限还没完成工作，那就会默认这个工作失败。Kafka中由这个概念，Flink中同样由这个概念。但是flink默认超时时间是1小时，而Kafka默认是15分钟，这就有可能出现检查点保存东西的时间大于15分钟，如说是16分钟保存完成然后给sink发送检查点保存陈功可以提交事务的信号，但是这个时候Kafka已经认为事务失败，把之前的数据都扔了。那数据不就是丢失了么。所以说Kafka的超时时间要大于Flink的超时时间才好。

截止到目前为止，基本上把有关于状态维护的一些东西都说完了，有状态后端、有检查点。还通过检查点完成可端到端的数据精准一次性消费。但是想到这我又感觉，如果有学习进度比我一些的，万一没办法很好的理解怎么办。所以在下一篇文章当中我就聊聊Flink中的“状态”到底是个什么东西，都有什么类型，都怎么去用。

大数据Kafka有哪些优势能力呢？

文件传输协议(FTP)是网络上文件传输的一组标准协议。FTP允许用户通过文件作(如添加、删除、修改、检查和传输文件等)与另一台主机进行通信。).Kafka初由Linkedin开发，是一个分布式、分区、多副本、多订户、分布式消息传递系统。如果真的要拿ftp和卡夫卡比较，可以这样描述:1。FTP只需要一个地址和用户名就可以在任何可访问的地方共享文件，主要用于共享文件；2.Kafka一般用于分布式系统或者大数据分析，大部分情况下需要编码，Kafka环境的建立应该比FTB更辅助。

高吞吐量：Kafka 每秒可以生产约 25 万消息（50 MB），每秒处理 55 万消息（110 MB）

持久化数据存储：可进行持久化作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication 防止数据丢失。

分布式系统易于扩展：所有的 producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。

客户端状态维护：消息被处理的状态是在 consumer 端维护，而不是由 server 端维护。当失败时能自动平衡。

Kafka是一种高吞吐量的分布式发布消息系统，它可以处理消费者在网站中的所有动作流数据。 （1）优点：kafka的优点非常多 高性能：单机测试能达到 100w tps；

kafka系列之(3)——Coordinator与offset管理和Consumer Rebalance

consumer group是kafka提供的可扩展且具有容错性的消费者机制。组内可以有多个消费者或消费者实例(consumer instance)，它们共享一个公共的ID，即group ID。组内的所有消费者协调在一起来消费主题(subscribed topics)的所有分区(partition)。

consumer group下可以有一个或多个consumer instance，consumer instance可以是一个进程，也可以是一个线程

group.id是一个字符串，标识一个consumer group

consumer group下的topic下的每个分区只能分配给某个group下的一个consumer(当然该分区还可以被分配给其他group)

Coordinator一般指的是运行在broker上的group Coordinator，用于管理Consumer Group中各个成员，每个Kafka都有一个GroupCoordinator实例，管理多个消费者组，主要用于offset位移管理和Consumer Rebalance。

对于每个Consumer Group，Coordinator会存储以下信息：

consumer group如何确定自己的coordinator是谁呢？ 简单来说分为两步：

消费者在消费的过程中需要记录自己消费了多少数据，即消费位置信息。在Kafka中这个位置信息有个专门的术语：位移(offset)。

(1)、很多消息引擎都把这部分信息保存在端(broker端)。这样做的好处当然是实现简单，但会有三个主要的问题：

1. broker从此变成有状态的，会影响伸缩性；

2. 需要引入应答机制(acknowledgement)来确认消费成功。

3. 由于要保存很多consumer的offset信息，必然引入复杂的数据结构，造成资源浪费。

而Kafka选择了不同的方式：每个consumer group管理自己的位移信息，那么只需要简单的一个整数表示位置就够了；同时可以引入checkpoint机制定期持久化，简化了应答机制的实现。

(2)、Kafka默认是定期帮你自动提交位移的 = true)，你当然可以选择手动提交位移实现自己控制。

(3)、另外kafka会定期把group消费情况保存起来，做成一个offset map，如下图所示：

上图中表明了test-group这个组当前的消费情况。

老版本的位移是提交到zookeeper中的，目录结构是：/consumers//offsets//

，但是zookeeper其实并不适合进行大批量的读写作，尤其是写作。

__consumers_offsets topic配置了compact策略，使得它总是能够保存新的位移信息，既控制了该topic总体的日志容量，也能实现保存新offset的目的。compact的具体原理请参见： Log Compaction

至于每个group保存到__consumers_offsets的哪个分区，如何查看的问题请参见这篇文章： Kafka 如何读取offset topic内容 (__consumer_offsets)

offset提交消息会根据消费组的key(消费组名称)进行分区. 对于一个给定的消费组,它的所有消息都会发送到的broker(即Coordinator)

Coordinator上负责管理offset的组件是 Offset mar 。负责存储,抓取,和维护消费者的offsets. 每个broker都有一个offset mar实例. 有两种具体的实现:

ZookeeperOffsetMar: 调用zookeeper来存储和接收offset（老版本的位移管理）。

DefaultOffsetMar: 提供消费者offsets内置的offset管理。

通过在config/server.properties中的offset.storage参数选择。

DefaultOffsetMar

除了将offset作为logs保存到磁盘上,DefaultOffsetMar维护了一张能快速服务于offset抓取请求的 consumer offsets表 。这个表作为缓存，包含的含仅仅是”offsets topic”的partitions中属于leader partition对应的条目(存储的是offset)。

对于DefaultOffsetMar还有两个其他属性: “和””,默认值都是1。这两个属性会用来自动地创建”offsets topic”。

offset mar接口的概要：

什么是rebalance？

rebalance本质上是一种协议，规定了一个consumer group下的所有consumer如何达成一致来分配topic的每个分区。比如某个group下有20个consumer，它了一个具有100个分区的topic。正常情况下，Kafka平均会为每个consumer分配5个分区。这个分配的过程就叫rebalance。Kafka新版本consumer默认提供了两种分配策略：range和round-robin。

rebalance的触发条件有三种：

组成员发生变更(新consumer加入组、已有consumer主动离开组或已有consumer崩溃了——这两者的区别后面会谈到)

主题数发生变更——这当然是可能的，如果你使用了正则表达式的方式进行，那么新建匹配正则表达式的topic就会触发rebalance

主题的分区数发生变更

refer

Kafka安全机制解析及重构（四）| ACL权限控制

在前三篇文章中我们介绍了Kafka的安全机制，并自己重构了一个名为ABC的SASL机制

Kafka安全机制解析及重构（一）

Kafka安全机制解析及重构（二）

Kafka安全机制解析及重构（二）

我们将用户的权限细分为以下两类：

根据上一篇文章中的配置方法配置好后，Kafka可以实现与Broker之间的连接鉴权，但是也仅仅是连接权限。当按照上一篇的尝试配置好后，如果再配置上Kafka自带的ACL，会发现broker之间无法同步数据，且客户端就算配置上权限，仍然无法访问指定的TOPIC。这与Broker之间通信使用PLAINTEXT机制有关。

我们重读一下Kafka的ACL的说明

Principal指的就是用于校验权限的信息，在我们的机制中，也就是 用户名 。

通过阅读kafka.security.auth.SimpleAclAuthorizer这个类可以发现，在authorize()这个方法中，principal是从session中读取出来的。

可Kafka Broker之间明明是通过PLAINTEXT连接的，不会带上用户名信息的，那总该有个默认的principle吧，这个默认的principal可以在中找到

为了进一步验证broker之间的连接是否是用ANONYMOUS连接的，我们可以开启Kafka的debug日志，在config/log4j.properties中修改配置

然后就可以在logs/kafka-authorizer.log中看到Broker之间互相用ANONYMOUS来访问，然后被拒绝的信息了。

既然明确了Broker之间使用的ANONYMOUS用户，那就好办了，将ANONYMOUS配置成超级用户就行了。我们只需要在server.properties中进行如下的配置，就可以让broker之间恢复正常通信：

需要注意以下两点：

ApacheKafka开源消息系统_kafka源码分析

消息中间价，Kafka，大厂开源，稳定更新，性能优越，顺便介绍kafka的相关知识。

一、kafka是什么？

ApacheKafka是一套开源的消息系统，它初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一个分布式，分区化，可的提交日志服务。现在，LinkedIn公司有三个同事离职创业，继续开发kafka。

二、关键配置项解读

出于性能和实际集群部署情况，我们还是需要讲解一些重要的配置项。除此之外，如果对某个默认参数存在质疑，在详细了解改参数的作用前，建议采用默认配置。

aertised.host.name

注册到zk供用户使用的主机名。内网环境通常无需配置，而IaaS一般需要配置为公网地址。默认为“host.name”，可以通过接口获取该值。

aertised.port

注册到zk供用户使用的服务端口，通常在IaaS环境需要额外配置。

num.partitions

自动创建topic的默认partition数量。默认是1，为了获得更好的性能，建议修改为更大。取值参考后文。

default.replication.factor

自动创建topic的默认副本数量，建议修改为2；但通常一个副本就足够了。

min.insync.replicas

ISR提交生成者请求的小副本数。

unclean.leader.election.enable

是否允许不具备ISR资格的replicas选举为leader作为不得已的措施，甚至不惜牺牲部分数据。默认允许。建议允许。数据异常重要的情况例外。

controlled.shutdown.enable

在kafka收到stop命令或者异常终止时，允许自动同步数据。建议开启。

三、调优考量

配置合适的partitons数量。

这似乎是kafka新手必问得问题。partiton是kafka的并行单元。从procer和broker的视角看，向不同的partition写入是完全并行的；而对于consumer，并发数完全取决于partition的数量，即，如果consumer数量大于partition数量，则必有consumer闲置。所以，我们可以认为kafka的吞吐与partition时线性关系。partition的数量要根据吞吐来推断，定p代表生产者写入单个partition的吞吐，c代表消费者从单个partition消费的吞吐，我们的目标吞吐是t，那么partition的数量应该是t/p和t/c中较大的那一个。实际情况中，p的影响因素有批处理的规模，压缩算法，确认机制和副本数等，然而，多次benchmark的结果表明，单个partition的写入吞吐在10MB/sec左右；c的影响因素是逻辑算法，需要在不同场景下实测得出。

这个结论似乎太书生气和不实用。我们通常建议partition的数量一定要大于等于消费者的数量来实现并发。曾测试过1万个partition的情况，所以不需要太担心partition过多的问题。我建议的做法是，如果是3个broker的集群，有5个消费者，那么建议partition的数量是15，也就是broker和consumer数量的小公倍数。当然，也可以是一个大于消费者的broker数量的倍数，比如6或者9，还请读者自行根据实际环境裁定。