1.初识Kafka

Kafka所"扮演"的三大角色:

消息系统:Kafka和传统的消息系统都具备系统解耦、冗余存储、流量削峰、缓存、异步通信、扩展性、可恢复性等功能。与此同时,Kafka还提供了大多数消息系统难以实现的消息顺序保障及回溯消费功能。
存储系统:Kafka将消息持久化到磁盘,相比较其他的将消息存储在内存的系统而言,能够有效降低丢失的分险。得益于Kafka的存储策略和多副本机制,也可以将Kafka作为长期存储系统使用,只需要把对应的数据保留策略(默认7天)设置为"永久"或者启用主题的日志压缩功能即可。
流式处理平台:Kafka不仅为每个流行的流式处理框架提供了可靠的数据来源,还提供了一个完整的流式处理类库,比如窗口、连接、变换和聚合等各类操作。

基本概念

一个典型的Kafka体系架构包含若干Broker、若干Producer、若干Consumer以及Zookeeper集群。如下图,Zookeeper用来负责集群元数据的管理、控制器的选举等操作。Producer将消息发送到Broker,Broker负责将消息存储到磁盘中,而Consumer负责从Broker订阅并消费消息。
在这里插入图片描述
Producer:生产者,负责创建消息然后将其投递到Kafka中。
Consumer:消费者,负责连接到Kafka上并接收消息,进而处理相应的业务逻辑。
Broker:服务代理节点。可以将Broker看作一个独立的Kafka服务节点或Kafka服务实例。大多数情况下也可以将一个Broker看作是一台服务器节点,前提是这台服务器上只启动了一个Kafka实例。一个或多个Broker组成了一个Kafka集群。

Kafka还有两个重要的概念:
主题(Topic):Kafka中的消息以主题为单位进行归类,生产者负责将消息发送到特定的主题(发送到Kafka的每个消息都要指定一个主题),消费者根据主题订阅消费消息。
分区(Partition):主题是一个逻辑上的概念,它还可以细分为多个分区,一个分区只属于一个主题,很多时候也会把分区称之为主题分区(Topic-partition)。同一个主题下的不同分区包含着不同的消息,分区在存储层面可以看作一个可追加的日志文件,消息被追加到分区日志文件的时候都会分配一个特定的偏移量(offset)。
偏移量(offset):是消息在分区的唯一标识,Kafka通过offset保证消息在分区内的顺序性,不过offset并不跨越分区,也就是说Kafka保证的是分区的有序性而非主题的。
在这里插入图片描述
如图,主题有4个分区,消息被顺序的追加到每个分区的日志文件尾部。Kafka的分区可以分布在不同的服务器(Broker),以此来提供比单个Broker更加强大的功能。

每条消息被发送到Broker之前都会根据分区规则选择存储到那个分区。如果一个主题只对应一个分区,那么整个分区所在的机器I/O将会成为整个主题的性能瓶颈,而多分区解决了整个问题。

选择分区的规则:通常,消息是没有Key这个概念的。比如要发送一条消息,一般直接给出这条消息的内容。由于消息负载要分布到不同的服务端节点,不能让消息老是发送到同一个节点,以免那个节点负担太重(读取的时候也会有问题),一般这种没有key的消息会采用round-robin方式,均衡地发布到不同的分区。
如果指定了消息的key,为消息选择分区的算法是:对key进行散列化后,在与分区的数量取模运算得到分区编号。因为对一个不变的key进行散列化的结果永远是同一个值,所以只有分区数量不变,相同key的所有消息总是会被写到同一个分区。

kafka为分区引入了多副本(Replica)机制,可以通过增加副本提升容错能力。
同一分区的副本中保存的是相同的消息(同一个时刻,可能不同),副本是“一主多从”的关系,其中leader副本(主副本)负责处理读写请求,follower副本(从副本)只负责与leader副本的消息同步。副本处于不同的Broker中,当leader副本出现故障时,从follower副本中重新选举新的leader副本对外提供服务。Kafka通过多副本机制实现了故障自动转移,当主副本故障时,保存服务依然可用。
在这里插入图片描述
如图,消费者生产者只和leader副本交互,而follower副本只负责消息的同步,很多时候follower副本中的消息相对leader而言有一定的滞后。

Kafka消费端也具备一定的容错能力。Consumer使用拉(Pull)模式从服务端拉取消息,并且保存消费的具体位置,当消费者宕机恢复上线后可以根据之前保存的位置重新拉取需要的消息消费,这样就不会造成消息丢失。

所有与leader副本保持一定程度同步的副本(包括leader副本在内)组成ISR(In-Sync Replicas)。消息会发送到leader副本,然后follower副本才能从leader副本中拉取消息进行同步,同步期间follower副本相对于leader副本会有一定程度滞后。这个“一定程度滞后”是指可以忍受的范围,这个范围可以通过参数进行配置。与leader副本同步滞后过多的副本(不包括leader副本)组成OSR(Out-of-Sync Replicas)。

leader副本负责维护和跟踪ISR集合中所有副本的滞后状态,当其中某个follower副本落后太多或者失效时,那么leader副本会把它从集合剔除。如果OSR集合中有follower副本“追上”了leader副本,那么leader副本会把这个follower副本从OSR集合转移到ISR集合。默认情况下,如果leader副本发送故障时,只有ISR集合的follower副本有资格被选举为新的leader副本,而OSR集合的副本是没有机会的(该原则同样可以通过修改相应参数配置改变)。

ISR与HW和LEO也有紧密关系。HW是 High Watermark 的缩写,俗称高水位,它标识了一个特定的消息偏移量(offset),消费者只能拉取到这个 offset 之前的消息。
在这里插入图片描述
如果,这个日志文件有9条消息,第一个条消息的offset为0,最后一条为8,9的那条是待写入的。日志文件的HW为6,表示消费者只能消费offset为0-5的消息,offset为6的消息对消费者来说是不可见的。

LEO是 Log End Offset 的缩写,它表示当前日志文件中下一条待写入的消息。上图中offset为9的位置为当前日志文件的LEO,LEO的大小相当于当前日志文件的最大offset值+1。分区ISR集合中的每个副本都会维护自身的LEO,而ISR集合中最小的LE即为分区的HW,对消费者而言只能消费HW之前的消息。

在这里插入图片描述
假设一个分区有三个副本,一个leader和两个follower,此时分区的LEO和HW都是3。
在这里插入图片描述
消息3和消息4从生产者发出后会先存入leader副本,然后follower副本去拉取leader副本的消息进行同步。
在这里插入图片描述
在同步过程中,因为效率问题,follower只拉取了部分。那么leader和follower1的LEO为5,follower2的LEO为4,此时HW取分区最小值,HW为4,消费者可以消费offset为0-3之间的消息。
在这里插入图片描述
如果所有副本都成功写入了消息3和4,整个分区的HW和LEO都变为5,那么消费者可以消费offset 0-4的消息。

由此可见,Kafka 的复制机制既不是完全的同步复制,也不是单纯的异步复制。事实上,同步复制要求所有能工作的 follower 副本都复制完,这条消息才会被确认为已成功提交,这种复制方式极大地影响了性能。而在异步复制方式下,follower 副本异步地从 leader 副本中复制数据,数据只要被 leader 副本写入就被认为已经成功提交。在这种异步情况下,如果 follower 副本都还没有复制完而落后于 leader 副本,突然 leader 副本宕机,则会造成数据丢失。Kafka 使用的这种 ISR 的方式则有效地权衡了数据可靠性和性能之间的关系。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值