加入收藏 | 设为首页 |

雷火电竞登录-深化了解Apache Kafka的高可靠性原理

海外新闻 时间: 浏览:181 次

深化了解Apache Kafka的高可靠性原理

现在,许多开源散布式处理系统如Cloudera、Apache Storm、Spark等都支撑与Kafka的集成。Kafka越来越遭到许多互联网公司的喜爱,它们将Kafka作为其间心音讯引擎之一。

在本文中,咱们将了解Kakfa存储机制、仿制原理、同步原理和持久性确保,以剖析其可靠性。

如图所示,一个典型的Kafka架构包含几个生产者(可所以服务器日志、事务数据、由页面前雷火电竞登录-深化了解Apache Kafka的高可靠性原理端生成的页面视图等)、几个broker(Kafka支撑水平扩展,更通用的署理)、几个顾客(组)和一个Zookeeper集群。Kafka经过Zookeeper办理集群装备,挑选领导者,并在顾客组发作更改时从头平衡。生产者运用推形式向署理发布音讯,顾客运用拉形式订阅和消费来自署理的音讯。

Topics and Partitions

Partition是一个物理概念,Topic是一个逻辑概念。每个提交到Kafka集群的音讯都有一个类别,这个类别称为Topic,每个主题将雷火电竞登录-深化了解Apache Kafka的高可靠性原理被划分为多个分区,每个分区是存储等级的附加日志文件。文件中每个音讯的方位称为偏移量,偏移量是一个long数字,是仅有标识符。

众所周知,次序写磁盘比随机写内存更有用。关于Kafka的高吞吐量,每个音讯都附加到分区,这是对磁盘的次序写入,因而十分有用。

分区处理了功能瓶颈问题。经过设置分区规矩,能够将一切音讯均匀地散布到不同的分区,然后完成必定程度的扩展。在创立topic时,能够在$KAFKA_HOME /config/ server中指定分区的数量。特点,当然,您还能够在创立topic之后更改分区的数量。在发送音讯时,能够指定此音讯的密钥,依据密钥和分区机制承认发送到哪个分区的此音讯的生成器。

Kafka强健的仿制战略确保了它的高可靠性。

经过解说Kafka的仿制原理和同步办法,咱们现已达到了能够开端探究微观层次Kafka概念的阶段。现在,让咱们从不同的维度开端探究Kafka,比方ISR(同步副本)、HW(高水位)、leader election以及数据可靠性和持久性确保。

Topics and Partitions是怎么存储的?

Kafka中的音讯按topic分类。生产者经过topic向Kafka的broker发送音讯,顾客经过topic读取数据。一个topic能够划分为多个分区,而分区又能够细分为多个段,因而一个分区在物理上由多个段组成。

为了便于阐明,我将在这儿显现在单个节点集群上的文件只要一个Kafka broker。Kafka音讯文件存储目录的方位如下:

[root@tools ~]# ls -ltr /kafka-logs/
total 20
-rw-r--r--. 1 kafka hadoop 57 Aug 10 15:22 meta.properties
drwxr-xr-x. 2 kafka hadoop 70 Aug 11 02:46 __consumer_offsets-0
drwxr-xr-x. 2 kafka hadoop 70 Aug 11 02:46 __consumer_offsets-29
drwxr-xr-x. 2 kafka hadoop 70 Aug 11 02:46 __consumer_offsets-10....
drwxr-xr-x. 2 kafka hadoop 70 Aug 11 02:46 __consumer_offsets-3
drwxr-xr-x. 2 kafka hadoop 70 Aug 11 02:46 __consumer_offsets-13
drwxr-xr-x. 2 kafka hadoop 70 Aug 14 10:16 vidtest-0
drwxr-xr-x. 2 kafka hadoop 70 Aug 21 09:51 interns_test-0
drwxr-xr-x. 2 kafka hadoop 70 Aug 28 06:10 medicalschema-0
-rw-r--r--. 1 kafka hadoop 34 Aug 30 15:28 cleaner-offset-checkpoint
drwxr-xr-x. 2 kafka hadoop 4096 Aug 30 15:29 __consumer_offsets-48
drwxr-xr-x. 2 kafka hadoop 70 Sep 18 23:31 imagetext-0
drwxr-xr-x. 2 kafka hadoop 70 Nov 17 12:29 imageobject-0
drwxr-xr-x. 2 kafka hadoop 70 Nov 19 02:05 my-topic-0
-rw-r--r--. 1 kafka hadoop 1392 Nov 22 02:31 recovery-point-offset-checkpoint
-rw-r--r--. 1 kafka hadoop 1392 Nov 22 02:32 replication-offset-checkpoint

您能够经过修正"server.properties"来更改kafka-logs目录的方位。server.properties文件,坐落$KAFKA_HOME/config下。让咱们假定分区是最小的存储单元,咱们能够幻想当Kafka producer不断发送音讯时,不可防止地会导致分区文件的无限胀大,这将严重影响音讯文件的保护和所消费音讯的铲除。因雷火电竞登录-深化了解Apache Kafka的高可靠性原理而,能够把分区分隔为段 。每个分区相当于一个巨大的文件被等分红多个巨细持平的段(段)数据文件(每个段文件中的音讯数不必定持平)。段文件的生命周期能够经过修正服务器装备参数(log.segment.bytes, log.roll)。

段文件由两部分组成,即". Index" 文件and ".log"文件。 别离作为段索引文件和数据文件。这两个文件一一对应。

[root@tools~]# ls -ltr /kafka-logs/__consumer_offsets-5/
total 0
-rw-r--r--. 1 kafka hadoop 0 Aug 11 02:46 00000000000000000000.log
-rw-r--r--. 1 kafka hadoop 10485760 Nov 21 23:28 00000000000000000000.index

