首页  思维导图  详情

kafka架构原理

2019-12-18 09:59:14   0  举报





AI智能生成

kafka 架构设计及原理解析

kafka

kafka集群

作者其他创作

大纲/内容

优点

读写快

Cache Filesystem Cache PageCache缓存

顺序写由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快

Zero-copy 另拷贝技术减少拷贝次数

Batch of Messages 批量处理数据，合并小的请求，然后以流的方式进行交互，直顶网络上限

Pull 拉模式使用拉模式进行消息的获取消费，与消费端处理能力相符

缺点

概念

broker

消息中间件处理节点，一个Kafka节点就是一个Broker，一个或多个Broker可以组成一个kafka集群

partitions

物理上的概念，一个Topic可以分多个Partition，每个Partition内部是有序的

topic

主题，Kafka根据topic对消息进行归类，发布到Kafka集群的每条消息都需要指定一个Topic

group

每一个Consumer属于一个特定的ConsumerGroup，一条消息可以发送到多个不同的Consumer Group，但是一个Consumer Group中只能有一个Consumer能够消费该消息

是一个逻辑上的概念，是kafka实现单播和广播两种消息模型的手段。

同一个topic的数据，会广播不同的group，同一个group中的worker，只有一个worker能拿到这个数据

对于同一个topic，每个group都可以拿到同样的所有的数据，但是数据进入grup后只能被其中一个worker消费。

group内的woker可以使用多线程或者多线程来实现，也可以将进程分散在多台机器上，worker的数量不超过partition的数量，而且二者最好保持整数被关系，因为kafka在设计时假定了一个partition只能被一个worker消费（同一个group内）

思考

为什么设计一个goup内的消息只能一个workeri 消费

group和substribe那里的offset有什么关系

consumer

producer

消息生成方，存储消息在哪一个partition中，如果没有指定partition，则进行轮询发送。如果指定了partition key，则对Key值进行Hash，然后和partition个数进行取余操作，保证了同一个key值的会被路由到同一个分区，如果想队列强顺序一致性，可以让所有的消息都设置同一个key。

如何优化写入速度

增加线程

提供batch.size

增加更多的producer实列

增加partition 数

设置acks=-1时，如果延迟增大，可以增加num.replica.fetchers（follower同步数据的线程数）来调解

跨数据中心传输，增加socket缓冲区设置以及OS tcp缓冲区设置

ack配置

默认设置，数据发送到kafka后，进过leader成功接收消息的确认，就算是发送成功了。在这种情况下，如果leader down机，则会丢失数据

生产者将数据发送出去以后就不管了，不去等待任何返回。这种情况下数据传输效率最高，但是数据可靠性确是最低的

-1

producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成，可靠性最高。当ISR中所有Replica都想Leader发送ACK时，leader才commit，这时候producer才能认为一个请求中的消息都commit

Offset

Kafka为每一个topic维护了分布式的分区日志文件，每个partition在kafka的存储层面是一个Append Log。任何发布到此Partition的消息都会追加到Append Log的文件尾部，在每一个分区中每条消息都会按照时间顺序分配到一个单调递增的顺序编号，也就是我们的Offset。它是一个Long类型的数字。我们通过Offset可以确定一条消息在该Partition下的唯一消息。在Partition下面保证了有序性，但是在Topic下面没有有序性

消息模型

pull

push

OSR

ISR

副本同步队列

ISR是有leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个纬度，当前最新版本0.10.x中只支持replica.lag.time.max.ma这个纬度）任意一个超过阀值都会把follower剔除ISR，存入OSR(outof-Sync Replicas）列表，新进入的follower也会先存放在OSR中。AR=ISR+OSR

所有副本

unclean

unclean.leader.election.enable=true

非ISR集合的broker也可以参与选举，这样有可能会丢失数据，spark streaming在消费过程中拿到的end offset会突然变小，导致spark streaming会变小，导致spark streming job 挂掉。

可能发生数据丢失和数据不一致的情况，kafka的可靠性降低

unclean.leader.election.enable=false

Kafka的可用性就会降低

思考：具体业务场景中应该怎么用

message

格式

一个固定的header和一个变长的消息体body组成

header部分由一个字节的magic（文件格式）和四个字节的CRC32（用于判断body消息体是否正常）构成

当magic的值为1的时候，会在magic和crc32之间多一个字节的数据，attributes（保存一些相关属性，比如是否压缩、压缩格式等等）；如果magic的值为0，那么不存在attributes属性

body是由N个字节构成的一个消息体，包含了具体的key/value消息

topic

存储机构

数据同步

分布式读

分布式写

数据同步

kafka的复制机制不是完全同步复制，也不是单纯的异步复制，完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据。kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file（zero copy）机制，这样极大的提供复制性能，内部批量写磁盘，大幅度减少Follower于Leader的消息量差

zookeeper

整个kafka架构对应一个zookeeper集群，通过zk管理集群配置，选举Leader，以及Consumer Group发生变化时进行Rebalance

新版kafka考虑到zk本身的一些因素以及整个架构较大概率存在的单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，一减少了对zookeeper的依赖，但是broker依然依赖于zk，zookeeper在kafka中还是用来选举controller和检测broker是否存活

选举controller

检测broker是否存活

思考问题

zero copy 原理，为什么快

isr中如果的follower挂掉了，里面的数据怎么处理

leader crash，ISR为空怎么办

kafka在Broker端提供了一个配置参数 unclean.leader.election

true

可以从非ISR的队列中选择非同步的副本成为leader，由于不同步副本的消息比较滞后，当选择为leader时，可能会出现消息的不一致

false

会一直等待leader恢复，整个系统hold在那里

kafka的消息是否会丢失