Feed流架构涉及内容（一）-- kafka

这里额外整理一下kafka的知识点，我自己写自己也再过一遍。
参考：https://blog.csdn.net/u010020099/article/details/82290403
https://blog.csdn.net/kuluzs/article/details/71171537

kafka是一款基于发布与订阅的消息系统。它一般被称为“分布式提交日志”或者“分布式流平台”。文件系统或者数据库提交日志用来提供所有事物的持久化记录，通过重建这些日志可以重建系统的状态。同样地，kafka的数据是按照一定顺序持久化保存的，可以按需读取。

kafka的拓扑结构

image.png

Kafka的基本概念

名词 解释
Producer 消息的生成者
Consumer 消息的消费者
ConsumerGroup 消费者组，可以并行消费Topic中的partition的消息
Broker 缓存代理，Kafka集群中的一台或多台服务器统称broker.
Topic Kafka处理资源的消息源(feeds of messages)的不同分类
Partition Topic物理上的分组，一个topic可以分为多个partion,每个partion是一个有序的队列。partion中每条消息都会被分 配一个 有序的Id(offset)
Message 消息，是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息
Producers 消息和数据生成者，向Kafka的一个topic发布消息的 过程叫做producers
Consumers 消息和数据的消费者，订阅topic并处理其发布的消费过程叫做consumers

---

OKOK，一堆东西列上面估计你已经看晕了，那么这些一大堆东西其实可以分成两大部分。第一个是逻辑层面，第二个是物理层面。我从上往下来说：

逻辑层面

1、Topic，用来区分、隔离不同的消息数据，屏蔽了底层复杂的存储方式。对于大多数人来说，在开发的时候只需要关注数据写入到了哪个topic、从哪个topic取出数据。
（通俗点来说就有点像你往哪个mysql的表里写数据一样）
2、Consumer Group，是Kafka实现单播和广播两种消息模型的手段。同一个topic的数据，会广播给不同的group；同一个group中的worker，只有一个worker能拿到这个数据。换句话说，对于同一个topic，每个group都可以拿到同样的所有数据，但是数据进入group后只能被其中的一个worker消费。group内的worker可以使用多线程或多进程来实现，也可以将进程分散在多台机器上，worker的数量通常不超过partition的数量，且二者最好保持整数倍关系，因为Kafka在设计时假定了一个partition只能被一个worker消费（同一group内）。

物理层面

1、Broker，指kafka分布式服务中的一台机器，一个node。当然完全也可以只有一个broker，这个是在config配置项里需要配置的东西，与程序读写无关。
2、partition。partition会实际存储在系统的某个目录。
Topic的一个子概念，一个topic可具有多个partition，但Partition一定属于一个topic。
值得注意的是：
在实现上都是以每个Partition为基本实现单元的。
消费时，每个消费线程最多只能使用一个partition。
一个topic中partition的数量，就是每个user group中消费该topic的最大并行度数量。

（换个简单的方式理解，Partition可以理解为一个存放log的文件夹，kafka所有数据的读写都会以log方式实现，读写都会在这些文件夹中。user group的什么并行数量可以理解为每个文件夹只允许一个线程去读写，这样不会出现并发错误。）
3、Offset，专指Partition以及User Group而言，记录某个user group在某个partiton中当前已经消费到达的位置。