kafka 架构设计简介(一)

一、概述

kafka是一个分布式的消息系统，由LinkedIn开发，后成为Apache的一部分。它以水平扩展和高吞吐率被广泛使用。

最近开始深入学习kafka，然后打算写一个kafka系列文章，这是第一篇。虽然目前网上关于kafka的文章有很多，很多都写的很详细，但是还是想自己整理一遍。一方面为了更好的巩固，另一方面也为了以后复习起来方便。

本篇对kafka的整个架构以及概念做一些简单的介绍。后面再对一些存储机制，以及读写原理，甚至对源码对一些解析。

二、kafka的架构

kafka的架构

Producer: 负责生产消息的组件。
Broker: 消息存储处理的组件。可以水平扩展，数量越多，吞吐量越高。
Customer: 消息的消费者。
Customer Group: 消费者群组。一个group中可以有多个customer，他们以协作的方式从一个topic的各个partition获取数据。
Zookeeper Cluster: zk集群，用于管理配置，进行leader选举。

三、Topic & Partition

topic可以理解为消息的主题，producer发送消息的时候需要指定消息的topic，customer消费消息的时候也要指定要消费的消息topic。

在kafka中，每个topic都有若干个partition，具体的数量可以通过配置num.partitions来指定。每个parttion都有若干个复制partition，用于partition leader失效后启用，从而达到数据高可用的目的。

当producer向kafka集群提交消息的时候，会将消息通过分区器发送到指定的partition中。customer消费的时候也会自动根据负载均衡消费指定的partition。另外，一个partition只能被一个customer Group中的一个customer消费。也就是说，如果一个customer Group中有5个customer，但是该topic的partition只有4个，那么会有一个customer是消费不到数据的。

producer生产数据示意图：

写流程

customer 消费数据示意图：

image.png

四、关于Customer Group和Customer

一般我们要消费kafka消息的时候，需要制定customer group id。kafka会记录这个group id，然后维护相关的offset(都记录在zk集群上面)。每个group id都会维护自己的offset，比如某个topic有5个partition，然后group id开始消费的时候就会有5个不同的offset分别对应5个parttion。

当有customer加入这个group id的时候，会被负载均衡去消费某几个partition。当然，kafka会保证所有的partition都有customer在消费。也就是如果某个customer group中只有一个customer，那么这个customer会消费该topic下所有的partiton。

也就是说，不同customer group之间的消费进度是相互独立的。如果我们要用kafka来做消息订阅发布的组件，那么只要开多个customer group就来消费消息就可以了。
如果要用kafka做消费队列的组件，那么可以设定多个customer同属于一个customer group。

我的CSDN博客地址:
https://blog.csdn.net/u013332124/article/details/80330561