".index"索引文件存储了很多的元数据。".log"数据文件存储很多的音讯,索引文件中的元数据指向相应数据文件中音讯的物理偏移地址。这两个文件的命名约好如下:分区榜首部分从0开端,每个后续部分文件名的偏移值是最终一段的最终音讯文件,该值为64位巨细,20位字符的长度,空位用0填充。 segment中index和data file对应联系物理结构如下:

如上所示,咱们有170410段,其间包含0000000000000170410.inedx索引和0000000000000170410.log文件。以".index"中的元数据[3,348]为例。 第三条音讯表明在".log"数据文件,即170410 + 3 = 170413条音讯在大局分区中,物理偏移量为348在部分段文件中。

怎么从分区偏移量中查找音讯?

假定咱们有下面特定段的文件,咱们想读取雷火电竞登录-深化了解Apache Kafka的高可靠性原理offset = 170418的音讯。首要找到段文件,其间00000000000000000000.index的 文件的最初,第二个文件是00000000000000170410.index (开端偏移量170410 +1 = 170411),第三个文件是00000000000000239430.index(开端偏移量为239430 + 1 = 239431),因而这个偏移量= 170418归于第二个文件。

00000000000000000000.index 00000000000000000000.log 00000000000000170410.index 00000000000000170410.log 00000000000000239430.index00000000000000239430.log

仿制和同步

为了进步音讯的可靠性,Kafka为每个主题分区供给了N个副本,其间N(大于或等于1)是主题副本因子的数量。Kafka运用多仿制机制主动进行毛病搬运,并确保当Kafka集群中的署理发作毛病时,服务是可用的。在Kafka N副本中,一个是leaderr副本,另一个是follower, leader担任处理一切的分区读和写恳求,一起follower被动地、有规则地从leader那里仿制数据。

Kafka供给了一个数据仿制仿制算法,以确保假如leader失利或挂起,将选出一个新的leader,而且client端的音讯会被成功写入。leader担任保护和盯梢ISR (in - sync Replicas,kafka不是彻底同步,也不是彻底异步,是一种ISR机制)中一切follower lags的状况,这些滞后状况指示一个仿制同步行列。当生产者向broker发送音讯时,leader写音讯并将其仿制给一切follower。音讯提交后成功地仿制到一切同步副本。音讯仿制推迟受最慢的follower的约束,快速检测slow copies十分重要,假如follower过分"滞后"或失利,则leader会将其从ISR中删去。

这儿的中心问题是,在海量的 topic 情况下,或许经常性的流量颤动情况下,咱们不能对 topic 的producer 每次打过来的音讯数目做任何假定,所以就不太好定出来一个 适宜的 replica.lag.max.messages 值

replica.lag.max.messages参数在0.10版别之后被删去。只是留下了replica.lag.time.max.ms (delay)作为ISR中用于副本办理的参数。设置太大,将影响真实推迟的follower被删去;设置太小,导致follower被频频的拜访(performance issue)。让咱们看看问题地点,关于replica.lag.max.messages,假如当时leader音讯的副本数量超越该参数的follower messages的值,则leader将从ISR中删去follower。假定你雷火电竞登录-深化了解Apache Kafka的高可靠性原理设置replica.lag.max.messages = 4,假如producer发送到broker的音讯数量小于4时, follower从leader那里接收到音讯后,假如follower落后了,follower开端拉这些音讯,可是音讯数量不会超越4条,所以没有follower从ISR中删去,所以这次replica.lag.max.message似乎是合理的。可是,producer建议一个瞬时峰值流,producer一次发送4条以上的音讯时,这就超越replica.lag.max.messages,follower被以为与leader不同步,因而follower被踢出ISR。但事实上,这些follower是活着的,没有任何功能问题。不久,他们追上了leader,从头加入了ISR。因而,它们不断地勾选ISRs并再次回来ISRs,这无疑增加了不必要的功能开支。

这段或许不太好了解,简而言之:

在 follower 落后 le我的世界2ader 超越 replica.lag.max.messages = 4 条音讯的时分,不会立马踢出ISR 调集,而是持续落后超越 replica.lag.time.max.ms 时刻,才会被踢出 ,这样就能防止流量颤动形成的运维问题,由于follower 鄙人一次fetch的时分就会跟上leader.

上面的部分也提到了HW这个概念。HW一般称为高水位,取一个分区对应的最小ISR LEO(Log End Offset)作为HW,顾客只能消费HW地点的方位。此外,每个副本都有HW, leader和follower担任更新它们的HW状况。关于leader新写的信息,顾客不能当即消费。当ISR中的一切副本都已同步后,leader将等候更新音讯。

request.required.acks,设置数据可靠性等级的acks参数:

1(默认值):这意味着生产者在领导者成功接收到ISR中的数据并得到承认后发送下一条音讯。假如leader封闭,它将丢掉数据。

0:这意味着生产者不需求等候署理的承认就能够持续发送下一批音讯。在这种情况下,数据传输功率最高,但数据的可靠性的确最低。

-1:生产者需求等候ISR中一切的follower承认数据收到后发送一次,这是可靠性最高的。可是,这并不确保数据不会丢掉。

假如想进步数据的可靠性,请设置request.required.acks= -1,一起设置min.insync.replicas此参数(能够在署理或主题等级设置该参数)以完成最大功率。该参数设置ISR中副本的最小数量。默认值是1。当且仅request.required.acks参数设置为-1时,此参数才收效。假如ISR中的仿制数小于min.insync.replicas,客户端将回来一个反常。replicas装备:org.apache.kafka.common.errors . notenoughreplicasexceptoin:音讯被回绝,由于同步的副本比所需的少。