张伦聪的技术博客 Research And Development

kafka基本原理


kafka拓扑图

大家都知道kafka是依赖zookeeper集群的,一般最少也要三台服务器来实现HA(高可用)。

为什么zk一定要奇数节点且最少3个节点?

Zookeeper的大部分操作都是通过选举产生的。比如,标记一个写是否成功是要在超过一半节点发送写请求成功时才认为有效。同样,Zookeeper选择领导者节点也是在超过一半节点同意时才有效。最后,Zookeeper是否正常是要根据是否超过一半的节点正常才算正常。这是基于CAP的一致性原理。现在假如有一个6个节点的Zookeeper集群,根据以上规则:至少一半以上的节点正常集群才算正常,那么此种情况下最多只能允许2个节点失败,即失效容忍度为2。假如有一个5个节点的Zookeeper集群,根据以上规则,仍然是允许2个节点失败。因此,从以上例子来看,安装5个节点和6个节点的Zookeeper没有区别,因为失效节点的容忍度是一致性的,那么这样的话,就没有必要多安装一个节点了。

什么是CAP原则

CAP原则又称CAP定理,指的是在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可兼得。CAP原则是NOSQL数据库的基石。Consistency(一致性)。 Availability(可用性)。Partition tolerance(分区容错性)。分布式系统的CAP理论:理论首先把分布式系统中的三个特性进行了如下归纳:

● 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)

● 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)

● 分区容错性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。NoSQL系统通常注重性能和扩展性,而非事务机制(事务就是强一致性的体现)。传统的SQL数据库的事务通常都是支持ACID的强事务机制。A代表原子性,即在事务中执行多个操作是原子性的,要么事务中的操作全部执行,要么一个都不执行;C代表一致性,即保证进行事务的过程中整个数据库的状态是一致的,不会出现数据花掉的情况;I代表隔离性,即两个事务不会相互影响,覆盖彼此数据等;D表示持久化,即事务一旦完成,那么数据应该是被写到安全的,持久化存储的设备上(比如磁盘)。

拓扑图如下,分三层:

1.Producers:消息生产者,push消息给Brokers.发送时根据不同topic选择不同分区(在Broker上)。

2.Brokers:注册在zookeeper节点上。

3.Consumers:消息消费者,从brokers上根据订阅的topic选择不同分区,poll数据,执行消费。

1.producer:消息生产者,发布消息到 kafka 集群的终端或服务。

2.broker:kafka 集群中包含的服务器。

3.topic:每条发布到 kafka 集群的消息属于的类别,即 kafka 是面向 topic 的。

4.partition:partition 是物理上的概念,每个 topic 包含一个或多个 partition。kafka 分配的单位是 partition。

5.consumer:从 kafka 集群中消费消息的终端或服务。

6.Consumer group:high-level consumer API 中,每个 consumer 都属于一个 consumer group,每条消息只能被 consumer group 中的一个 Consumer 消费,但可以被多个 consumer group 消费。

7.replica:partition 的副本,保障 partition 的高可用。

8.leader:replica 中的一个角色, producer 和 consumer 只跟 leader 交互。

9.follower:replica 中的一个角色,从 leader 中复制数据。

10.controller:kafka 集群中的其中一个服务器,用来进行 leader election 以及 各种 failover。

11.zookeeper:kafka 通过 zookeeper 来存储集群的 meta 信息。

生产模型

kafka生产者多线程异步发送模型如下图,主要包含2个流程:1.数据批量存储,批量发送2.Netty NIO 发送数据.

一、数据入池

1.KafkaProducer启动发送消息

2.消息发送拦截器拦截

3.用序列化器把数据进行序列化

4.用分区器选择消息的分区

5.添加进记录累加器

二、NIO发送数据

6.等待数据条数达到批量发送阀值或者新建一个RecoedBatch,立即唤醒Sender线程执行run方法

7.发送器内部从累加器Deque中拿到要发送的数据RecordBatch转换成ClientRequest客户端请求

8.在发送器内部,经由NetworkClient转换成RequestSend(Send接口)并调用Selector暂存进KafkaChannel(NetWorkClient维护的通道Map<String, KafkaChannel> channels)

9.执行nio发送消息(1.Selector.select()2.把KafkaChannel中的Send数据(ByteBuffer[])写入KafkaChannel的写通道GatheringByteChannel)

消费模型

根据xml配置的不同启动不同的容器(ConcurrentMessageListenerContainer/MessageListenerContainer),下图为并发消息监听器容器启动流程,主要包含2个主流程:1.从cluster拉取消息2.消费消息

1.容器启动,轮询执行消费。

2.kafkaConsumer拉取消息流程:

1)Fetcher请求获取器获取请求并存储在unset中

2)ConsumerNetworkClient网络客户端执行poll(),调用NetWlrikClient的send()方法从unset中获取ClientRequest请求转成RequestSend最终塞进Selector的KafkaChannel通道中,Seletcor.send()从kafka集群拉取待消费数据ConsumerRecords

3.消费者监听器MessageListener.onMessage()执行用户自定义的实际消费业务逻辑。

kafka的设计特点

1、吞吐量

高吞吐是kafka需要实现的核心目标之一,为此kafka做了以下一些设计:

数据磁盘持久化:消息不在内存中cache,直接写入到磁盘,充分利用磁盘的顺序读写性能 zero-copy:减少IO操作步骤 数据批量发送 数据压缩 Topic划分为多个partition,提高parallelism

2.负载均衡

producer根据用户指定的算法,将消息发送到指定的partition 存在多个partiiton,每个partition有自己的replica,每个replica分布在不同的Broker节点上 多个partition需要选取出lead partition,lead partition负责读写,并由zookeeper负责fail over 通过zookeeper管理broker与consumer的动态加入与离开

什么是zero-copy

许多web应用都会向用户提供大量的静态内容,这意味着有很多data从硬盘读出之后,会原封不动的通过socket传输给用户。这种操作看起来可能不会怎么消耗CPU,但是实际上它是低效的:kernal把数据从disk读出来,然后把它传输给user级的application,然后application再次把同样的内容再传回给处于kernal级的socket。这种场景下,application实际上只是作为一种低效的中间介质,用来把disk file的data传给socket。 data每次穿过user-kernel boundary,都会被copy,这会消耗cpu,并且占用RAM的带宽。幸运的是,你可以用一种叫做Zero-Copy的技术来去掉这些无谓的copy。应用程序用zero copy来请求kernel直接把disk的data传输给socket,而不是通过应用程序传输。Zero copy大大提高了应用程序的性能,并且减少了kernel和user模式的上下文切换。 Java的libaries在linux和unix中支持zero copy,一个关键的api是java.nio.channel.FileChannel的transferTo()方法。我们可以用transferTo()来把bytes直接从调用它的channel传输到另一个writable byte channel,中间不会使data经过应用程序。


如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

¥ 打赏博主

留言