kafka实战,自我深度剖析

资料来源： http://r6d.cn/bdjdi

Kafka概述Kafka概述： Kafka是由链接插件开放源代码的。

kafka-高生产的分布式消息系统(a high-throughputdistributedmessagingsystem )。

Kafka是基于高吞吐量、分布式、分发订阅的消息系统，可以利用Kafka技术在廉价的PC服务器上构建大规模的消息系统。

Kafka的特性：高吞吐量、低延迟： Kafka每秒可以处理十万条消息，延迟最少为几毫秒，每个主题可以分为多个分区，consumer group对分区进行captition

可扩展性： kafka群集支持热扩展；

持久性、可靠性：消息持久化到本地磁盘，支持数据备份以防止数据丢失。

容错：允许群集中的节点失败(如果副本数为n，则允许n-1节点失败)；

高并发：支持数千个客户端同时读写；

支持实时在线处理和离线处理：可以使用Storm这样的实时流媒体系统实时处理消息，同时也可以使用Hadoop这样的批处理系统进行离线处理。

Kafka应用场景：图： Kafka应用场景Kafka与其他组件相比，具有消息持久化、高吞吐量、分布式、多客户端支持、实时等特性，可用于常规消息收集、网站

日志收集：一家公司可以在Kafka上收集各种服务的日志，通过Kafka可以作为集成接口服务向各种consumer开放，如Hadoop、Hbase、Solr等

消息系统：解耦、生产者和消费者、缓存消息等

用户活动跟踪： Kafka常用于记录web用户和app用户的活动，如web浏览、搜索和点击。 这些活动信息由各项服务发布到Kafka的topic，读者订阅这些topic进行实时监控分析，或者加载到Hadoop或数据仓库进行脱机分析和挖掘。

运营指标： Kafka也常用于记录运营监控数据。 包括收集各种分布式APP应用程序的数据，并为各种操作(如报警和报告)提供集中反馈

流：例如spark streaming和storm；

事件源；

kafka在FusionInsight中的位置：

图： Kafka在FusionInsight中的位置Kafka用作支持在线和脱机消息处理的分布式消息系统，并提供了Java API以供其他组件与坞站连接。

afka体系结构和功能Kafka体系结构：图： Kafka体系结构图的基本概念：

Broker:Kafka群集包含一个或多个称为Broker的服务实例。 是Kafka中具体处理数据的单元。 Kafka支持Broker水平扩展。 一般来说，Broker数据越多，集群的吞吐量就越强。

topic :发布到Kafka群集的所有邮件都有一个称为topic的类别。

Partition:Kafka将Topic分为一个或多个Partition，每个Partition在物理上与一个文件夹相对应，该文件下存储该Partition的所有邮件。

producer :负责向Kafka中介发布信息。

Consumer :信息消费者，从Kafka中介读取信息的客户端。

客户组：每个客户都属于特定的客户组。 您可以为每个Consumer指定组名称。

ZooKeeper:kafka与Zookeeper级联，由Zookeeper管理级联配置，并选择Leader。

Kafka Topics :照片； Kafka Topics为发布到Kafka的每封邮件都有一个类别。 此类别称为Topic，也可以理解为存储消息的队列。 例如，天气可以作为Topic，将每天的温度信息保存在“天气”这一列中。 数据总数是先进先出。 后面的数据将添加到后面。

Kafka分区：照片： Kafka分区每个主题由一个或多个分区组成。 每个分区都是有序、不变的消息队列。 引入了Partition机制，保证了Kafka的高吞吐量能力。

每个分区都存储一个日志文件，其中记录了所有消息文件。 一个主题的多个分区分布在不同的Kafka节点上。 这样，包括Producer和Consumer在内的多个客户端就可以同时访问不同的节点，并对同一主题读取消息。

图：分区主题分区数可以在创建时设置。

分区数据决定了每个客户组并发消费者的最大数据。

Consumer group A有两个消费者读取四个分区

数据；Consumer group B有四个消费者来读取4个partition中数据。

Kafka Partition offset:

图：Kafka Partition offset

任何发布到此Partition的消息都会被直接追加到log文件的尾部。

每条消息在文件中的位置称为offset（偏移量），offset是一个long型数字，它唯一标记一条消息。消费者通过（offset、partition、topic）跟踪记录。

Kafka不支持消息的随机读取。

Kafak Partition Replicas（副本）:

图：副本机制

副本以分区为单位。每个分区都有各自的主副本。

可以通过配置文件，配置副本的个数。

一个Kafka集群中，各个节点可能互为Leader和Follower。

主副本叫做Leader，从副本叫做Follower，处于同步状态的副本叫做In-Sync Replicas（ISR）。

如果Leader失效，那么将会有其他的Follower来接管成为新的Leader。如果由于Follower自身的原因，比如网络原因导致同步落后太多，那么当Leader失效后，就不会将这个Follower选为leader。

由于Leader的Server承载了全部的请求压力，因此从集群的整体考虑，Kafka会将Leader均衡的分散在每个实例上，来保持整体稳定。

Follower通过拉取的方式从Leader中同步数据。消费者和生产这都是从Leader中读取数据，不与Follower交互。

主副本和从副本的数据同步：

图：主副本和从副本的数据同步

