0/Предисловие

kafka cluster > broker > topic > partition > segment > 
.index文件、.log文件、.timeindex文件 > message

1/Зачем вам нужна очередь сообщений (например, промежуточное программное обеспечение сообщений)

周末无聊刷着手机，某宝网APP突然蹦出来一条消息“为了回馈老客户，女朋友买一送一，活动仅限今天！”。
买一送一还有这种好事，那我可不能错过！忍不住立马点了去。于是选了两个最新款，下单、支付一气呵成！
满足的躺在床上，想着马上有女朋友了，竟然幸福的失眠了……
第二天正常上着班，突然接到快递小哥的电话：
     小哥：“你是xx吗？你的女朋友到了，我现在在你楼下，你来拿一下吧！”。
     我：“这……我在上班呢，可以晚上送过来吗？“。
     小哥：“晚上可不行哦，晚上我也下班了呢！”。
于是两个人僵持了很久……
最后小哥说，要不我帮你放到楼下小芳便利店吧，你晚上下班了过来拿，尴尬的局面这才得以缓解！
回到正题，如果没有小芳便利店，那快递小哥和我的交互模式就应该如下图所示：

如果是上图这种交互模式，会发生什么呢？
      1、为了这个女朋友，我请假回去拿（老板不批）。
      2、小哥一直在你楼下等（小哥还有其他的快递要送）。
      3、周末再送（显然等不及）。
      4、这个女朋友我不要了（绝对不可能！）
 
小芳便利店出现后，交互模式就应如下图所示：

在上面例子中，“快递小哥”和“买女朋友的我”就是需要交互的两个系统，
小芳便利店就是我们本文要讲的-“消息中间件”。

总结下来小芳便利店（消息中间件）出现后有如下好处：
<1>解耦
   先普及一下解耦：本来2个物体之间存在某种联系或者依赖，解耦就是让这2个物体分离开，消除联系和依赖
   
   快递小哥有很多快递要送，每次都要先电话一一确认收货人是否有空，哪个时间段有空，然后再确定送货方案
   这样完全依赖收货人了！如果快递一多，快递小哥估计的忙疯了……
   如果有了便利店，快递小哥只需要将同一个小区的快递放在同一个便利店，然后通知收货人来取货就可以了
   这时候快递小哥和收货人就实现了解耦！

<2>异步

После того, как мне позвонит брат-курьер, ему нужно все время ждать внизу с вами, пока я не заберу курьера, он может отправить его другим. После того, как брат-курьер помещает курьера в круглосуточный магазин Xiaofang, он может заняться другой работой, и ему не нужно ждать вашего прибытия, и он находится в состоянии ожидания. Повысить эффективность работы.

<3>缓冲和削峰

Предположим, я купил самые разные товары в разных магазинах на Double Eleven, и так получилось, что экспресс-доставка этих магазинов была разной, например Zhongtong, Yuantong, Shentong, разные ссылки и т.д...

<4>健壮性
   消息队列(消息中间件)可以堆积请求，所以消费端即使短时间内死掉，也不会影响主要业务的正常运行。

<5>冗余
   采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的消费者消费，供多个毫无关联的业务使用。
   
 更巧的是他们都同时到货了！中通的小哥打来电话叫我去北门取快递、圆通小哥叫我去南门、申通小哥叫我去东门。我一时手忙脚乱……

Мы видим, что в сценариях, где система должна взаимодействовать, использование промежуточного программного обеспечения очереди сообщений действительно полезно.Основываясь на этой идее, существует более профессиональное «промежуточное программное обеспечение», чем круглосуточный магазин Xiaofang, например, Fengchao и Cainiao Station.

Доступ к данным и распределение событий

Доступ к данным

假设有一个用户行为采集系统，负责从App端采集用户点击行为数据。
通常会将数据上报和数据处理分离开，即App端通过REST API上报数据，后端拿到数据后放入队列中就立刻返回，而数据处理则另外使用Worker从队列中取出数据来做，如下图所示。

这样做的好处有：
   第一，功能分离，上报的API接口不关心数据处理功能，只负责接入数据；
   第二，数据缓冲，数据上报的速率是不可控的，取决于用户使用频率，采用该模式可以一定程度地缓冲数据；
   第三，易于扩展，在数据量大时，通过增加数据处理Worker来扩展，提高处理速率。
这便是典型的生产消费者模式，数据上报为生产者，数据处理为消费者。

Рассылка событий

假设有一个电商系统，那么，用户“收藏”、“下单”、“付款”等行为都是非常重要的事件，通常后端服务在完成相应的功能处理外，还需要在这些事件点上做很多其他处理动作，比如发送短信通知、记录用户积分等等。我们可以将这些额外的处理动作放到每个模块中，但这并不是优雅的实现，不利于功能解耦和代码维护。 

   Нам нужна система распределения событий, которая публикует соответствующие события в каждом функциональном модуле и обрабатывает их заинтересованными обработчиками. Здесь задействованы две роли: A заинтересован в B, A — обработчик, а B — событие.Обработчик события завершает привязку между ними и подписывается на событие из центра сообщений. Сервисный модуль — это серверная служба бизнес-логики, которая публикует события в разных точках событий, а события распределяются по обработчикам, соответствующим обработчикам событий, через центр сообщений. Весь процесс показан на рисунке ниже. Вот типичная модель подписки для публикации.

