kafka 的架构

讲一下kafka 的架构

一个典型的Kafka集群中包含若干Producer，若干broker，若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

👉Producer：消息生产者，即将消息发布到指定的Topic中，同时Producer也能决定此消息所属的Partition：比如基于Round-Robin（轮询）方式或者是Hash（哈希）方式等一些算法。

👉Consumer：消息消费者，每个Consumer属于一个Consumer Group；反过来，每个Consumer Group中可以包含多个 Consumer。如果所有的Consumer都具有相同的Consumer Group，那么消息将会在Consumer之间进行负载均衡。也就是说一个Partiotn中的消息指挥被相同Consumer Group中的某个Consumer消费，每个Consumer Group消息消费是互相独立的。如果所有的Consumer都具有不同的Consumer Group，则消息将会被广播给所有的Consumer。

👉Broker代理人：一台Kafka服务器就是一个Broker，一个集群由多个Broker组成，一个Broker可以容纳对各Topic，Broker和Broker 之间每个Matser和Standby的概念，它们之间的地位基本是平等的。

👉Topic：每条发送到Kafka集群的消息都属于某个主题，这个主题就称为Topic。物理上不同Topic的消息分开存储，逻辑上 一个Topic的消息虽然保存在一个或者多个Broker上，但是用户只需指定消息的主题Topic即可生产或者消费数据而不需要去关心数据存放在何处。

👉Partition：为了实现可扩展性，一个非常大的Topic可以被分为多个Partition，从而分布到多台Broker上。Partition中的每条 消息都会被分配一个自增Id（Offset）。Kafka只保证按一个Partition中的顺序将消息发送给消费者，但是不保证单个Topic中的多个Partition之间的顺序。

👉Offset：消息在Topic的Partiton中的位置，同一个Partition中的消息随着消息的写入，其对应的Offset也自增。

👉Replica：副本。Topic的Partition含有N个Replica，N为副本因子。其中一个Replica为Leader，其他的都为Follower，Leader处理Partition的所有读写请求，于此同时，Follower会定期地去同步Leader上的数据。

👉Message：消息，是通信的基本单位。每个Producer可以向一个Topic（主题）发布一些消息。在老版本中，每一条消息称为Message，在由java重新实现的客户端中，每一条消息称为Record。

👉LogSegment：日志段，一个日志又被划分为多个日志段，日志段是Kafka日志对象分片的最小单元。一个日志段对应磁盘上一个具体的日志文件和两个索引文件。日志文件以“.log”为后缀，主要保存消息实际数据。两个索引文件分别以“.index”和“.timeindex”为后缀，分别表示消息偏移量索引文件和消息时间戳索引文件。

👉ISR：保存同步的副本列表。Kafka在zookeeper中动态维护了一个ISR（In-sync-Replica）即保存同步的副本列表，保存的是与Leader副本保持消息同步的所有副本对应的代理节点id。如果一个Follower副本宕机或者落后太多，则该Follower副本节点将从ISR列表中移除。

👉Zookeeper：存放Kafka集群相关元数据的组件。在zookeeper集群中会保存Topic的状态信息，例如分区的个数、分区的 组成、分区的分布情况等；保存Broker的状态信息；保存消费者消费信息等。通过这些信息，Kafka很好地将消息生产、消息存储、消息消费的过程集合起来。