Kafka是什么?为何要用？

Kafka是什么?为何要用？

Kafka 是什么？

毫无疑问，你如今对 Apache Kafka 必定充满了各类好奇，那么今天就容许我先来尝试回答下" Kafka 是什么"这个问题。那么，Kafka 是什么呢？用一句话归纳一下：Apache Kafka 是一款开源的消息引擎系统。

假若“消息引擎系统”这个词对你来讲有点陌生的话，那么“消息队列”“消息中间件”的提法想必你必定是有所耳闻的。不过说实话我更愿意使用消息引擎系统这个称谓，由于消息队列给出了一个很不明确的暗示，仿佛 Kafka 是利用队列的方式构建的；

而消息中间件的提法有过分夸张“中间件”之嫌，让人搞不清楚这个中间件究竟是作什么的。像 Kafka 这一类的系统国外有专属的名字叫 Messaging System，国内不少文献将其简单翻译成消息系统。我我的认为并非很恰当，由于它片面强调了消息主体的做用，而忽视了这类系统引觉得豪的消息传递属性，就像引擎同样，具有某种能量转换传输的能力，因此我以为翻译成消息引擎反倒更加贴切。

仍是拉回来继续聊消息引擎系统，那这类系统是作什么用的呢？我先来个官方严肃版本的答案。
根据维基百科的定义，消息引擎系统是一组规范。企业利用这组规范在不一样系统之间传递语义准确的消息，实现松耦合的异步式数据传递。

果真是官方定义，有板有眼。
若是以为难于理解，那么能够试试我下面这个民间版：
系统 A 发送消息给消息引擎系统，系统 B 从消息引擎系统中读取 A 发送的消息。

最基础的消息引擎就是作这点事的！不管是上面哪一个版本，它们都提到了两个重要的事实：

消息引擎传输的对象是消息；
如何传输消息属于消息引擎设计机制的一部分。

既然消息引擎是用于在不一样系统之间传输消息的，那么如何设计待传输消息的格式历来都是一等一的大事。试问一条消息如何作到信息表达业务语义而无歧义，同时它还要能最大限度地提供可重用性以及通用性？稍微停顿几秒去思考一下，若是是你，你要如何设计你的消息编码格式。

一个比较容易想到的是使用已有的一些成熟解决方案，好比使用 CSV、XML 亦或是JSON；又或者你可能熟知国外大厂开源的一些序列化框架，好比 Google 的 Protocol Buffer 或 Facebook 的 Thrift。这些都是很酷的办法。那么如今我告诉你 Kafka 的选择：它使用的是纯二进制的字节序列。固然消息仍是结构化的，只是在使用以前都要将其转换成二进制的字节序列。

消息设计出来以后还不够，消息引擎系统还要设定具体的传输协议，即我用什么方法把消息传输出去。常见的有两种方法：
**

• 点对点模型：也叫消息队列模型。若是拿上面那个“民间版”的定义来讲，那么系统 A发送的消息只能被系统 B 接收，其余任何系统都不能读取 A 发送的消息。平常生活的例子好比电话客服就属于这种模型：同一个客户呼入电话只能被一位客服人员处理，第二个客服人员不能为该客户服务。
• 发布 / 订阅模型：与上面不一样的是，它有一个主题（Topic）的概念，你能够理解成逻辑语义相近的消息容器。该模型也有发送方和接收方，只不过提法不一样。发送方也称为发布者（Publisher），接收方称为订阅者（Subscriber）。和点对点模型不一样的是，这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。生活中的报纸订阅就是一种典型的发布 / 订阅模型。

比较酷的是 Kafka 同时支持这两种消息引擎模型，后面我会分享 Kafka 是如何作到这一点的。

提到消息引擎系统，你可能会问 JMS 和它是什么关系。JMS 是 Java Message Service，它也是支持上面这两种消息引擎模型的。严格来讲它并不是传输协议而仅仅是一组 API 罢了。不过多是 JMS 太有名气以致于不少主流消息引擎系统都支持 JMS 规范，好比ActiveMQ、RabbitMQ、IBM 的 WebSphere MQ 和 Apache Kafka。

固然 Kafka 并未彻底遵守 JMS 规范，相反，它另辟蹊径，探索出了一条特有的道路。

好了，目前咱们仅仅是了解了消息引擎系统是作什么的以及怎么作的，但还有个重要的问题是为何要使用它。

为何要使用它

依旧拿上面“民间版”举例，咱们不由要问，为何系统 A 不能直接发送消息给系统 B，中间还要隔一个消息引擎呢？

答案就是“削峰填谷”。这四个字简直比消息引擎自己还要有名气。

我翻了不少文献，最多见的就是这四个字。所谓的“削峰填谷”就是指缓冲上下游瞬时突发流量，使其更平滑。特别是对于那种发送能力很强的上游系统，若是没有消息引擎的保护，“脆弱”的下游系统可能会直接被压垮致使全链路服务“雪崩”。

可是，一旦有了消息引擎，它可以有效地对抗上游的流量冲击，真正作到将上游的“峰”填满到“谷”中，避免了流量的震荡。消息引擎系统的另外一大好处在于发送方和接收方的松耦合，这也在必定程度上简化了应用的开发，减小了系统间没必要要的交互。

说了这么多，可能你对“削峰填谷”并无太多直观的感觉。

解决此问题的一个常见作法是咱们对上游系统进行限速，但这种作法对上游系统而言显然是不合理的，毕竟问题并不出如今它那里。因此更常见的办法是引入像 Kafka 这样的消息引擎系统来对抗这种上下游系统 TPS 的错配以及瞬时峰值流量。
仍是这个例子，当引入了 Kafka 以后。上游订单服务再也不直接与下游子服务进行交互。相似地，下游的各个子服务订阅 Kafka 中的对应主题，并实时从该主题的各自分区（Partition）中获取到订单消息进行处理，从而实现了上游订单服务与下游订单处理服务的解耦。Kafka 可以将瞬时增长的订单流量所有以消息形式保存在对应的主题中，既不影响上游服务的 TPS，同时也给下游子服务留出了充足的时间去消费它们。这就是 Kafka 这类消息引擎系统的最大意义所在。

最后我想送给你一句话：聪明人也要下死功夫。当我感到浮躁的时候它能帮我静下心来踏踏实实作事情。但愿这句话对你也有所启发。切记：聪明人要下死功夫！