引言:来到了新公司,需要对kafka组件有很深的研究,本人之前对老版的kafka有过一定的研究,但是谈不上深入,新公司力推kafka,比较kafka作为消息系统在目前的市场上的占有率还是很高的,可以看本人之前kafka的博客中有关kafka的优点和为什么要用kafka。
在众多优点中,我本人认为最重要的2个优点如下:
创新互联公司是专业的千山网站建设公司,千山接单;提供网站制作、成都做网站,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行千山网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
1、削峰
数据库的处理能力是有限的,在峰值期,过多的请求落到后台,一旦超过系统的处理能力,可能会使系统挂掉。
如上图所示,系统的处理能力是 2k/s,MQ 处理能力是 8k/s,峰值请求 5k/s,MQ 的处理能力远远大于数据库,在高峰期,请求可以先积压在 MQ 中,系统可以根据自身的处理能力以 2k/s 的速度消费这些请求。
这样等高峰期一过,请求可能只有 100/s,系统可以很快的消费掉积压在 MQ 中的请求。
注意,上面的请求指的是写请求,查询请求一般通过缓存解决。
2、解耦
如下场景,S 系统与 A、B、C 系统紧密耦合。由于需求变动,A 系统修改了相关代码,S 系统也需要调整 A 相关的代码。
过几天,C 系统需要删除,S 紧跟着删除 C 相关代码;又过了几天,需要新增 D 系统,S 系统又要添加与 D 相关的代码;再过几天,程序猿疯了...
这样各个系统紧密耦合,不利于维护,也不利于扩展。现在引入 MQ,A 系统变动,A 自己修改自己的代码即可;C 系统删除,直接取消订阅;D 系统新增,订阅相关消息即可。
这样通过引入消息中间件,使各个系统都与 MQ 交互,从而避免它们之间的错综复杂的调用关系。
kafka架构原理:
最经典的图也就是官方的图了
找了一些其他博主的图:这里自己就懒的画了
详细复杂的kafka架构
通俗点讲:就是producer ----> kafka cluster(brokers) -----> consumer
生产者生产消息 经过 kafka队列 被消费者消费
相关的组件概念见:
topic and logs
废话不多说,先见图
文字解释如下:
Message 是按照 Topic 来组织的,每个 Topic 可以分成多个 Partition(对server.properties/num.partitions)。 本人习惯性配置文件为num.partitions=broker个数,人为的分配到各个节点上。
Partition 中的每条记录(Message)包含三个属性:Offset,messageSize 和 Data。
其中 Offset 表示消息偏移量;messageSize 表示消息的大小;Data 表示消息的具体内容。
Partition 是以文件的形式存储在文件系统中,位置由 server.properties/log.dirs 指定,其命名规则为 <topic_name>-<partition_id>。
生产配置文件为:log.dirs=/data/kafka/kafka-logs
[hadoop@kafka03-55-13 kafka-logs]$ pwd
/data/kafka/kafka-logs
[hadoop@kafka03-55-13 kafka-logs]$ ls |grep mjh
topic-by-mjh-0
topic-by-mjh-1
topic-by-mjh-10
topic-by-mjh-11
topic-by-mjh-12
...
...
...
Partition 可能位于不同的 Broker 上,Partition 是分段的,每个段是一个 Segment 文件。
Partition 目录下包括了数据文件和索引文件
[hadoop@kafka03-55-13 kafka-logs]$ cd topic-by-mjh-0
[hadoop@kafka03-55-13 topic-by-mjh-0]$ ll
total 4
-rw-rw-r-- 1 hadoop hadoop 10485760 Aug 24 20:13 00000000000000000334.index
-rw-rw-r-- 1 hadoop hadoop 0 Aug 13 17:42 00000000000000000334.log
-rw-rw-r-- 1 hadoop hadoop 10485756 Aug 24 20:13 00000000000000000334.timeindex
-rw-rw-r-- 1 hadoop hadoop 4 Aug 16 14:16 leader-epoch-checkpoint
Index 采用稀疏存储的方式,它不会为每一条 Message 都建立索引,而是每隔一定的字节数建立一条索引,避免索引文件占用过多的空间。
缺点是没有建立索引的 Offset 不能一次定位到 Message 的位置,需要做一次顺序扫描,但是扫描的范围很小。
索引包含两个部分(均为 4 个字节的数字),分别为相对 Offset 和 Position。
相对 Offset 表示 Segment 文件中的 Offset,Position 表示 Message 在数据文件中的位置。
Segment下的log文件就是存储消息的地方
每个消息都会包含消息体、offset、timestamp、key、size、压缩编码器、校验和、消息版本号等。
在磁盘上的数据格式和producer发送到broker的数据格式一模一样,也和consumer收到的数据格式一模一样。由于磁盘格式与consumer以及producer的数据格式一模一样,这样就使得Kafka可以通过零拷贝(zero-copy)技术来提高传输效率。 // 关于零拷贝技术,后期会专门写一遍博客来解释
小结:
1、Partition 是一个顺序的追加日志,属于顺序写磁盘(顺序写磁盘效率比随机写内存要高,保障 Kafka 吞吐率)。
2、Kafka 的 Message 存储采用了分区(Partition),磁盘顺序读写,分段(LogSegment)和稀疏索引这几个手段来达到高效性。
3、在 Kafka 的文件存储中,同一个 Topic 下有多个不同的 Partition,每个 Partition 都为一个目录,而每一个目录又被平均分配成多个大小相等的 Segment File 中(Segment 大小我们在生产上设置成1G或者 500MB ),Segment File 又由 index file 和 data file 组成,他们总是成对出现,后缀 ".index" 和 ".log" 分表表示 Segment 索引文件和数据文件。
Partition and Replica
一个 Topic 物理上分为多个 Partition,位于不同的 Broker 上。如果没有 Replica,一旦 Broker 宕机,其上所有的 Patition 将不可用。
每个 Partition 可以有多个Replica(对应server.properties/default.replication.factor),分配到不同的 Broker 上。本人默认习惯为 default.replication.factor=2 也就是默认2个副本,比较合理
其中有一个 Leader 负责读写,处理来自 Producer 和 Consumer 的请求;其他作为 Follower 从 Leader Pull 消息,保持与 Leader 的同步。
如何分配 Partition 和 Replica 到 Broker 上?步骤如下:
1、将所有 Broker(假设共 n 个 Broker)和待分配的 Partition 排序。
2、将第 i 个 Partition 分配到第(i mod n)个 Broker 上。
3、将第 i 个 Partition 的第 j 个 Replica 分配到第((i + j) mode n)个 Broker 上。
根据上面的分配规则,若 Replica 的数量大于 Broker 的数量,必定会有两个相同的 Replica 分配到同一个 Broker 上,产生冗余。因此 Replica 的数量应该小于或等于 Broker 的数量。
//这里kafka硬性规定了创建的replica不能超过broker的数量,必须等于小于broker的数量
这里有2个算法函数解释一下
1、mod:求余函数;
2、mode:返回在某数组或数据区域中出现频率最多的数值,mode是一个位置测量函数。
我这里只有3个broker 创建4个replica就出现报错 具体见下
[root@kafka02-55-12 ~]# kafka-topics.sh --zookeeper 10.211.55.11:2181,10.211.55.12:2181,10.211.55.13:2181/kafkagroup --replication-factor 4 --partitions 9 --create --topic topic-zhuhair
**Error while executing topic command : Replication factor: 4 larger than available brokers: 3.**
[2019-08-24 20:41:40,611] ERROR org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 4 larger than available brokers: 3.
pratition的leader是如何选举的---broker failover故障转移
//通俗点讲也就是当broker发生宕机了,如何保证高可用的
文字描述如下:
Kafka 在 Zookeeper 中(/brokers/topics/[topic]/partitions/[partition]/state)动态维护了一个 ISR(in-sync replicas)。
ISR 里面的所有 Replica 都"跟上"了 Leader,Controller 将会从 ISR 里选一个做 Leader。
具体流程文字描述如下:
1、Controller 在 Zookeeper 的 /brokers/ids/[brokerId] 节点注册 Watcher,
2、当 Broker 宕机时 Zookeeper 会 Fire Watch。
3、Controller 从 /brokers/ids 节点读取可用 Broker。
4、Controller 决定 set_p,该集合包含宕机 Broker 上的所有 Partition。
5、对 set_p 中的每一个 Partition,从/brokers/topics/[topic]/partitions/[partition]/state 节点读取 ISR,决定新 Leader,将新 Leader、ISR、controller_epoch 和 leader_epoch 等信息写入 State 节点。
6、zk通过 RPC 向相关 Broker 发送 leaderAndISRRequest 命令。
极端情况下需要考虑的是:
当 ISR 为空时,会选一个 Replica(不一定是 ISR 成员)作为 Leader;
当所有的 Replica 都歇菜了,会等任意一个 Replica 复活,将其作为 Leader。
//
这就需要在可用性和一致性当中作出一个简单的折衷。如果一定要等待ISR中的Replica“活”过来,那不可用的时间就可能会相对较长。而且如果ISR中的所有Replica都无法“活”过来了,或者数据都丢失了,这个Partition将永远不可用。选择第一个“活”过来的Replica作为Leader,而这个Replica不是ISR中的Replica,那即使它并不保证已经包含了所有已commit的消息,它也会成为Leader而作为consumer的数据源(前文有说明,所有读写都由Leader完成)。Kafka0.8.*使用了第二种方式。根据Kafka的文档,在以后的版本中,Kafka支持用户通过配置选择这两种方式中的一种,从而根据不同的使用场景选择高可用性还是强一致性。
ISR(同步列表)中的 Follower 都"跟上"了Leader,"跟上"并不表示完全一致,它由 server.properties/replica.lag.time.max.ms 配置。表示 Leader 等待 Follower 同步消息的最大时间,如果超时,Leader 将 Follower 移除 ISR。配置项 replica.lag.max.messages 已经移除。
Replica 副本如何同步 消息传递同步策略
1、Producer在发布消息到某个Partition时,先通过ZooKeeper找到该Partition的Leader,
2、无论该Topic的Replication Factor为多少,Producer只将该消息发送到该Partition的Leader。
3、Leader会将该消息写入其本地Log。
4、每个Follower都从Leader pull数据。这种方式上,Follower存储的数据顺序与Leader保持一致。
5、Follower在收到该消息并写入其Log后,向Leader发送ACK。
6、一旦Leader收到了ISR中的所有Replica的ACK,该消息就被认为已经commit了,Leader将增加HW并且向Producer发送ACK。
为了提高性能,每个Follower在接收到数据后就立马向Leader发送ACK,而非等到数据写入Log中。
因此,对于已经commit的消息,Kafka只能保证它被存于多个Replica的内存中,而不能保证它们被持久化到磁盘中,也就不能完全保证异常发生后该条消息一定能被Consumer消费。
Consumer读消息也是从Leader读取,只有被commit过的消息才会暴露给Consumer。
具体的可靠性,是由生产者(根据配置项 producer.properties/acks)来决定的。
有资料说 最新的文档 2.2.x request.required.acks 已经不存在了,这一点有待我去确认
通俗一点讲对ack的三个参数的含义为
Kafka producer有三种ack机制 初始化producer时在config中进行配置
0 :意味着producer不等待broker同步完成的确认,继续发送下一条(批)信息
提供了最低的延迟。但是最弱的持久性,当服务器发生故障时,就很可能发生数据丢失。例如leader已经死亡,producer不知情,还会继续发送消息broker接收不到数据就会数据丢失
1:意味着producer要等待leader成功收到数据并得到确认,才发送下一条message。此选项提供了较好的持久性较低的延迟性。Partition的Leader死亡,follwer尚未复制,数据就会丢失
-1:意味着producer得到follwer确认,才发送下一条数据
持久性最好,延时性最差。
在这里强调的一点是,在kafak的partition中的fllower和leader中的复制不是完全的同步复制,也不是单纯的异步复制
同步复制:所有的fllower复制完才提交 这样的缺点是极大的影响了吞吐率
异步复制:Follower异步的从Leader复制数据,数据只要被Leader写入log就被认为已经commit,这种情况下如果Follower都复制完都落后于Leader,而如果Leader突然宕机,则会丢失数据。
所有 kafak采用的是ISR 的方式则很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据,这样极大的提高复制性能(批量写磁盘),极大减少了Follower与Leader的差距。
producer如何发送消息
Producer 首先将消息封装进一个 ProducerRecord 实例中。
写消息的路由模式
1、 指定了 patition,则直接使用;
2、 未指定 patition 但指定 key,通过对 key 的 value 进行hash 选出一个 patition
这个 Hash(即分区机制)由 producer.properties/partitioner.class 指定的类实现,这个路由类需要实现 Partitioner 接口。
3、 patition 和 key 都未指定,使用轮询选出一个 patition。
备注:消息并不会立即发送,而是先进行序列化后,发送给 Partitioner,
也就是上面提到的 Hash 函数,由 Partitioner 确定目标分区后,发送到一块内存缓冲区中(发送队列)。Producer 的另一个工作线程(即 Sender 线程),
则负责实时地从该缓冲区中提取出准备好的消息封装到一个批次内,统一发送到对应的 Broker 中。
具体写数据流程如下:
具体流程如下:
1、 producer 先从 zookeeper 的 "/brokers/.../state" 节点找到该 partition 的 leader
2、 producer 将消息发送给该 leader
3、 leader 将消息写入本地 log
4、 followers 从 leader pull 消息,写入本地 log 后 leader 发送 ACK
5、 leader 收到所有 ISR 中的 replica 的 ACK 后,增加 HW(high watermark,最后 commit 的 offset) 并向 producer 发送 ACK
参考网上的资料,有的文字版的解释是这样的 个人觉得下面的这样的文字解释的更加通俗易懂
流程如下:
1、首先,我们需要创建一个ProducerRecord,这个对象需要包含消息的主题(topic)和值(value),可以选择性指定一个键值(key)或者分区(partition)。
2、发送消息时,生产者会对键值和值序列化成字节数组,然后发送到分配器(partitioner)。
3、如果我们指定了分区,那么分配器返回该分区即可;否则,分配器将会基于键值来选择一个分区并返回。
4、选择完分区后,生产者知道了消息所属的主题和分区,它将这条记录添加到相同主题和分区的批量消息中,另一个线程负责发送这些批量消息到对应的Kafka broker。
5、当broker接收到消息后,如果成功写入则返回一个包含消息的主题、分区及位移的RecordMetadata对象,否则返回异常。
6、生产者接收到结果后,对于异常可能会进行重试。
参考链接:
架构成长之路:Kafka设计原理看了又忘,忘了又看?一文让你掌握: https://www.toutiao.com/i6714606866355192328/
Kafka的ACK机制有三种,是哪三种 : https://blog.csdn.net/Sun1181342029/article/details/87806207
kafka原理系列ACK机制(数据可靠性和持久性保证) https://blog.csdn.net/bluehawksk/article/details/96120803
kafka入门介绍 https://www.orchome.com/5
Kafka学习之路 (三)Kafka的高可用 https://www.cnblogs.com/qingyunzong/p/9004703.html
文章标题:kafka深入研究之路(1)-剖析各原理01
链接地址:https://www.cdcxhl.com/article28/jidhjp.html
成都网站建设公司_创新互联,为您提供品牌网站建设、虚拟主机、用户体验、网站收录、搜索引擎优化、建站公司
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联