温州有没有专门的企业网站,宝安营销型网站设计,广告联盟点击广告能赚多少,wordpress添加主栏目对于 MQ 来说#xff0c;不管是 RocketMQ、Kafka 还是其他消息队列#xff0c;它们的本质都是#xff1a;一发一存一消费。下面我们以这个本质作为根#xff0c;一起由浅入深地聊聊 MQ。 01 从 MQ 的本质说起
将 MQ 掰开了揉碎了来看#xff0c;都是「一发一存一消费」不管是 RocketMQ、Kafka 还是其他消息队列它们的本质都是一发一存一消费。下面我们以这个本质作为根一起由浅入深地聊聊 MQ。 01 从 MQ 的本质说起
将 MQ 掰开了揉碎了来看都是「一发一存一消费」再直白点就是一个「转发器」。
生产者先将消息投递一个叫做「队列」的容器中然后再从这个容器中取出消息最后再转发给消费者仅此而已。 上面这个图便是消息队列最原始的模型它包含了两个关键词消息和队列。 1、消息就是要传输的数据可以是最简单的文本字符串也可以是自定义的复杂格式只要能按预定格式解析出来即可。 2、队列大家应该再熟悉不过了是一种先进先出数据结构。它是存放消息的容器消息从队尾入队从队头出队入队即发消息的过程出队即收消息的过程。 2.1 队列模型
最初的消息队列就是上一节讲的原始模型它是一个严格意义上的队列Queue。消息按照什么顺序写进去就按照什么顺序读出来。不过队列没有 “读” 这个操作读就是出队从队头中 “删除” 这个消息。 这便是队列模型它允许多个生产者往同一个队列发送消息。但是如果有多个消费者实际上是竞争的关系也就是一条消息只能被其中一个消费者接收到读完即被删除。 2.2 发布-订阅模型
如果需要将一份消息数据分发给多个消费者并且每个消费者都要求收到全量的消息。很显然队列模型无法满足这个需求。
一个可行的方案是为每个消费者创建一个单独的队列让生产者发送多份。这种做法比较笨而且同一份数据会被复制多份也很浪费空间。
为了解决这个问题就演化出了另外一种消息模型发布-订阅模型。 在发布-订阅模型中存放消息的容器变成了 “主题”订阅者在接收消息之前需要先 “订阅主题”。最终每个订阅者都可以收到同一个主题的全量消息。
仔细对比下它和 “队列模式” 的异同生产者就是发布者队列就是主题消费者就是订阅者无本质区别。唯一的不同点在于一份消息数据是否可以被多次消费。 2.3 小结
最后做个小结上面两种模型说白了就是单播和广播的区别。而且当发布-订阅模型中只有 1 个订阅者时它和队列模型就一样了因此在功能上是完全兼容队列模型的。 举一个实际例子比如说电商业务中最常见的「订单支付」场景在订单支付成功后需要更新订单状态、更新用户积分、通知商家有新订单、更新推荐系统中的用户画像等等。 引入 MQ 后订单支付现在只需要关注它最重要的流程更新订单状态即可。其他不重要的事情全部交给 MQ 来通知。这便是 MQ 解决的最核心的问题系统解耦。
改造前订单系统依赖 3 个外部系统改造后仅仅依赖 MQ而且后续业务再扩展比如营销系统打算针对支付用户奖励优惠券也不涉及订单系统的修改从而保证了核心流程的稳定性降低了维护成本。
这个改造还带来了另外一个好处因为 MQ 的引入更新用户积分、通知商家、更新用户画像这些步骤全部变成了异步执行能减少订单支付的整体耗时提升订单系统的吞吐量。这便是 MQ 的另一个典型应用场景异步通信。
除此以外由于队列能转储消息对于超出系统承载能力的场景可以用 MQ 作为 “漏斗” 进行限流保护即所谓的流量削峰。
