面试官让我重构 Kafka，懵了

学算法认准 labuladong

经常有读者后台跟我说，希望我能够写一些系统设计相关的文章，最近我就在研究常用消息队列 kafka 和 pulsar 的架构设计，所以总结了这篇文章，希望在你做技术选型或阅读源码的时候起到一定的帮助。

我从以前的一个真实面试场景开始好了。

面试官：了解 Kafka 吗？简单介绍下？

我张口就来：Kafka 嘛，作为一款比较成熟的消息队列，它必然 YYDS，什么削峰填谷，异步化，解耦，高性能，高可用……

面试官：嗯，那么 Kafka 有什么缺点呢？

我：啊这……

平时背的八股文都是夸 Kafka 的，突如其来的这波反向操作可把我难住了。

面试官肯定一眼就看出来我在背八股文，对消息队列没有什么深入的研究，笑了笑，语重心长地教导我：

正所谓 时势造英雄 ，任何新技术的出现都是时代的产物，不存在 YYDS 的技术，Kafka 是很好，但在目前云原生的趋势下它确实老了，不能满足目前很多业务发展的需要了。你回去好好研究下 Kafka 可能存在的问题，如果让你来重新设计 Kafka，你会如何做？

我陷入沉思：时势造英雄，确实是这样。

想当年刚进大学的时候看着别人的教程自己搭博客平台，要登录 Linux 服务器安装 python mysql nginx 等等一大堆东西，还要熟悉 Centos/Ubuntu 等系统的各种配置细节的差异；后来实习的时候我拼命研究 OpenStack、Open vSwitch 什么的。现如今各种服务都是容器化一键部署，之前学的那套东西基本忘光了，脑子里只剩 docker + k8s 了。

类比过来，目前 Kafka 确实是主流消息队列，但这只能证明用它的人多，打得补丁多，并不能代表它是完美的，它的设计不可能跳出时代的局限，随着时代的发展，它必然也会被新的技术取代。

那我看看新一代的消息队列是如何设计的，不就可以学到 Kafka 的局限性以及改进思路了吗？

目前最新的消息队列是 Apache Pulsar ，于 2018 年毕业成为 Apache 顶级项目，号称是下一代云原生分布式消息流平台：

这么牛逼，那我必须研究一波 Pulsar 的设计，看看下一代云原生的消息平台长啥样。

消息队列的角色

首先看看我们为什么需要消息队列。

如果两个服务之间需要通信，最简单的方案就是直接让它俩之间建立通信就行了。但试想一下，如果所有生产数据的服务和消费数据的服务都要彼此相连，那么系统多了之后，各个系统之间的依赖关系会极其复杂。如果其中的某个系统进行一点修改，那简直是噩梦，真可谓牵一发而动全身。

而在生产者和消费者之间引入中间件就是为了解决这个问题：消息的产生者不关心消费者是谁，它只需要把消息一股脑丢到消息队列里面，消费者会从消息队列里面消费数据。

​

这就是系统设计中一个最简单实用的技巧：加中间层。没有什么问题是加一个中间层服务解决不了的，如果真解决不了，那就加两层。

PS：这不是玩笑，确实有句名言如是说：计算机领域的任何问题都可以通过添加中间层来解决。

细分一下，消费模型又分两种：

1、点对点模式，也叫队列模式。即每条消息只会被一个消费者消费。

2、发布订阅（Pub/Sub）模式。发送到某个 Topic 的消息，会分发给所有订阅该 Topic 的消费者进行消费。

一个成熟的消息队列应该同时支持上述两种消费模型。

另外，你总不能让生产者的消息「阅后即焚」吧，所以消息队列应该有自己的持久化存储系统，能够把消息存储下来，方便后续的回溯、分析等操作。

综上，消息队列在整个系统中的主要作用就是：

1、解耦。使得服务之间的拓扑关系简单了很多。

2、削峰/异步化。消息队列可以把大量不需要实时处理的数据暂存下来，等待消费者慢慢消费。

当然，消息队列中间件看似消除了服务之间的互相依赖，但说到底其实是让所有服务都依赖