2/2 режима связи очереди сообщений (промежуточное ПО сообщений)

Режим «точка-точка» (режим производитель-потребитель)

指的是由生产者将消息源源不断推送到消息队列（消息中间件），由不同的消费者从消息中心取出数据做自己的处理，在同一类别下，所有消费者拿到的都是同样的数据。

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

Режим публикации и подписки

  发布发布模式，本质上也是一种生产消费者模式。
  不同的是，由订阅者首先向消息队列（消息中间件）指定自己对哪些数据感兴趣，发布者推送的数据经过消息中心后，每个订阅者拿到的仅仅是自己感兴趣的一组数据

如上图所示，发布订阅模式是一个基于消息推送的消息传送模型，该模型可以有多种不同的订阅者。
生产者将消息放入消息队列后，队列会将消息推送给订阅过该类消息的消费者(类似于你关注了某个微信公众号，如果该微信公众号有新的文章，则会主动推送给你)。
由于是消费者被动接收推送(push)，所以无需感知消息队列是否有待消费的消息！
但是consumer1、consumer2、consumer3由于机器性能不一样，所以处理消息的能力也会不一样，但消息队列却无法感知消费者消费的速度！
所以推送的速度成了发布订阅模模式的一个问题！假设三个消费者处理速度分别是8M/s、5M/s、2M/s，如果队列推送的速度为5M/s，则consumer3无法承受！如果队列推送的速度为2M/s，则consumer1、consumer2会出现资源的极大浪费！

3/кластер Кафка

上面简单的介绍了为什么需要消息队列(消息中间件)以及消息队列通信的两种模式，
接下来就到了我们本文的主角—— kafka cluster 闪亮登场的时候了！

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理网站中用户的所有动作流数据，具有高性能、持久化、多副本备份、横向扩展能力……… 
一些基本的介绍这里就不展开了，网上有太多关于这些的介绍了，读者可以自行百度一下！

Инфраструктура и терминология

话不多说，先看图，通过这张图我们来捋一捋相关的概念及之间的关系：

如果看到这张图你很懵逼，木有关系！我们先来分析相关概念术语:
1）Producer：Producer即生产者，消息的产生者，是消息的入口。
2）kafka cluster：
    Broker：Broker是kafka实例，每个服务器上有一个或多个kafka的实例，
            我们姑且认为每个broker对应一台服务器。
            每个kafka集群内的broker都有一个不重复的编号，
            如图中的broker-0、broker-1等……
           
    Topic：消息的主题，可以理解为消息的分类，这是逻辑上的划分，用来区分/隔离不同类别的消息。
           kafka的数据就保存在topic。
           在每个broker上都可以创建多个topic。
         
    Partition：Topic的分区，是kafka下数据存储的基本单元，这是物理划分。
               每个topic可以有多个分区，这些分区可以在同一台服务器上，也可以在多台服务器上。
               分区的作用是做增加负载能力，提高kafka的吞吐量。
               同一个topic在不同的分区的数据是不重复的，
               partition的表现形式就是一个一个的文件夹！
               如上图所示，topic有4个partition,分散在2台机器上。
    
    Replication:每一个分区都有多个副本，副本的作用是做备胎。
                当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。
                在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，
                follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
    
    Message：每一条发送的消息主体。

3）Consumer：消费者，即消息的消费方，是消息的出口，及拉取消息队列中的数据，然后处理数据。
4）Consumer Group：我们可以将多个消费者组成一个消费者组，
                 在kafka的设计中同一个分区partition的数据只能被消费者组中的某一个消费者消费。
                 同一个消费者组的消费者可以消费同一个topic的不同分区的数据，
                 这也是为了提高kafka的吞吐量！
                 consumer group中的worker可以使用多线程或者多进程来实现，也可以把进程分散到多台机器上。
                 worker的数量通常不超过partition的数量，二者最好保持整数倍关系。

Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。

4/ Анализ рабочего процесса

上面介绍了kafka的基础架构及基本概念术语，不知道大家看完有没有对kafka有个大致印象，
如果对还比较懵也没关系！我们接下来再结合上面的结构图分析kafka的工作流程，
最后再回来整个梳理一遍我相信你会更有收获！

Отправить сообщение кластеру kafka cluser

我们看上面的架构图中，producer就是生产者，是数据的入口。
注意看图中的红色箭头，Producer在写入数据的时候永远的找leader，不会直接将数据写入follower！
那leader怎么找呢？写入的流程又是什么样的呢？我们看下图：

发送的流程就在图中已经说明了，就不单独在文字列出来了！
需要注意的一点是，消息写入leader后，follower是主动的去leader进行同步的(及从leader拉取pull)！
producer采用push模式将数据发布到broker，每条消息追加到分区partition中，顺序(追加)写入磁盘，
所以保证同一分区内的数据是有序的！写入示意图如下：

