kafka 第一次小整理(草稿篇)————分发的基本思路[三]

前言

简单整理一下分发的基本思路。

正文

kafka 原本是做日志管理系统，主要是分发这块的。

那么如何做分发呢？

分发的是什么呢？ 分发的其实是日志，日志是事件状态，kafka 内部就叫做Record，也就是记录哈，也可以叫做事件状态的记录，其实和日志的意思差不多了。

首先需求是有分类的，要给record 进行分类，这个分类就用topic。每个分类有自己的topic。

然后就是怎么存的问题了。

首先最容易想到的是下面这种:

一个队列，往队列里面存就好，然后另外一端进行消费就好。

这样又一个问题，那就是分发的需求是不止能分发一个，还要分发很多个消费者。

那么就不能是队列，因为队列消费掉就没了。

那么想到的就是数组。

为什么是数组呢？

因为数组有索引，多个消息者要需要记住自己消费到什么地方了。

这个就是消费者位移，表示消费者的消费进度，每个消费者都有自己的消费者位移。

有了这个消费者位移后，消费者得告诉自己叫什么吧，消费者不得给个名字啊，不然谁知道呢？

那就变成了上面这样。

似乎这样就能满足需求了。

然后运行起来发现一个问题，那就是生产在大多数情况下，是会形成堵塞的。

因为这样还是一个可能多个生产，但是一个消费的情况。即使生产一个，消费一个（这里只消费名相同），那也肯定是达不到，因为报告一件事情容易，解决一件事情困难。

那么能不能这样呢？

那么下一个想法就是能不能增加消费速度呢？

上面就是有多个consumer name 为consumer1的同时进行消费。

这里且不管实现难度哈，单纯概念。假如有多个consumer1 可以同时进行消费，且不会消费到相同的，这样就增加了消费速度。

那么这就是一组consumer，那么得给这个组改个名字，叫做consumer group。

这样似乎是没有问题了，虽然这样实现比较复杂，但是能实现。

上面这种想法也是能实现的，比如说有一个consumer group 里面的取个一条数据，已经消费的标记为消费，如果消费了，offset 继续偏移就好，不需要消费。

但是这样有一个问题，这里不谈及到任何实现困难上，那就是不能保证消费顺序。

在现实中我们收到的新闻是有时间顺序的，但是这样消费的是没有顺序的。

比如说，最近俄乌战争，加入你先收到的是俄乌战争结束了，然后收到俄乌战争开始了，懵逼不。（讲过实际中的例子，如果无法保证消费顺序的话，比如说一个命令是开机一个命令是关机，用户执行的是先关机再开机，那么如果开机和关机命令是相反的，可想而知效果完全不同）

这是不是很不科学啊。所以这样做是不符合现实世界的，计算机世界现在是帮助我们解决现实世界的问题。

这样是不符合需求的。那么既然，消费者增加不可靠，那么可以这样。

那就按照上面这样，增加topic，细化。

比如战争新闻，分为叙利亚的、阿富汗的等。

这样不就ok了呀。

这样的确可以哈，消费者和生产者。

但是呢，扩展性很差，需要很多个topic，每增加一个都需要增加一个topic，无论是对于code 还是 对于业务都困难。

那么能不能合成一个topic呢？

不知道有没有看过actionblock 或者channel 这种异步方式，这种管道模式就是一个入口，处理管道。

这里设置多跟管道，kafka里面叫做分区。

然后每个分区里面只能被一个消费者消费，这是为了保证record的顺序，前文已经提及到了。

然后考虑下一个问题，这里是一个消费者对于一个分区。 且一个分区只能被一个消费者里面的一个分区消费。

这样设计依然存在瑕疵。

有多个消费组，有些消费组需要的record 很多，有些只是取其中很少部分。举个例子，比如说战争新闻，有些消费组只关系俄乌关系，其余消息不做处理，进行过滤。

那么这个消费组消费的就很快，那么这个消费组里面就不需要这么多的消费者。所以肯定不能设计成一对一的关系。

那有没有可能设计一个消费组里面的一个消费者消费多个分区呢？ 这也是可以的。这个时候就有处理一个消费组里面的消费者要覆盖这个topic全部分区的情况。那么就要考虑如果增加了一个消费者如何处理，如果一个消费组下线（无论是掉线还是业务需求）如何处理。

至此差不多就是kafka的基本雏形。如果没有接触异步编程，那么的确很难想到kafka这种模型，如果知道actionblock 或者channel 这种，但是更能理解了。

结

至此，简单分析了一个kafka的分发模型，下一节kafka是如何设计高可用的。以上只是个人理解，如有错误，望请指出。