Kafka学习笔记 - 01: 初步了解-CSDN博客

本文链接：https://blog.csdn.net/u011682283/article/details/86479583

Kafka 是 Linkedin 公司用于日志处理的分布式消息队列，同时支持离线和在线日志处理。kafka 对消息保存时根据Topic进行归类，发送消息者成为 Producer ,消息接受者成为 Consumer,此外 Kafka 集群有多个 Kafka 实例组成，每个实例(server)称为broker。无论是 Kafka 集群，还是 producer 和 consumer 都依赖于 zookeeper 来保证系统可用性，为集群保存一些 meta 信息

Kafka 维护消息类别的东西是 topic
我们称发布消息到 Kafka 主题的进程叫生产者 producer
我们称订阅主题、获取消息的进程叫消费者 consumer
Kafka 是由多个服务器组成的机器，每个服务器称作 broker

在较高的层次上看，生产者通过网络发送消息到 Kafka 集群，Kafka 集群将这些消息提供给消费者，如下图：

在 Kafka 中，客户机和服务器之间的通信是通过一个简单的、高性能的、与语言无关的 TCP 协议完成的。此协议经过版本控制，并与旧版本保持向后兼容性。我们为 Kafka 提供了一个 Java 客户机，但是客户机可以使用多种语言。

Topics and Logs

一个 Topic 可以认为是一类消息，每个 topic 将被分成多个 partition(区),每个 partition 在存储层面是append log 文件。任何发布到此 partition 的消息都会被直接追加到 log 文件的尾部，每条消息在文件中的位置称为 offset(偏移量)，offset 为一个 long 型数字，它是唯一标记一条消息。kafka 并没有提供其他额外的索引机制来存储 offset，因为在 Kafka 中几乎不允许对消息进行“随机读写”。

一个主题就是消息的类别或名称。对每个主题，Kafka 集群都管理着一个被分区的日志，如下：

每个分区就是一个提交日志：每个分区上保存着不断被追加的消息，这些消息是有序的且顺序不可改变；分区上的每个消息都被分配了一个序列号 offset，offset 唯一标识了分区上的消息。

在 Kafka 中，即使消息被消费,消息仍然不会被立即删除。日志文件将会根据 broker 中的配置要求,保留一定的时间之后删除;比如log 文件保留2 天,那么两天后,文件会被清除,无论其中的消息是否被消费。Kafka 通过这种简单的手段,来释放磁盘空间,以及减少消息消费之后对文件内容改动的磁盘IO 开支。

对于 consumer 而言,它需要保存消费消息的 offset,对于 offset 的保存和使用, 由 consumer 来控制; 当 consumer 正常消费消息时,offset 将会"线性"的向前驱动,即消息将依次顺序被消费。事实上 consumer 可以使用任意顺序消费消息,它只需要将 offset 重置为任意值。

partitions 的设计目的有多个。最根本原因是 Kafka 基于文件存储。通过分区,可以将日志内容分散到多个 server 上,来避免文件尺寸达到单机磁盘的上限,每个 partiton都会被当前 server(kafka实例)保存;可以将一个 topic 切分多任意多个 partitions 来保存消息。此外越多的 partitions 意味着可以容纳更多的 consumer,有效提升并发消费的能力。同样的，分区数必须在设计之初就设置好，重新指定分区数的开销是很大的。

对日志进行分区有几个目的：

支持水平扩容，一个 Topic 可以有多个 Partition，这使得可以保存比一个机器保存的多的多的数据。
并行查询，缓解单节点的压力

Distribution

一个 Topic 的多个 partitions,被分布在 Kafka 集群中的多个 server 上;每个 server(kafka 实例)负责 partitions 中消息的读写操作;此外Kafka 还可以配置 partitions 需要备份的个数(replicas),每个 partition 将会被备份到多台机器上,以提高可用性。

主从分区间的数据同步：

Kafka 每个 topic 的 partition 有N个副本，其中N是 topic 的复制因子。Kafka 通过多副本机制实现故障自动转移，当 Kafka 集群中一个 broker 失效情况下仍然保证服务可用。在 Kafka 中发生复制时确保 partition 的预写式日志有序地写到其他节点上。N个replicas 中。其中一个 replica 为 leader，其他都为 follower，leader 处理 partition 的所有读写请求，与此同时，follower会被动定期地去复制 leader 上的数据。

基于 replicated(冗余)方案,那么就意味着需要对多个备份进行调度;每个 partition 都有一个机器为"leader";零个或多个机器作为follower。leader 负责所有的读写操作,follower 执行 leader 的指令。如果 leader 失效,那么将会有其他 follower 来接管(成为新的leader);follower 只是单调的和 leader 跟进,同步消息即可。由此可见作为 leader 的server 承载了全部的请求压力,因此从集群的整体考虑,有多少个 partitions 就意味着有多少个"leader",Kafka 会将"leader"均衡的分散在每个实例上,来确保整体的性能稳定。

Producers

Producer 将消息发布到指定的 Topic 中,同时 Producer 也能决定将此消息归属于哪个 partition;这可以通过简单的循环的方式来实现，或者使用一些分区方法（比如根据消息的 key 来分区）

Consumers

消费者都属于一个消费组;反过来说,每个消费组中可以有多个消费者。发送到 Topic 的消息,只会被订阅此 Topic 的每个消费组中的一个消费组消费。如果所有的消费者都具有相同的消费组,这种情况和 queue 模式很像;消息将会在 consumers 之间负载均衡。如果所有的 consumer 都具有不同的 group,那这就是"发布-订阅"，消息将会广播给所有的消费者。

在 Kafka 中,一个 partition 中的消息只会被 group 中的一个 consumer 消费;每个 group 中 consumer 消息消费互相独立;我们可以认为一个 group 是一个"订阅"者,一个 Topic 中的每个 partions,只会被一个"订阅者"中的一个 consumer 消费,不过一个 consumer 可以消费多个 partitions 中的消息。Kafka 只能保证一个 partition 中的消息被某个 consumer 消费时,消息是顺序的。事实上,从Topic 角度来说,消息仍不是有序的。Kafka 的设计原理决定,对于一个 topic,同一个 group 中不能有多于 partitions 个数的consumer 同时消费,否则将意味着某些 consumer 将无法得到消息。