消息引擎系统
什么是 Kafka？
Apache Kafka 是一款开源的消息引擎系统。
这里说的 “消息引擎系统” 其实就是 “消息队列” “消息中间件”，这里用 “消息引擎系统” 是因为这个称谓更加合适；消息队列会让人误以为是利用队列的方式构建的；而消息中间件有过度夸大 “中间件” 的嫌疑。
像 Kafka 这一类的系统国外有专属的名字叫 Messaging System，国内很多文献简单将其翻译成消息系统。我感觉不太恰当，因为它片面强调了消息主题的作用，而忽视了这类系统引以为豪的消息传递属性，就像引擎一样，具备某种能力转换传输的能力，所以我觉得翻译成消息引擎反而更加贴切。
这类系统是做什么的呢？
根据维基百科的定义：消息引擎系统是一组规范。企业利用这组规范在不同系统之间传递语义准确的消息，实现松耦合的异步式数据传递。
如果不太能理解，可以试试下面的平民版：
系统 A 发送消息给消息引擎系统，系统 B 从消息引擎系统中读取 A 发送的消息。
最基础的消息引擎都是做这些事的，不论是官方版还是民间版，都提到了两个重要的事实：
- 消息引擎传输的对象是消息
- 如何传输消息属于消息引擎设计机制的一部分
既然消息引擎是用来传递不同系统之间的消息，那么就肯定要啊考虑如何设计待传输消息的格式。一条消息如何做到信息表达语义无歧义，同时还能最大限度提供可重用性以及通用性呢？
一个比较容易想到的就是使用已有的成熟方案，比如使用 CSV、XML亦或是 JSON；又或者国内外大厂开源的一些序列化框架，比如 Google 的 Protocol Buffer 或者 Facebook 的 Thrift。而 Kafka 使用的确实纯二进制的字节序列。不过消息肯定还是结构化的，只是在使用之前都要将其转换成二进制的字节序列。
消息设计出来之后，还要考虑消息引擎系统采用的具体传输协议，即我用什么方法把消息传递出去。常见的方法有两种：
- 点对点模型：又称消息队列模型。即系统 A 发送的消息只能被系统 B 接收，其他任何系统都不能读取到系统 A 发送的消息。举个例子：同一个客户呼入电话只能被一个客服人员处理，第二个客服人员不能为该客户服务。
- 发布/订阅模型：与上面不同的是，它有一个主题（Topic）的概念，可以理解成逻辑语义相近的消息容器。该模型也有接收方和发送方，只不过提法不同。发送方成为发送者（Publisher），接收方成为订阅者（Subscriber）。和点对点模型不同的是，这个模型存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们能接收到相同主题的消息。生活中的报纸订阅就是一种典型的发布/订阅模型。
Kafka 同时支持这两种消息引擎模型，在后续文章会再进行讲解。
为什么要使用它？
目前我们了解了消息引擎系统是做什么的，以及怎么做的，我们还需要知道为什么要使用它？
以上面的 “平民版” 举例，很多初学者会好奇，为什么系统 A 不直接发送消息给系统 B，中间还需要一个引擎系统？
答案是 ”削峰填谷“。
所谓的 “削峰填谷” 就是指缓冲上下游瞬间突发流量，使其更加平滑。尤其是对于那种发送能力很强的上游系统，如果没有消息引擎的保护，“脆弱” 的下游系统可能会直接被冲垮导致整个服务 “崩溃”。但是，一旦有了消息引擎，它能够更有效地对抗上游的流量冲击，真正做到将上游的 “峰” 填满到 ”谷“ 中，避免了流量的震荡。消息引擎系统的另一大好处在于发送方和接收方的松耦合，这也在一定程度上简化了应用的开发和维护成本，减少了系统不必要的交互。
再举个例子说明一下 ”削峰填谷“ 这个概念吧：在 ”双十一“ 秒杀活动中，上百万的抢购请求打到数据库里，很容易就导致数据库承受不住压力，直接崩掉。解决此类问题的常见做法是我们对上游系统进行限速，但这种常见做法对上游系统而言显然是不合理的，毕竟问题并不出现在它那里。所以更常见的办法是引入像 kafka 这样的消息引擎系统来对抗这种上下游系统 TPS 的错配以及瞬时峰值流量。
还是这个例子，当引入了 Kafka 之后。上游订单服务不再与下游子服务进行交互。当新订单生成后，它仅仅是向 Kafka Broker 发送一条订单消息即可。类似地，下游的各个子服务订阅 Kafka 中的对应主题，从而实现了上游订单服务与下游订单处理的解耦。这样当出现秒杀业务时，Kafka 能够将瞬间增加的订单流量全部以消息的形式保存在对应的主题中，既不影响上游的 TPS，同时也给下游子服务留出了充足的时间去消费它们。这就是 Kafka 这类消息引擎系统的最大意义所在。
小结
Apache Kafka 是一款开源的消息引擎系统。根据维基百科的定义，消息引擎系统是一组规范。企业利用这组规范在不同系统之间传递语义准确的消息，实现松耦合的异步式数据传递。通俗来讲，就是系统 A 发送消息给消息引擎系统，系统 B 从消息引擎系统读取系统 A 发送的消息
消息引擎系统要设定具体的传输协议，即我用什么方式把消息传输出去。常见的方法有两种：
- 点对点模型
- 发布/订阅模型
Kafka 这两种同时支持
系统 A 不能直接发送消息给系统 B，中间还要隔一个消息引擎，是为了 ”削峰填谷“。