Kafka架构的艺术-谈谈KAFKA的架构以及这种架构的优势

待我称王封你为后i 2021-12-03 23:39 206阅读 0赞

# Kafka各组件 #

## Broker(一个kafka节点) ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70]  
每个kafka节点称为一个Broker，一个服务器上可以部署一个或者多个kafka的节点（示例图中每个服务器只部署了一个），然后这些节点连接到注册中心上，就形成了一个kafka的集群。

## Topic（主题） ##

在kafka中消息是分类型的，比如用户行为日志类型，支付订单类型，结算数据类型等，不同类别的消息在生产的时候可以指定发送到不同的Topic里。  
**一个Broker上可以创建一个或者多个Topic。同一个topic可以在同一集群下的多个Broker中分布。**  
所以上诉用图表示就是如下  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 1]

## Partition（分区） ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 2]  
每个Topic分为一个或多个Partition，每个分区会映射到一个逻辑的日志（log）文件，是kafka中真正存储消息的单元。  
每当一个message被发布到一个topic上的一个partition，broker应会将该message追加到这个逻辑log文件的最后一个segment上。这些segments 会被flush到磁盘上。Flush时可以按照时间来进行，也可以按照message 数来执行。

每个partition都是一个有序的、不可变的结构化的提交日志记录的序列。在每个partition中每一条日志记录都会被分配一个序号——通常称为offset，offset在partition内是唯一的。论点逻辑文件会被化分为多个文件segment（每个segment的大小一样的）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 3]

那么也就是说在kafka中虽然消息是无序的，但是**发送到同一个partition上的消息是有序的**。

# Kafka的架构优点 #

我们前面说到，同一个topic会在多个broker上存在，那么为什么要这样设计呢？这其实是因为每一个broker上的topic里面包含的Partition其实是不一样的。

**假设一个Topic包含4个Partition，Kafka内部会根据一定的算法把这4个Partition尽可能均匀分布到不同的服务器上的同一个Topic中。这样做是为了容灾。具体会复制几份，会复制到哪些broker上，都是可以配置的。**

我知道上面这段话有点绕，下面我们来举个例子，比如：

服务器1负责topic2的Partition1、Partition2，Partition4  
服务器2负责topic2的Partition1、Partition3，Partition4  
服务器3负责topic2的Partition2、Partition3  
为了方便（因为我懒 ），我在每个broker中只画了一个Topic，同时，用p1,p2,p3,p4来表示Partition1、Partition2，Partition3，Partition4。那么整个架构如下所示  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 4]  
可以看到，对于每一个Partition实际上都有2个备份，这就很好的实现了容灾。

看了上面，相信你已经对kafka的架构有所了解了，其实这种奇妙的架构是有很大的优点的。kafka是不支持读写分离的，也就是说，不管是写还是读，都是发送到主节点。只不过在kafka中的主节点，并不是我们传统意义上的实体服务器，而是一个Partition。前面讲过了，生产者生产数据和消费者接收数据，实际上都是和topic里面的Partition打交道。

我们再举个例子  
下图中，标红的Partition代表主Partition，比如Partition1的主节点在borker2中，Partition2的主节点在borker1中，其他参照下图。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 5]  
那么这个时候生产者生产数据和消费者消费数据是怎样的流程图呢？  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 6]  
在kafka中，生产者生产的数据会采用一定的算法分配到不同的Partition上，当数据量足够大的时候，每个Partition的负载压力是差不多的，对于上图，可能服务器2的负载压力会大一点，那是因为有两个主节点在在这台服务器上（我懒的画图 ），在实际环境中，我们可以尽可能的均匀分配主节点，这样每一台服务器的压力就差不多了。

# 总结 #

可以看出得益于 Kafka 优秀的架构设计，kafka完全从架构上给我们实现了灾备，负载均衡。

Kafka之所以不支持读写分离，也是有原因的，主写主读可以简化代码的实现逻辑，减少出错的可能；将负载粒度细化均摊，与主写从读相比，不仅负载效能更好，而且对用户可控；没有延时的影响；在副本稳定的情况下，不会出现数据不一致的情况。

从某种意义上来说，主写从读是由于设计上的缺陷而形成的权宜之计。

虽然，在某些情况下由于机器数量问题，可能会带来负载不均衡，但我们也可以通过调整来避免这些情况，详细可以看[这篇文章][Link 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70]: /images/20211203/046d2387d47b4cf7923c58d8f15b9f82.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 1]: /images/20211203/96bdd4c2f0a94a5ab5b81315507c3688.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 2]: /images/20211203/914b8c7b69aa4aebbd53723c4aa10067.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 3]: /images/20211203/60f31525c82a417094ec71ce3ee9ea2c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 4]: /images/20211203/8dea2636420f4590b4ecbb20a146153f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 5]: /images/20211203/a749d65cdd3f4c958d7bf9fab13581f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70 6]: /images/20211203/b73d75b57a88465bb4ab17f7c4e6ab99.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzI1NDQ3MjQxNA==&mid=2247488775&idx=1&sn=b7d2dc48f9740932e5282de35d8348d5&chksm=e9c5ecb6deb265a09e4694851f87cb46785b902da05994fe82883b0f046689c380cf22353fc5&mpshare=1&scene=24&srcid=#rd