消息引擎系统介绍

kafka是什么？kafka是一款开源的消息引擎系统。如果消息引擎系统这个词对你来说有点陌生的话，那么"消息队列"、“消息中间件"你一定是有所耳闻的。对于kafka来说，如果叫消息队列，那么仿佛是在暗示kafka使用队列的方式构建的，如果叫消息中间件，又过度夸张"中间件”，让人搞不清楚这个中间件到底是干嘛的。而kafka在国外有一个专属的名字，叫做Message System，之所以翻译成消息引擎系统，是因为不要只关注递消息，同时也要关注这类系统所具有的引以为豪的消息传递属性，就像引擎一样，具备某种能量转换传输的能力。

那么继续聊聊消息引擎系统，这类系统是干什么的呢？根据维基百科的定义，消息引擎系统是一组规范，企业利用这组规范在不同系统之间传递语义准确的消息，实现松耦合的异步式数据传递。官方的定义难以理解，我们可以看一个民间版的定义。

消息A发送消息给消息引擎，系统B从消息引擎系统中读取A发送的消息。

是不是很简单呢？最基础的消息引擎就是用来干这点事的。无论怎么定义，都提到了两个重要的事实。
消息引擎传输的对象是消息
如何传输消息属于消息引擎设计机制的一部分

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

一个比较容易想到的是使用一些已有的成熟解决方案，比如使用csv、xml、json等等，又或者是国外大厂开源的一些序列化框架，比如Google的protocol buffer和Facebook的thrift。但是对于kafka来说，它使用的是纯二进制的字节序列。当然消息还是结构化的，只是使用之前都是要将其转化成二进制的字节序列。

但是消息设计出来还不够，之前也提到过，如何传递消息也是属于消息引擎设计机制的一部分。也就是说，我用什么方式将消息传递出去。常见的有两种方法：
点对点模型：点对点模型，也叫做消息队列模型。如果拿上面的那个民间版的定义来说的话，那么系统A发送的消息只能被系统B接收，其他任何系统都不能接收A发来的消息。日常生活中，就像电话客服服务，同一个客户呼入电话，只能被一位客服人员处理，第二个客服人员不能为该客服服务。
发布/订阅模型：和点对点模型不同，它有一个主题（Topic）的概念。该模型也有发送方和接收方，只不过叫法不一样。发送方也被称为发布者（publisher），接收方称为订阅者（subscriber）。和点对点模型不一样，这个模型可以存在多个发布者和多个订阅者，它们都能接收到相同主题的消息。好比微信公众号，一个公众号可以有多个订阅者，一个订阅者也可以订阅多个公众号。

提到消息引擎系统，可能或有人好奇，它和jms是什么关系。jms是java message service，它也是支持上面这两种消息引擎模型的，并且严格来说，它并非传输协议，而是一组api罢了。不过可能是jms太有名气，以至于很多主流消息引擎系统都支持jms规范，不如ActiveMQ,RabbitMQ,IBM的WebSphereMQ和Apache Kafka。当然kafka并未完全遵照jms规范，相反，它另辟蹊径，探索出了一条特有的道路。

介绍完消息引擎系统以及模型，我们回过头来思考。还拿之前的例子，为什么系统A不直接向系统B发送消息，而是非要隔一个消息引擎呢？

答案是：削峰填谷，真的是非常形象的四个字。所谓的削峰填谷，就是指缓冲上下游瞬时突发流量，使其更平滑。特别是那种发送能力很强的上游系统，如果没有消息引擎的保护，脆弱的下游系统可能直接被压垮导致全链路服务雪崩。但是，一旦有了消息引擎，它能够有效的对抗上游的流量冲击，真正做到将上游的"峰"填到下游的"谷"中，避免了流量的震荡。消息引擎系统的另一大好处在于发送方和接收方的耦合，这也在一定程度上简化了应用的开发，减少了系统间不必要的交互。

说了这么多，可能没有直观的感受，我们来举一个实际的例子。比如在京东购买商品。当点击购买的时，会调用订单系统生成对应的订单，然而要处理订单，则会依次调用下游系统的多个子服务，比如调用银行等支付接口、查询你的登录信息、验证商品信息等等。显然上游的订单操作比较简单，它的TPS要远高于处理订单的下游服务。因此如果上游和下游直接对接，势必会出现下游服务无法及时处理上游订单从而造成订单堆积的情况。特别是当出现双十一、双十二、类似秒杀这种业务的时候，上游订单流量会瞬间增加，可能出现的结果就是直接压垮下游子系统服务。解决此问题的一个此常见的做法就是对上游系统进行限速，但是这种做法显然是不合理的，毕竟问题不是出现在它那里。况且那你要是限速了，别人家的网站双十一成交一千万笔单子，自家网站才成交一百万笔单子，这样钱送到嘴边都赚不到。所以更常见的办法就是引入像kafka这样的消息引擎系统来对抗这种上下游的TPS不一致以及瞬时峰值流量。

还是这个例子，引入kafka之后，上游系统不再直接与下游系统进行交互。新订单生成之后它仅仅是向kafka broker发送一条消息即可。类似的，下游的各个子服务sing月kafka中的对应主题，并实时从该主题的各自分区（partition）中获取到订单消息进行处理，从而实现上游订单服务和下游订单处理服务的解耦。这样当出现秒杀业务端额时候，kafka能够将瞬时增加的订单流量全部以消息的形式保存在对应的主题中。既不影响上游服务的TPS，同时也给下游服务留出了足够的时间去消费它们。这就是kafka这类消息引擎存在的最大意义所在。

转自：
https://www.cnblogs.com/yuhan-Hanny/p/11684681.html