快速了解 Kafka 基础架构

今天来聊下大数据场景下比较流行的消息队列组件kafka。本篇文章将主要从理论角度来介绍。

kafka是一款开源、追求高吞吐、实时性，可持久化的流式消息队列，可同时处理在线（消息）与离线应用(业务数据和日志)。在现在火热的大数据时代，获得了普遍的应用。

总体架构

kafka的消息以Topic进行归类，支持分布式distribution、可分区partition和可复制replicated的特性。下面为本人梳理的一张Kafka系统架构图。

Kafka的架构相较于其余消息系统而言，比较简单。其总体流程简述以下

Producer与指定Topic各分区Partition的Leader链接，从而将消息push到Broker中。
Broker可理解消息系统的中间代理，将消息写入磁盘实现持久化，并可对消息复制备份。
Consumer采用pull的方式主动获取broker中指定Topic的消息，并进行处理。
Zookeeper负责Kafka服务相关metadata的存储，如broker，topic和consumer等信息的存储。

注：zookeeper是一个分布式协调服务，分布式应用可基于它实现同步服务，配置维护和命名服务等。此篇文章不作介绍，之后有时间再作总结！

下面对涉及的各个组件做详细介绍。

主题Topic

首先，Kafka中的消息以Topic分类管理。在Kafka中，一个topic可被多个Consumer订阅。经过集群管理，每一个Topic可由多个Partition组成。以下图

从上图能够看出，Topic中数据是顺序不可变序列，采用log追加方式写入，于是kafka中无因随机写入致使性能低下的问题。

Topic的数据可存储在多个partition中，便可存放在不一样的服务器上。这可以使Topic大小不限于一台server容量。同时，消息存在多个partition上，能够实现Topic上消息的并发访问。

Kafka中数据不会因被consumer消费后而丢失，而是经过配置指定消息保存时长。Topic中每一个partition中的消息都有一个惟一的标识，也称为offset。因数据不会因消费而丢失，因此只要consumer指定offset，一个消息可被不一样的consumer屡次消费。

基于此，消息获取便可采用顺序访问，咱们也能够指定任意offset随机访问，且不会对其余consumer产生影响。

分布式Distribution

Kafka的集群分布式主要涉及两个内容：Partition分区与Replication备份。

Partition实现将Topic中的各个消息存储到不一样的分区中，从而分布在不一样的Kafka节点之上，使Topic的数据大小不限于一台Server。

Replication主要用于容错，对一个Partition复制多份，存储在不一样kafka节点上。这可防止因某一分区数据丢失而致使错误。

虽然Relication复制Partition多份，但其中只有一个为Leader角色，其他Partition角色皆为Follower。Producer发布消息都是由Leader负责写入，并同步到其余的Follower分区中。若是Leader失效，则某个Follower会自动替换，成为新的Leader分区。此时，Follower可能落后于Leader，因此从全部Follower中选择一个”up-to-date”的分区。

关于性能方面，考虑Leader不但承载了客户的链接与消息写入，还负责将消息同步至不一样的Follower分区上，性能开销较大。所以，不一样Partition的Leader分布在不一样的kafka节点上，从而防止某个节点压力过载。

为了更好了解Partition与Replication关系。举个例子，假设现有一个Topic名为spark_topic，其Partition分区数量为3，Replication备份因子为2。则效果以下图

spark_topic存在spark_topic-1，spark_topic-2，spark_topic-3共三个分区。而每一个分区均有两处备份，如spark_topic-1，其同时存在于kafka节点broker0与broker1上，其中broker01上的分区角色为Leader。

消费者Consumer

Consumer负责消费消息。Kafka中Consumer消费消息采用fetch方式主动拉取，这种方式的好处是Consumer客户端能根据本身的处理消息能力决定消息获取的速度与批量获取的数量，从而防止系统过载。

Kafka的消息并不会由于消息被Consumer消费而丢失，于是其提供一个惟一的标识offset实现消息的顺序获取，而offset须要consumer自行维护，非kafka节点服务管理。这不一样于传统的消息系统。在Kafka集群中，消费者的信息与offset在zookeeper也有保存维护，Consumer会间歇性向zookeeper同步offset。

Kafka的Consumer提供分组功能，每一个Consumer都属于一个分组。那分组的做用是什么呢？

相似queue模式，一个Consumer分组的多个Consumer订阅同一个Topic，一条消息只分发给其中一个Consumer，实现负载均衡效果。

发布订阅模式，而不一样组的多个Consumer订阅同一个Topic，一条消息会广播给在不一样分组的全部Consumer。

请注意，在Kafka中，同一Consumer分组中，一个Consumer只能订阅一个Topic中的Partition，于是在一个Consumer分组中，同时订阅同一个Topic的Consumer的个数不能超过Partition分区数。可参看上图所示。

一样，为减小网络IO开销，Consumer可采用batch fetch方式实现一次批量获取多条消息。

应用场景

下面是一些官网介绍的Kafka应用场景，包括消息系统、网站行为跟踪、应用监控、日志收集等等。

消息系统

Kafka能够做为传统消息系统的替代。相比传统消息，Kafka有更高的吞吐量、拥有内置的分区Partition、复制备份高容错能力。

传统消息系统对高吞吐量没有太高要求，但kafka的低延迟特性和强大的备份容错能力是传统消息所必须的。

网站行为追踪

Kafka可用于用户行为追踪，经过将用户行为数据发送给Kafka。以此为基础，实现用户行为在线与离线分析，可用于网站实时监控与异常行为拦截等。

日志收集

Kafka能够做为日志收集解决方案。日志收集一般是将不一样服务器的日志文件收集到一个中心区域，Kafka实现了对日志文件数据进行抽象，统一了处理接口。Kafka低延迟，支持不一样的日志数据源，分布式消费易于扩展，可同时将数据提供给hdfs、storm、监控软件等等。

应用监控

Kafka可用于监控运行中的应用系统。如收集分布式应用的数据进行聚合计算，进行分析检测异常状况。

我的感受，本质和网站行为分析异常监控有殊途同归之处，只不过所监控的数据对象不一样罢了。

结束

利用两周末学习总结了大数据中经常使用的消息队列服务-Kafka。本篇主要从架构角度介绍。我的感受，介绍系统架构比操做实战更加困难，文章若有错误，请帮忙请指正。