架构设计

如果让你设计一个消息队列，你会怎么设计它的架构？

面试准备

• Kafka为什么要引入topic？
• Kafka为什么要引入分区？只有topic行不行？
• Kafka为什么要强调把topic的分区分散在不同的broker上？ Kafka为什么要引入消费者组概念？只有消费者行不行？

面试思路

基于mysql封装消息队列

topic设计

topic会有若干分区，分区分散在不同的broker上。有些分区叫做Partition，有的叫Queue

topic代表不同的业务，不划分分区，就会出现竞争

结合 MySQL 的特性，最基础的设计就是一个topic是一个逻辑表，而对应的分区就是对这个逻辑表执行分库分表之后得到的物理表。

举个例子，假如说有一个叫做 create_order 的 topic，那么就代表我有一个逻辑上叫做create_order 的表。如果这个topic有 3 个分区，那么就代表我有create_order_0、create_order_1 和 create_order_2 三张物理表。这种情况下，每一张表都可以用自增主键，这个自增主键就对应于 Kafka 中的偏移量。

broker和消息存储

发送消息

批量发送

直接插入消息

消费消息

记录偏移量

直接拉取消息

延迟消息

面试思路总结

• 一个topic一个逻辑表，一个分区一个物理表。
• 同一个topic 的不同分区对应的表，应该尽可能分散在不同的数据库、主从集群上。生产者使用推模型，主动推送消息。
• 生产者可以考虑使用批量发送、直连数据库的方式提高性能。
• 一个topic一个消费偏移量表，用来记录各个消费者组的消费进度。消费者使用拉模型，按照自己的消费能力按需拉取。
• 可以通过增加send_time这个列来支持延时队列。