高并发处理思路与手段(三):消息队列

一、消息队列在实际场景中的使用

流程A在处理时没有在当前线程同步的处理完而是直接发送了一条消息A1到队列里,然后消息队列过了一段时间(可能是几毫秒 几秒 几分钟)这个消息开始被处理,消息处理的过程就相当于流程A被处理;当然这只是一个简单的模型下面我们套用实际的场景来看一下,比如下单成功后发送短信提醒;如果没有消息队列我们会选择同步调用发短信的接口并等待短信发送成功,正常情况下这么做是没有问题的但是如果发短信的时候短信接口出问题了或者说调用超时了等意外情况,这个时候我们就需要设计对应的方案来解决前提是这些方案的设计会比较复杂;

但是当我们使用消息队列以后这个事情就会变得非常简单,使用消息队列以后有如下好处:

① 实现了异步解耦

② 设计变的更加简单了

③ 保证了数据的最终一致性;

④ 提高效率;


二、消息队列特性

1 与业务无关 : 只做消息分发

2 FIFO : 先投递先到达

3 容灾 : 节点的动态增删和消息的持久化

4 性能 : 吞吐量提升,系统内部通信效率提高


三、为什么需要消息队列

生产和消费的速度或稳定性等因素不一致;


四、消息队列的好处

1 业务解耦

2 最终一致性 : 用记录和补偿的方式来处理,在做所有的不确定事情之前先记录然后再去做,它的结果通常分为三种成功失败或者不确定(比如说超时等);如果是成功我们就可以清楚掉记录,如果是失败或者不确定我们可以通过定时任务将所有事情重新做一遍直到成功为止;

3 广播 : 如果没有消息队列每一个新的业务方介入都需要联调一次接口,使用消息队列只需要关心消息是否送达到消息队列,新接入的接口订阅相关的消息自己做处理就可以了;

4 错峰与流控 : 上下游对于事情的处理是不同的,比如WEB前端每秒承受上千万的请求都是可以的但是数据库的处理却非常有限;迫于成本的压力我们不能要求数据库的机器数量与前端资源一样;这样的问题同样存在于系统与系统之间,比如短信系统的速度卡在网关上边它与前端的并发量不是一个数量级的,用户玩几秒种收到短信也是可以的;针对于这样的场景如果没有消息队列也能实现但是系统的复杂度非常的高;


五、常用的消息队列介绍

① Kafka

Kafka是Apache下的一个子项目,是一个高性能 跨语言 分布式发布订阅消息队列系统;

1 Kafka的特性

① 快速持久化 : 它可以在o1的系统开销下实现消息的持久化;

② 高吞吐 : 在一台普通的服务器上就可以达到10w/秒的吞吐速率;

③ 天生的分布式 : 所有组件天生支持分布式且自动实现负载均衡;

2 Kafka基础定义

① Broker : Kafka集群包含一个或多个服务器,这个服务器就被称为Producer;

② Topic : 指每条发布到Kafka的消息都有一个类别,这个类别叫做Topic;物理上不同Topic的消息是分开存储的,逻辑上一个Topic消息虽然保存在一个或者多Producer上但是用户只需指定消息的Topic就可以生产或者消费数据而不用关心数据存在哪里;

③ Partition : 是物理上的概念,每个Topic包含一个或者多个Partition;

④ Producer : 负责发布消息到Kafka的Broker里边;

⑤ consumer : 消息消费者,向Kafka broker读取消息的客户端;

⑥ Consumer Group : 每个Consumer属于一个特定的Consumer Group(可为每个Consumer指定group name,若不指定group name则属于默认的group);

② RabbitMQ

RabbitMQ是流行的开源消息队列系统,用erlang语言开发。RabbitMQ是AMQP(高级消息队列协议)的标准实现;

1 RabbitMQ的使用过程

(1)客户端连接到消息队列服务器,打开一个channel。

(2)客户端声明一个exchange,并设置相关属性。

(3)客户端声明一个queue,并设置相关属性。

(4)客户端使用routing key,在exchange和queue之间建立好绑定关系。

(5)客户端投递消息到exchange。

2 RabbitMQ的概念

Broker:简单来说就是消息队列服务器实体。

Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列。

Queue:消息队列载体,每个消息都会被投入到一个或多个队列。

Binding:绑定,它的作用就是把exchange和queue按照路由规则绑定起来。

Routing Key:路由关键字,exchange根据这个关键字进行消息投递。

vhost:虚拟主机,一个broker里可以开设多个vhost,用作不同用户的权限分离。

producer:消息生产者,就是投递消息的程序。

consumer:消息消费者,就是接受消息的程序。

channel:消息通道,在客户端的每个连接里,可建立多个channel,每个channel代表一个会话任务。

原文地址:https://www.cnblogs.com/shamo89/p/10020304.html

时间: 2024-11-06 03:34:37

高并发处理思路与手段(三):消息队列的相关文章

高并发处理思路与手段(四):应用拆分