从Partition的Leader复制数据到Follower，需要一个线程，实际上，复制数据的操作，是Follower主动从Leader上批量拉取数据，这就极大的提高了Kafka的吞吐量。Follower复制数据的线程叫做ReplicaFetcher Thread，而Kafka的Producer和Consumer只与Leader进行交互，不会与Follower进行交互。

图片

Kafka中每个Broker启动的时候，都会创建一个副本管理服务ReplicaManager，该服务负责维护ReplicaFether Thread与其他Broker链路连接关系。该服务中存在的Follower Partition对应的Leader Partition会分布在不同的Broker上，这些Broker创建相同数量的ReplicaFether Thread，同步对应Partition数据。

Kafka中Partition间复制数据，是由Follower主动从Leader拉消息的。Follower每次读取消息都会更新HW状态，用于记录当前最新消息的标识。每当Follower的Partition发生变化而影响Leader所在的Broker时，ReplicaManager就会新建或者销毁相对应的ReplicaFether Thread。

推荐：Java面试练题宝典

Kafka Logs：

为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索性文件。Kafka把Topic中一个Partition大文件分成多个小文件段通过多个小文件段，就容易定期清除或删除已经消费完的文件，减少磁盘占用。

Kafka的存储布局非常简单，Topic的每个分区对应一个逻辑日志，物理上一个日志为相同大小的一个分糊涂的心情。每次Producer发布一个消息到一个分区的时候，代理就将这些数据追加到最后一个糊涂的心情当中。当发布的消息数量达到消息设定的阈值，或者经过一定的时间后，糊涂的心情就会真正的写到磁盘当中。在写入完成以后，消息就会公开给Consumer。

同一个Topic下有不同的分区，每个分区会划分为多个文件，只有一个当前文件在写，其他文件是只读的。当写满一个文件（即达到某个设定的值）Kafka会新建一个空文件继续来写。而老文件切换为只读。

文件的命名以起始的偏移量来进行命名。Segment Files由两大部分组成，分别为Index file和data file，此两个文件一一对应成对出现。后缀 .index 和 .log 就分别表示为Segment的索引文件和数据文件。Segment文件的命名规则是：Partition全局的第一个Segment从0开始，后续每个segment文件为上一个全局Partition的最大offset，这个数据时64位的long型数据。

如果没有数据就用0进行填充。通常把日志文件默认为1G，当达到1G就会创建新的Log文件和index文件。如果设置的参数过小，会产生大量的log文件和index文件，系统在启动的时候就需要加载大量的index到内存，占用大量的句柄。如果设置的太大，分糊涂的心情又比较少，不利于快速的查找。Kafka就是通过索引实现快速的定位message。

图：索引文件

通过索引信息可以快速定位message。

通过将index元数据全部映射到memory，可以避免segment file的index数据IO磁盘操作。

通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。

稀疏存储：将原来完整的数据，只间隔的选择多条数据进行存储。

Kafka Log Cleanup:

日志的清理方式有两种：delete和compact。

删除的阈值有两种：过期的时间和分区内总日志大小。

删除 图：日志清理方式–compact

compact操作是保存每个消息的最新value值。消息时顺序存储的，offset大的为最新的数据。

Kafka数据可靠性：

Kafka所有消息都会被持久化到磁盘中，同时Kafka通过对Topic Partition设置Replication来保障数据可靠。

消息传输过程中保障通常有以下三种：

最多一次（At Most Once）：消息可能丢失；消息不会重复发送和处理。

最少一次（At Lease Once）：消息不会丢失；消息可能会重复发送和处理。

仅有一次（Exactly Once）：消息不会丢失；消息仅被处理一次。

Kafka消息传输保障机制，通过配置不同的消息发送模式来保障消息传输，进而满足不同的可靠性要求应用场景。

可靠 Kafka关键流程 写流程： 图：Kafka写流程–Producer写数据

总体流程：

Producer连接任意存活的Broker，请求制定Topic、Partition的Leader元数据信息，然后直接与对应的Broker直接链接，发布数据。

开发分区接口：

用户可以指定分区函数，使得消息可以根据Key，发送到特定的Partition。

Kafka读流程： 图：Kafka读流程–Consumer读数据

总体流程：

Consumer连接指定Topic Partition所在的Leader Broker，用主动获取方式从Kafka中获取消息。

Kafka在Zookeeper上的目录结构 Zookeeper在Kafka的作用：

无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。

Kafka使用zookeeper作为其分布式协调框架，很好的将消息生产、消息存储、消息消费的过程结合在一起。

同时借助zookeeper，kafka能够生产者、消费者和broker在内的所以组件在无状态的情况下，建立起生产者和消费者的订阅关系，并实现生产者与消费者的负载均衡。

Zookeeper Shell：

通过zkCli来连接正在运行的Zookeeper Shell客户端，可以通过ls和get命令来获取Kafka相关信息。

图：用法示例 Kafka in ZooKeeper： 图：Kafka在ZooKeeper中的目录结构 Kafka Cluster Mirroring 镜像

Kafka Cluster Mirroring是Kafka跨集群数据同步方案，通过Kafka内置的MirrorMaker工具来实现。通过Mirror Maker工具中的consumer从源集群消费数据，然后再通过内置的Producer，将数据重新发布到目标集群。

推荐好文强大，10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程！分享一套基于SpringBoot和Vue的企业级中后台开源项目，代码很规范！能挣钱的，开源 SpringBoot 商城系统，功能超全，超漂亮！