大数据干货系列（十）--Kafka总结

本文共计2022字，预计阅读时长十分钟

---

Kafka总结

 

一、本质

一种分布式的、基于发布/订阅的消息系统

 

二、Kafka的特点

– 消息持久化：通过O(1)的磁盘数据结构提供数据的持久化

– 高吞吐量：每秒百万级的消息读写

– 分布式：扩展能力强

– 多客户端支持：java、php、python、c++ ……

– 实时性：生产者生产的message立即被消费者可见

 

三、Kafka架构

3.1 Broker（中介）

• 每一台机器叫一个Broker(中介)，Kafka内部是分布式的、一个Kafka集群通常包括多个Broker

• 负载均衡：将Topic分成多个分区，每个Broker存储一个或多个Partition

• 连接broker的多个Producer和Consumer同时生产和消费消息

3.2 Topic（类别）

• Topic使用分区的日志，每个分区都是有顺序且不变的消息序列，且对应一个文件夹和一个并行单元。

• commit的log可以不断追加。消息在每个分区中都分配了一个叫offset的id序列来唯一识别分区中的消息。

• 无论发布的消息是否被消费，Kafka都会持久化一定时间（可配置）。

• 每个消费者会都持久化这个offset在日志中。 offset的位置可由消费者控制，它可以按任意顺序来消费消息。比如复位到老的offset来重新处理。

3.3 Message（消息）

message（消息）是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。如果consumer订阅了这个主题，那么新发布的消息就会广播给这些consumer，为了数据流的高效性，message需要经过格式化处理转为二进制，格式如下：

– message length : 4 bytes (value: 1+4+n)

– "magic" value : 1 byte

– crc : 4 bytes

– payload : n bytes

 

3.4 Producer（消息生产者）

生产者可以发布数据到它指定的topic中，并可以指定在topic里哪些消息分配到哪些分区（比如简单的轮流分发各个分区或通过指定分区语义分配key到对应分区）

异步发送：生产者直接把消息发送给对应分区的broker，而不需要任何路由层。

同步发送：批处理发送，当message积累到一定数量或等待一定时间后进行发送。

 

3.5 Consumer（消息消费者）

• 重点介绍一种更抽象的消费方式：消费组（consumer group）

• 该方式包含了传统的queue和发布订阅方式

– 首先消费者标记自己一个消费组名。消息将投递到每个消费组中的某一个消费者实例上。

– 如果所有的消费者实例都有相同的消费组，这样就像传统的queue方式。

– 如果所有的消费者实例都有不同的消费组，这样就像传统的发布订阅方式。

– 消费组就好比是个逻辑的订阅者，每个订阅者由许多消费者实例构成(用于扩展或容错)。

• 相对于传统的消息系统，Kafka拥有更强壮的顺序保证。

• 由于topic采用了分区，可在多Consumer进程操作时保证顺序性和负载均衡。

 

四、Kafka Core

4.1持久化

• Kafka存储布局简单：Topic的每个Partition对应一个逻辑日志（一个日志为相同大小的一组分段文件）

• 每次生产者发布消息到一个分区，代理就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者经过一定的时间后，段文件真正flush磁盘中。写入完成后，消息公开给消费者。

• 消息通过日志中的逻辑偏移量（offset）来公开。

 

4.2传输效率高

• 生产者一次提交时发出一批消息，消费者也是一次请求获取一批数据，从而减少网络请求数量。

• Kafka层采用无缓存设计，而是依赖于底层的文件系统页缓存。这有助于避免双重缓存，即消息只缓存了一份在页缓存中，故即使kafka重启，页缓存还是可用的。

• zero-copy：kafka为了减少字节拷贝，采用了大多数系统都会提供的sendfile系统调用。

 

4.3 Broker无状态

• Kafka代理是无状态的：意味着消费者必须维护已消费的状态信息（通过offset定位）。

– 当消息在代理中超过一定时间后，将会被自动删除。

– 消费者可以故意倒回到老的offset再次消费数据。

 

4.4 交付保证

• Kafka默认采用at least once的消息投递策略。即在消费者端的处理顺序是获得

消息->处理消息->保存位置。

• 三种保证策略：

– At most once 消息可能会丢，但绝不会重复传输

– At least one 消息绝不会丢，但可能会重复传输

– Exactly once 每条消息肯定会被传输一次且仅传输一次

 

4.5 副本管理

• kafka将日志复制到指定多个服务器上。

• 复本的单元是partition。在正常情况下，每个partition有一个leader和0到多个follower。

• leader处理对应分区上所有的读写请求。分区可以多于broker数，leader也是分布式的。

• follower的日志和leader的日志是相同的， follower被动的复制leader。如果leader挂了，其中一个follower会自动变成新的leader。

• kafka采用ISR(In-Sync Replicas同步副本)来管理各副本

– kafka动态的维护了一组in-sync(ISR)的复本，表示已追上了leader,只有处于该状态的成员组才是能被选择为leader。这些ISR组会在发生变化时被持久化到zookeeper中。

– 如果follower挂掉或卡住或落得很远，便会进入到Out-of-Sync Replicas列表中，leader则会移除Out-of-Sync Replicas列表中的副本。至于落了多远才叫远由replica.lag.max.messages配置，而表示复本“卡住”由replica.lag.time.max.ms配置。

 

4.6 分布式协调

• 由于kafka中一个topic中的不同分区只能被消费组中的一个消费者消费，就避免了多个消费者消费相同的分区时会导致额外的开销（如要协调哪个消费者消费哪个消息，还有锁及状态的开销）。

• kafka中消费进程只需要在代理和同组消费者有变化时时进行一次协调（这种协调不是经常性的，故可以忽略开销）。

 

4.7 Zookeeper的作用

1) 探测broker和consumer的添加或移除

Broker Node Registry

– broker启动时在/brokers/ids下创建一个znode，把broker id写进去。

– 因为broker把自己注册到zookeeper中实用的是临时节点，所以这个注册是动态的，如果broker宕机或者没有响应该节点就会被删除。

Broker Topic Registry

– 每个broker把自己存储和维护的partion信息注册到该路径下。

Consumers and Consumer Groups

– consumers也把它们自己注册到zookeeper上，用以保持消费负载平衡和offset记录。

– group id相同的多个consumer构成一个消费组，共同消费一个topic，同一个组的consumer会尽量均匀的消费，其中的一个consumer只会消费一个partition的数据。

Consumer Id Registry

– 每个consumer在/consumers/[group_id]/ids下创建一个临时的唯一的consumer_id，用来

描述当前该group下有哪些consumer是alive的，如果消费进程挂掉对应的consumer_id就会从该节点删除。

 

2) 维护消费关系和追踪消费者在分区消费的消息的offset。

Consumer Offset Tracking

– consumer把每个partition的消费offset记录保存在该节点下。

Partition Owner registry

– 该节点维护着partion与consumer之间的对应关系。 

重要通知：

公众号现在已经把目前所有的干货都整理出来了，

在外面点击菜单即可看到全部内容。

---

 

关注这个公众号，每天会有三道大数据面试题准时推送给你哦~