01 | 消息引擎系统ABC

胡夕



该思维导图由 AI 生成，仅供参考

你好，我是胡夕。欢迎你来到“Kafka 核心技术与实战”专栏。如果你对 Kafka 及其背后的消息引擎、流处理感兴趣，很高兴我们可以在此相聚，并在未来的一段日子里一同学习有关 Kafka 的方方面面。
毫无疑问，你现在对 Apache Kafka 一定充满了各种好奇，那么今天就允许我先来尝试回答下 Kafka 是什么这个问题。对了，先卖个关子，在下一期我还将继续回答这个问题，而且答案是不同的。那么，Kafka 是什么呢？用一句话概括一下：Apache Kafka 是一款开源的消息引擎系统。
倘若“消息引擎系统”这个词对你来说有点陌生的话，那么“消息队列”“消息中间件”的提法想必你一定是有所耳闻的。不过说实话我更愿意使用消息引擎系统这个称谓，因为消息队列给出了一个很不明确的暗示，仿佛 Kafka 是利用队列的方式构建的；而消息中间件的提法有过度夸张“中间件”之嫌，让人搞不清楚这个中间件到底是做什么的。
像 Kafka 这一类的系统国外有专属的名字叫 Messaging System，国内很多文献将其简单翻译成消息系统。我个人认为并不是很恰当，因为它片面强调了消息主体的作用，而忽视了这类系统引以为豪的消息传递属性，就像引擎一样，具备某种能量转换传输的能力，所以我觉得翻译成消息引擎反倒更加贴切。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

Apache Kafka: 解耦异步数据传递的利器 Apache Kafka是一款开源的消息引擎系统，旨在实现系统间的松耦合异步数据传递。它通过消息队列和发布/订阅模型传输消息，同时支持JMS规范，主要用于“削峰填谷”，即缓冲上下游瞬时突发流量，使其更平滑，避免流量的震荡。Kafka使用纯二进制的字节序列作为消息格式，并具有点对点模型和发布/订阅模型的双重支持。引入Kafka后，上游系统不再直接与下游子服务进行交互，而是通过Kafka Broker发送和接收消息，实现了上游和下游服务的解耦，从而有效应对瞬时峰值流量。作者分享了对Kafka源代码的阅读经历，强调了“聪明人也要下死功夫”的重要性。这篇文章深入浅出地介绍了Kafka的特点和应用，对于想要快速了解消息引擎系统的读者来说，是一份有价值的技术概览。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Kafka 核心技术与实战》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(121)

最新
精选