上面说到数据会写入到不同的分区，那kafka为什么要做分区呢？
相信大家应该也能猜到，分区的主要目的是：
1）方便扩展。因为一个topic可以有多个partition，所以我们可以通过扩展机器去应对日益增长的数据量
2）提高并发。以partition为读写单位，可以多个消费者同时消费数据，提高了消息的处理效率。

熟悉负载均衡的朋友应该知道，当我们向某个服务器发送请求的时候，
服务端可能会对请求做一个负载，将请求分发到不同的服务器，
那在kafka中，如果某个topic有多个partition，producer又怎么知道该将数据发往哪个partition呢
kafka中有几个原则：
1）在往partition中追加写入数据的时候，可以指定partition，如果有指定，则写入对应的partition。
2）如果没有指定partition，但是设置了数据的key，则会根据key的值hash出一个partition。
3）如果既没指定partition，又没有设置key，则会`轮询`选出一个partition。

保证消息不丢失是一个消息队列中间件的基本保证，
那producer在向kafka写入消息的时候，怎么保证消息不丢失呢？
其实上面的写入流程图中有描述出来，那就是通过ACK应答机制！
在生产者向消息队列写入消息数据的时候可以设置参数来确定是否确认kafka cluster是否接收到数据，
这个参数可设置的值为0、1、all。
1）0代表producer往kafka集群发送数据不需要等到kafka集群的返回，不确保消息发送成功。安全性最低但是效率最高。
2）1代表producer往kafka集群发送数据只要leader应答就可以发送下一条，只确保leader发送成功。
3）all代表producer往kafka集群发送数据需要所有的follower都完成从leader的数据同步才会发送下一条，确保leader发送成功和所有的副本都完成备份。安全性最高，但是效率最低。

最后要注意的是，如果往不存在的topic写数据，能不能写入成功呢？
kafka会自动创建该topic，分区和副本的数量根据默认配置都是1，及一个partition是leader，一个partition是follower

Сохранить данные

Producer将数据写入kafka集群后，集群就需要对数据进行保存了！
kafka将数据保存在磁盘(硬盘)，可能在我们的一般的认知里，写入磁盘是比较耗时的操作，不适合这种高并发的组件
Kafka初始会单独开辟一块磁盘空间，顺序写入数据（效率比随机写入高）。

Структура раздела:

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

如上图，这个partition有三组segment文件，每个log文件的大小是一样的，但是存储的message数量是不一定相等的（每条的message大小不一致）。
文件的命名是以该segment最小offset来命名的，如000.index存储offset为0~368795的消息，kafka就是利用分段+索引的方式来解决查找效率的问题。

Структура сообщения:

上面说到log文件就实际是存储message的地方，我们在producer往kafka写入的也是一条一条的message，那存储在.log文件中的message是什么样子的呢？
消息主要包含消息体、消息大小、offset、压缩类型……等等！我们重点需要知道的是下面三个：
1）offset：offset是一个占8byte的有序id号，它可以唯一确定每条消息在parition内的位置！
2）消息大小：消息大小占用4byte，用于描述消息的大小。
3）消息体：消息体存放的是实际的消息数据（被压缩过），占用的空间根据具体的消息而不一样。
   

Стратегия хранения:

无论消息是否被消费，kafka都会保存所有的消息。那对于旧数据有什么删除策略呢？
1）基于时间，默认配置是168小时（7天）。
2）基于大小，默认配置是1073741824。
需要注意的是，kafka读取特定消息的时间复杂度是O(1)，所以这里删除过期的文件并不会提高kafka的性能！

Данные о потреблении

消息存储在.log文件后，消费者就可以进行消费了。
与生产者生产消息相同的是，消费者在拉取消息的时候也是找leader去拉取。

多个消费者可以组成一个消费者组（consumer group），每个消费者组都有一个组id！
同一个消费者组的消费者可以消费同一topic下不同分区的数据，但是不会同组内多个消费者消费同一分区的数据！！！

是不是有点绕。我们看下图：
也就是说：同一个组内的多个消费者可以订阅同一个topic，但是消费的是topic内的不同的partition.
这就是并发机制。

图示是消费者组内的消费者数量小于partition数量的情况，所以会出现某个消费者消费多个partition数据的情况，消费的速度也就不及只处理一个partition的消费者的处理速度！
如果是消费者组的消费者多于partition的数量，那会不会出现多个消费者消费同一个partition的数据呢？
上面已经提到过不会出现这种情况！多出来的消费者不消费任何partition的数据。
所以在实际的应用中，建议消费者组的consumer的数量与partition的数量一致，这是最完美的。

上面?，我们聊到了partition划分为多组segment，
每个segment又包含.log、.index、.timeindex文件，
message存放在.log文件中。
存放的每条message包含offset、消息大小、消息体……
我们多次提到segment和offset，查找消息的时候是怎么利用segment+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。