Kafka入门与核心机制-CSDN博客

本文链接：https://blog.csdn.net/sinat_33455447/article/details/107434486

上一篇文章提到在不依赖kafka的情况下，如何直接使用python实现生产消费模型，但是也只适用于数据量不是特别大而且对于数据处理的实时性没有那么高的场景，要真正实现大数据的生产消费，那咱不得不聊聊kafka了。由于kafka可以聊的点不少，所以开个新坑写一个系列吧，本篇就先大致介绍一下kafka的基本情况。

一个学前小故事

周末睡觉前无聊的刷着手机，某宝网APP突然蹦出来一条消息“为了回馈老客户，猫条买一送一，活动仅限今天！”。买一送一还有这种好事，那我可不能错过！忍不住立马点了去。于是选了两个最香款，下单、支付一气呵成！肥猫在我脚边绕来绕去，大概是感应到马上有猫条吃了，竟然兴奋的跳上床，在我肚子上快乐的舞蹈……
在这里插入图片描述
第二天正常上着班，突然接到快递小哥的电话：
小哥：“你是xx吗？你的猫条到了，我现在在你楼下，你来拿一下吧！”。
我：“这……我在上班呢，可以晚上送过来吗？“。
小哥：“晚上可不行哦，晚上我也下班了呢！”。
于是两个人僵持了很久……

最后小哥说，要不我帮你放到楼下小芳便利店吧，你晚上下班了过来拿，尴尬的局面这才得以缓解！

回到正题，如果没有小芳便利店，那快递小哥和我的交互图就应该如下：
在这里插入图片描述
会出现什么情况呢？

我请假回去拿（老板is watching you）。
小哥一直在楼下等（小哥应该不是菩萨）。
周末再送（肥猫要疯）。
我不要了（no way）！

但有了小芳便利店，我和小哥的交互就有了一个中间件：
在这里插入图片描述
中间件的好处如下：

解耦，减少模块间的互相干扰，让各个模块的修改变化尽可能小的影响其它模块。如果直接送到收货人手里的话，需要先和收货人打电话沟通什么时侯在家，需要确认收货人的状态，有了中间件后，快递小哥只需要将同一个小区的快递放在同一个便利店，然后通知收货人来取货就可以了，不需要依赖收货人的状态，这时候快递小哥和收货人就实现了解耦。
异步，简单来说就是不用等待结果。快递小哥在放完快递，发了短信通知收件人之后，并不需要等待收件人取到快递，就可以送下一份快递了！
削峰，复杂上来说就是更多地延缓用户请求，以及层层过滤用户的访问需求，遵从“最后落地到数据库的请求数要尽量少”的原则。

消息队列的两种模式

通过上面的例子我们引出了消息中间件，并且介绍了消息队列出现后的好处，这里就需要介绍消息队列通信的两种模式了。

点对点模式

点对点模式通常是基于拉取或者轮询的消息传送模型，这个模型的特点是发送到队列的消息被一个且只有一个消费者进行处理。生产者将消息放入消息队列后，由消费者主动的去拉取消息进行消费。点对点模型的的优点是消费者拉取消息的频率可以由自己控制。但是消息队列是否有消息需要消费，在消费者端无法感知，所以在消费者端需要额外的线程去监控。
在这里插入图片描述

发布订阅模式

发布订阅模式是一个基于消息送的消息传送模型，该模型可以有多种不同的订阅者。生产者将消息放入消息队列后，队列会将消息推送给订阅过该类消息的消费者（类似微信公众号）。由于是消费者被动接收推送，所以无需感知消息队列是否有待消费的消息！
在这里插入图片描述

kafka

KAFKA是一款高吞吐的分布式发布与订阅的消息系统，它可以应用在活动跟踪，传递消息，度量指标和日志记录，流处理等场景中。具有高性能、持久化、多副本备份、横向扩展能力。

架构一览

在这里插入图片描述

Producer：Producer即生产者，消息的产生者，是消息的入口。
kafka cluster：
Broker：Broker是kafka实例，每个服务器上有一个或多个kafka的实例，可认为每个broker对应一台服务器。每个kafka集群内的broker都有一个不重复的编号，如图中的broker-0、broker-1等……
Topic：消息的主题，可以理解为消息的分类，kafka的数据就保存在topic。在每个broker上都可以创建多个topic。
Partition：Topic的分区，每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的，partition的表现形式就是一个一个的文件夹！
Replication:每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
Message：每一条发送的消息主体。
Consumer：消费者，即消息的消费方，是消息的出口。
Consumer Group：我们可以将多个消费组组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量！
Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。