比如一个股票系统有用户信息.开户.股票行情.交易.订单等,拆分后如下图所示: 原则 业务优先 每个系统都会有多个模块,每个模块又有多个业务功能:按照业务边界进行切割,再对模块进行拆分. 循序渐进 边拆分边测试,保证系统的正常运行. 兼顾技术:重构.分层 不能为了分布式而分布式,拆分过程不仅是业务梳理也是代码重构的过程,根据技术进行分层来分配工作,ui对用户体验,熟悉C和C++对服务器,熟悉数据库的对数据库,做到术业有专攻,合适的人去做合适的事情. 可靠测试 测试完毕后,才可进行下一步,每一步都要

高并发处理思路与手段(一):扩容

当一个开发人员提升计算机系统负荷时,通常会考虑两种方式垂直扩展和水平扩展.选用哪种策略主要依赖于要解决的问题以及系统资源的限制.在这篇文章中我们将讲述这两种策略并讨论每种策越的优缺点.如果你已经有一个软件系统需要不断成长,那么你将有意或者无意中选择这两种策略中的一种. 垂直扩展 在垂直扩展模型中,想要增加系统负荷就意味着要在系统现有的部件上下工夫,即通过提高系统部件的能力来实现.例如,假设你现在负责一批木材采伐的操作. 在这个例子中,我们假设有3辆卡车,每辆车一次可以运25根木材,计算花费1小时

高并发处理思路与手段(五):应用限流

限流就是通过对并发访问/请求进行限速或一个时间窗口内的请求进行限速,从而达到保护系统的目的.一般系统可以通过压测来预估能处理的峰值,一旦达到设定的峰值阀值,则可以拒绝服务(定向错误页或告知资源没有了).排队或等待(例如:秒杀.评论.下单).降级(返回默认数据). 限流不能乱用,否则正常流量会出现一些奇怪的问题,从而导致用户抱怨. 假设有130W到140W的数据插入到数据库中,如果没有做限流,数据库的主库会突然接收到130w的插入操作. 首先是网络上的开销,很可能直接把带宽占满,导致其他请求无法正

redis消息队列简单应用

参考 https://blog.yxccan.cn/blog/detail/3 一.什么是消息队列 是一个消息的链表,是一个异步处理的数据处理引擎. PS:可以理解为在redis的list列表中存放消息数据,然后按照排队方式先进先出(左进右出:右进左出) 二.可以使用的应用场景 主要应用一些延迟或异步操作的场景比如:发送邮件.发送短信.视频转码.图片转码.日志存储.导入数据等在发送邮件或者短信,我们不希望程序一直停留,等待发送成功才相应,而是异步进行处理,即:将待发送的邮件数据添加到消息队列中,

系统学习消息队列分享(二) 为什么需要消息队列?

消息队列是最古老的中间件之一,从系统之间有通信需求开始,就自然产生了消息队列.但是给消息队列下一个准确的定义却不太容易.我们知道,消息队列的主要功能就是收发消息,但是它的作用不仅仅只是解决应用之间的通信问题这么简单. 我们举个例子说明一下消息队列的作用.话说小袁是一家巧克力作坊的老板,生产出美味的巧克力需要三道工序:首先将可可豆磨成可可粉,然后将可可粉加热并加入糖变成巧克力浆,最后将巧克力浆灌入模具,撒上坚果碎,冷却后就是成品巧克力了. 最开始的时候,每次研磨出一桶可可粉后,工人就会把这桶可可粉

想使用消息队列,先考虑下这些问题

消息队列优势 消息队列(Message Queue,简称MQ),其主要用于在复杂的微服务系统中进行消息通信,它的优点可以大致整理成以下几点: 服务间解耦 提高服务并发.性能 突发流量削峰 ... 服务间解耦 微服务系统业务之间相互依赖,各种调用错综复杂,如果不能良好对服务进行解耦那一个服务的可用性.并发都会受到其他服务的影响. 在没有引用MQ的之前服务调用大概是这些步骤: 图上的A服务是直接调用的,这是没啥问题的,但是服务上线后要迭代更新的麻,这个时候要是服务C的开发人员有点代码小洁癖说:我这个

去哪儿网可用 消息队列

<去哪儿网技术专场>之 主题一:<去哪儿网可用 高性能 消息队列> 简介: 消息队列一般应用在广播通知.异步操作.数据复制. 为什么我们不用开源的消息队列? 我们开发的消息队列如何实现 “高可用”? 我们开发的消息队列如何实现 “高性能”?

进程间通信(IPC)之————消息队列

一.消息队列 前面提到的进程间通信的一种最基本的方式就是管道,而现在来谈一下另一种进程间的通信方式--消息队列.消息队列是从一个进程向另一个进程发送数据块的方式,每个数据块都有其类型,接收者接收的数据块也可以有不同的类型,这样我们就可以通过发送消息的方式来避免命名管道的同步和阻塞问题. 消息队列不同于管道的是,管道是基于字节流的,而消息队列是基于消息的,而且消息队列的读取方式不一定是先进先出的,消息队列是用链表实现的:但相同的是,它们有一样的不足,就是都有固定的大小,每个消息的大小都有上限(ms

消息队列一

参考页面: http://www.yuanjiaocheng.net/webapi/first.html http://www.yuanjiaocheng.net/entity/entitytypes.html http://www.yuanjiaocheng.net/entity/entity-relations.html http://www.yuanjiaocheng.net/entity/entity-lifecycle.html http://www.yuanjiaocheng.net