前言
简单整理一下分发的基本思路。
正文
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是如何设计高可用的。以上只是个人理解，如有错误，望请指出。