前面说过了每个topic都可以分为一个或多个partition，如果觉得topic比较抽象，那partition就是比较具体的东西了！Partition在服务器上的表现形式就是一个一个的文件夹，每个partition的文件夹下面会有多组segment文件，每组segment文件又包含.index文件、.log文件、.timeindex文件（早期版本中没有）三个文件， log文件就实际是存储message的地方，而index和timeindex文件为索引文件，用于检索消息。

Kafka规定了一个分区内的.log文件最大为1G，做这个限制目的是为了方便把.log加载到内存去操作
在这里插入图片描述

生产者是如何发送消息的

①、首先要构造一个 ProducerRecord 对象，该对象可以声明主题Topic、分区Partition、键 Key以及值 Value，主题和值是必须要声明的，分区和键可以不用指定。
②、调用send() 方法进行消息发送。
③、因为消息要到网络上进行传输，所以必须进行序列化，序列化器的作用就是把消息的 key 和 value对象序列化成字节数组。
④、接下来数据传到分区器，如果 ProducerRecord 对象指定了分区，那么分区器将不再做任何事，直接把指定的分区返回；如果没有，那么分区器会根据 Key 来选择一个分区；如果既没指定分区，又没有设置Key，则会轮询选出一个分区。选择好分区之后，生产者就知道该往哪个主题和分区发送记录了。
⑤、接着这条记录会被添加到一个记录批次里面，这个批次里所有的消息会被发送到相同的主题和分区。会有一个独立的线程来把这些记录批次发送到相应的 Broker 上。
⑥、Broker成功接收到消息，表示发送成功，返回消息的元数据（包括主题和分区信息以及记录在分区里的偏移量）。发送失败，可以选择重试或者直接抛出异常
在这里插入图片描述

下面举比较具体的例子来讲解上图④过程的三种分区策略：

轮询策略

也称 Round-robin 策略，即顺序分配。比如一个主题下有 3 个分区，那么第一条消息被发送到分区 0，第二条被发送到分区 1，第三条被发送到分区 2，以此类推。当生产第 4 条消息时又会重新开始，即将其分配到分区 0，如下图所示：
在这里插入图片描述
轮询策略有非常优秀的负载均衡表现，它总是能保证消息最大限度地被平均分配到所有分区上，故默认情况下它是最合理的分区策略，也是我们最常用的分区策略之一。

按消息键保序策略

也称 Key-ordering 策略。Kafka 允许为每条消息定义消息键，简称为 Key。这个 Key 的作用非常大，它可以是一个有着明确业务含义的字符串，比如客户代码、部门编号或是业务 ID 等；也可以用来表征消息元数据。特别是在 Kafka 不支持时间戳的年代，在一些场景中，工程师们都是直接将消息创建时间封装进 Key 里面的。一旦消息被定义了 Key，那么你就可以保证同一个 Key 的所有消息都进入到相同的分区里面，由于每个分区下的消息处理都是有顺序的，故这个策略被称为按消息键保序策略，如下图所示：
在这里插入图片描述

随机策略

也称 Randomness 策略。所谓随机就是我们随意地将消息放置到任意一个分区上，如下图所示：
在这里插入图片描述
先计算出该主题总的分区数，然后随机地返回一个小于它的正整数。本质上看随机策略也是力求将数据均匀地打散到各个分区，但从实际表现来看，它要逊于轮询策略，所以如果追求数据的均匀分布，还是使用轮询策略比较好。事实上，随机策略是老版本生产者使用的分区策略，在新版本中已经改为轮询了。

消费者是如何接受消息的

根据offset查找消息

假如现在需要查找一个offset为368801的message是什么样的过程呢？
1、先找到offset的368801message所在的segment文件（利用二分法查找），这里找到的就是在第二个segment文件。
2、打开找到的segment中的.index文件（也就是368796.index文件，该文件起始偏移量为368796+1，我们要查找的offset为368801的message在该index内的偏移量为368796+5=368801，所以这里要查找的相对offset为5）。由于该文件采用的是稀疏索引的方式存储着相对offset及对应message物理偏移量的关系，所以直接找相对offset为5的索引找不到，这里同样利用二分法查找相对offset小于或者等于指定的相对offset的索引条目中最大的那个相对offset，所以找到的是相对offset为4的这个索引。
3、根据找到的相对offset为4的索引确定message存储的物理偏移位置为256。打开数据文件，从位置为256的那个地方开始顺序扫描直到找到offset为368801的那条Message。
在这里插入图片描述