关于后端:消息队列常见的使用场景

6次阅读

共计 2139 个字符,预计需要花费 6 分钟才能阅读完成。

本文曾经收录到 Github 仓库,该仓库蕴含 计算机根底、Java 根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享 等外围知识点,欢送 star~

Github 地址:https://github.com/Tyson0314/…

音讯队列常见的应用场景

音讯队列中间件是分布式系统中重要的组件,次要解决利用耦合,异步音讯,流量削锋等问题

实现高性能,高可用,可伸缩和最终一致性架构。

应用较多的音讯队列有 RocketMQ,RabbitMQ,Kafka,ZeroMQ,MetaMQ

以下介绍音讯队列在理论利用中罕用的应用场景。

异步解决,利用解耦,流量削锋、日志解决和音讯通信五个场景。

场景 1:异步解决

场景阐明:用户注册后,须要发注册邮件和注册短信。传统的做法有两种 1. 串行的形式;2. 并行形式

(1)串行形式:将注册信息写入数据库胜利后,发送注册邮件,再发送注册短信。以上三个工作全副实现后,返回给客户端

(2)并行形式:将注册信息写入数据库胜利后,发送注册邮件的同时,发送注册短信。以上三个工作实现后,返回给客户端。与串行的差异是,并行的形式能够进步解决的工夫

假如三个业务节点每个应用 50 毫秒钟,不思考网络等其余开销,则串行形式的工夫是 150 毫秒,并行的工夫可能是 100 毫秒。

因为 CPU 在单位工夫内解决的申请数是肯定的,假如 CPU1 秒内吞吐量是 100 次。则串行形式 1 秒内 CPU 可解决的申请量是 7 次(1000/150)。并行形式解决的申请量是 10 次(1000/100)

小结:如以上案例形容,传统的形式零碎的性能(并发量,吞吐量,响应工夫)会有瓶颈。如何解决这个问题呢?

引入音讯队列,将不是必须的业务逻辑,异步解决。革新后的架构如下:

依照以上约定,用户的响应工夫相当于是注册信息写入数据库的工夫,也就是 50 毫秒。注册邮件,发送短信写入音讯队列后,间接返回,因而写入音讯队列的速度很快,根本能够疏忽,因而用户的响应工夫可能是 50 毫秒。因而架构扭转后,零碎的吞吐量进步到每秒 20 QPS。比串行进步了 3 倍,比并行进步了两倍

场景 2:利用解耦

场景阐明:用户下单后,订单零碎须要告诉库存零碎。传统的做法是,订单零碎调用库存零碎的接口。如下图

传统模式的毛病:

  • 如果库存零碎无法访问,则订单减库存将失败,从而导致订单失败
  • 订单零碎与库存零碎耦合

如何解决以上问题呢?引入利用音讯队列后的计划,如下图:

  • 订单零碎:用户下单后,订单零碎实现长久化解决,将音讯写入音讯队列,返回用户订单下单胜利
  • 库存零碎:订阅下单的音讯,采纳拉 / 推的形式,获取下单信息,库存零碎依据下单信息,进行库存操作
  • 如果:在下单时库存零碎不能失常应用。也不影响失常下单,因为下单后,订单零碎写入音讯队列就不再关怀其余的后续操作了。实现订单零碎与库存零碎的利用解耦

场景 3:流量削锋

流量削锋也是音讯队列中的罕用场景,个别在秒杀或团抢流动中应用宽泛

利用场景:秒杀流动,个别会因为流量过大,导致流量暴增,利用挂掉。为解决这个问题,个别须要在利用前端退出音讯队列。

  • 能够管制流动的人数
  • 能够缓解短时间内高流量压垮利用
  • 用户的申请,服务器接管后,首先写入音讯队列。如果音讯队列长度超过最大数量,则间接摈弃用户申请或跳转到谬误页面
  • 秒杀业务依据音讯队列中的申请信息,再做后续解决

场景 4:日志解决

日志解决是指将音讯队列用在日志解决中,比方 Kafka 的利用,解决大量日志传输的问题。架构简化如下

  • 日志采集客户端,负责日志数据采集,定时写入 Kafka 队列
  • Kafka 音讯队列,负责日志数据的接管,存储和转发
  • 日志解决利用:订阅并生产 kafka 队列中的日志数据

以下是新浪 kafka 日志解决利用案例

(1)、Kafka:接管用户日志的音讯队列

(2)、Logstash:做日志解析,对立成 JSON 输入给 Elasticsearch

(3)、Elasticsearch:实时日志剖析服务的核心技术,一个 schemaless,实时的数据存储服务,通过 index 组织数据,兼具弱小的搜寻和统计性能

(4)、Kibana:基于 Elasticsearch 的数据可视化组件,超强的数据可视化能力是泛滥公司抉择 ELK stack 的重要起因

场景 5:音讯通信

音讯通信是指,音讯队列个别都内置了高效的通信机制,因而也能够用在纯的音讯通信。比方实现点对点音讯队列,或者聊天室等

点对点通信:

客户端 A 和客户端 B 应用同一队列,进行音讯通信。

聊天室通信:

客户端 A,客户端 B,客户端 N 订阅同一主题,进行音讯公布和接管。实现相似聊天室成果。

以上理论是音讯队列的两种音讯模式,点对点或公布订阅模式。模型为示意图,供参考。

本文转载自:https://www.cnblogs.com/ruiat…

最初给大家分享一个 Github 仓库,下面有大彬整顿的 300 多本经典的计算机书籍 PDF,包含 C 语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构和算法、机器学习、编程人生 等,能够 star 一下,下次找书间接在下面搜寻,仓库继续更新中~

Github 地址:https://github.com/Tyson0314/…

正文完
 0