架构成长之路：Kafka设计原理看了又忘，忘了又看？一文让你掌握

今天，我将围绕如下几个问题进行分享：

• 为什么需要消息系统?
• Kafka 架构原理?
• Kafka 如何存储消息?
• Producer 如何发送消息?
• Consumer 如何消费消息?
• Offset 如何保存?
• 消息系统可能遇到哪些问题？

为什么需要消息系统？

削峰

数据库的处理能力是有限的，在峰值期，过多的请求落到后台，一旦超过系统的处理能力，可能会使系统挂掉。

 

如上图所示，系统的处理能力是 2k/s，MQ 处理能力是 8k/s，峰值请求 5k/s，MQ 的处理能力远远大于数据库，在高峰期，请求可以先积压在 MQ 中，系统可以根据自身的处理能力以 2k/s 的速度消费这些请求。

这样等高峰期一过，请求可能只有 100/s，系统可以很快的消费掉积压在 MQ 中的请求。

注意，上面的请求指的是写请求，查询请求一般通过缓存解决。

解耦

如下场景，S 系统与 A、B、C 系统紧密耦合。由于需求变动，A 系统修改了相关代码，S 系统也需要调整 A 相关的代码。

过几天，C 系统需要删除，S 紧跟着删除 C 相关代码；又过了几天，需要新增 D 系统，S 系统又要添加与 D 相关的代码；再过几天，程序猿疯了...

 

这样各个系统紧密耦合，不利于维护，也不利于扩展。现在引入 MQ，A 系统变动，A 自己修改自己的代码即可；C 系统删除，直接取消订阅；D 系统新增，订阅相关消息即可。

 

这样通过引入消息中间件，使各个系统都与 MQ 交互，从而避免它们之间的错综复杂的调用关系。

Kafka 架构原理?

 

Kafka 相关概念：

• Broker：Kafka 集群中包含的服务器。
• Producer：消息生产者。
• Consumer：消息消费者。
• Consumer Group：每个 Consumer 都属于一个 Consumer Group，每条消息只能被 Consumer Group 中的一个 Consumer 消费，但可以被多个 Consumer Group 消费。
• Topic：消息的类别。每条消息都属于某个 Topic，不同的 Topic 之间是相互独立的，即 Kafka 是面向 Topic 的。
• Partition：每个 Topic 分为多个 Partition，Partition 是 Kafka 分配的单位。Kafka 物理上的概念，相当于一个目录，目录下的日志文件构成这个 Partition。
• Replica：Partition 的副本，保障 Partition 的高可用。
• Leader：Replica 中的一个角色， Producer 和 Consumer 只跟 Leader 交互。
• Follower：Replica 中的一个角色，从 Leader 中复制数据。
• Controller：Kafka 集群中的其中一个服务器，用来进行 Leader Election 以及各种 Failover。