孙志强
讲讲怎么把50完行源代码读下来的? 嘿嘿
作者回复: 一行一行啃下来的。如果你也有兴趣，我建议可以先从kafka.log包开始读起，会很有收获的~~
2019-06-04
6
68
开发无止境，BUG随身行
有个问题请教下老师: 之前也用过kafka，怎么解决实时结果响应问题呢？比如秒杀商品，生产者产生订单，消费者处理订单结果，那这结果如何实时返回给用户呢？
作者回复: 这个场景使用Kafka Streams比较适合，它就是为read-process-write场景服务的
2019-06-03
2
60
Lei Yang
老师可以讲一讲Kafka和别的mq的区别和最佳选择方法么？例如什么时候选择RabbitMQ什么时候选择Kafka等等
作者回复: RabbitMQ属于比较传统的消息队列系统，支持标准的消息队列协议（AMQP, STOMP，MQTT等），如果你的应用程序需要支持这些协议，那么还是使用RabbitMQ。另外RabbitMQ支持比较复杂的consumer Routing，这点也是Kafka不提供的。
2019-06-03
2
52
Dovelol
老师好，想问下有些业务用mq来做异步处理，为了削峰填谷，是不是上游发送消息成功就认为业务成功了，可能下游过很久去消费，那实时性要求很高的业务怎么办呢，比如生成了订单但是一直不处理也不好吧。另外想请教下老师的角度来讲下mq和rpc调用的区别是什么呢？
作者回复: mq和rpc的区别往大了说属于数据流模式（dataflow mode）的问题。我们常见的数据流有三种：1. 通过数据库；2. 通过服务调用（REST/RPC）; 3. 通过异步消息传递（消息引擎，如Kafka） RPC和MQ是有相似之处的，毕竟我们远程调用一个服务也可以看做是一个事件，但不同之处在于： 1. MQ有自己的buffer，能够对抗过载（overloaded）和不可用场景 2. MQ支持重试 3. 允许发布/订阅模式当然它们还有其他区别。应该这样说RPC是介于通过数据库和通过MQ之间的数据流模式。
2019-06-03
5
51
Shane
老师，今天才学习到这篇文章，还是老师能够在百忙之中抽出时间来解答我的困惑。这篇文章提到了消息的协议，老师这里介绍了两种模式一种是点对点，一种是订阅，发布模式。但是，为什么我一开始想到消息的协议是http之类的传输协议？这两个有什么区别和联系？
作者回复: http不属于消息传输协议，它是网络通信协议的一种，严格来说这是两个范畴或者说是两个层次上的协议。通常来说，两个进程进行数据流交互的方式一般有三种： 1. 通过数据库：进程1写入数据库；进程2读取数据库 2. 通过服务调用：比如REST或RPC，而HTTP协议通常就作为REST方式的底层通讯协议 3. 通过消息传递的方式：进程1发送消息给名为broker的中间件，然后进程2从该broker中读取消息。消息传输协议属于这种模式因此我说虽然我们都称它们为协议，但它们不是一个层次上的协议。
2019-06-14
4
39
jeffery
pulsar高吞吐低延迟和kafka谁会主宰未来？夕哥、能不能拓展下flink+kafka的耦合！谢谢
作者回复: 和Pulsar的斯杰、翟佳都相识，不敢妄下结论。Flink + Kafka最近的确有标准套餐的趋势：）
2019-06-03
2
27
杨鹏程baci
胡夕老师好，我是第一次在这提问，这门课程我应该是0基础了，有一些疑问希望老师帮忙解答一下，用消息引擎的这种数据流数据方式，上游是不是就无法得知处理结果了，甚至是无法将返回值传回上游了？谢谢！
作者回复: 嗯嗯，确实不太容易。因为这种通信方式一般是异步且是单向的，如果你需要这种回馈机制，最好使用服务调用的方式
2019-06-20
3
23
gnayuh
老师讲的很好，我是之前那种听过kafaka等消息引擎大名的初学者，听完第一节课，联想到这个发布订阅模型跟之前学过java设计模式之观察者，总感觉它们之间有那么点类似，想知道它们之间的某种关系。还有就是学操作系统时候的生产者消费者也很像
作者回复: 它们的确很类似。特别是发布/订阅与观察者模式。在《Head first Design Pattern》一书中更是有这样的话： Publishers + Subscribers = Observer Pattern 不过细究起来还是有些许不同，pub与sub之间通常都隔了一层，比如broker或message channel，但是Observer模式中Observer通常都直接对接被观测者，因此Pub/Sub模式中组件的耦合度更低；另外Pub/Sub经常是以异步的方式实现，而Observer模式通常都是同步的
2019-06-03

22
燕子上
我司直接把kafka当mq来使用，高吞吐、低延迟、松耦合。对！我司看上了松耦合，哪哪都要用kafka解耦，真正的面向kafka编程🤣
作者回复: 赞👍
2019-06-04
2
21
Bin滨
谢谢知识分享。在Martin Kleppmann 的书中把kafka 定义成 log-based message brocker，这个基本上是对kafka最简单的定义了。append-only， partition， totally ordered 是比较需要理解的概念。
作者回复: 嗯嗯，DDIA是一本神书：）其实这个定义最早还是Kafka作者Jay Kreps提出的，有兴趣可以看看Kafka的论文：http://notes.stephenholiday.com/Kafka.pdf 以及Jay Kreps的《I ❤️ Logs》
2019-06-19

17

收起评论