亲宝软件园·资讯

展开

消息队列全面了解(一)

萌萌丶小魔王 人气:2

关于消息队列,我们来思考这么几个问题:

1、MQ为什么再系统中使用?一定要在分布式系统中使用吗?

2、MQ有哪些中间件?他们有哪些特点?

3、MQ给系统带来好处的同时有没有带来什么问题?如何解决?

一般在我们面试的时候,面试官一般会问如下问题:

1、你的项目中MQ的作用?

2、为什么选择这款MQ作为消息中间件?

3、重复消费怎么办?

4、如何确保消息被消费?

那么接下来,带着这些问题我来给大家一起分享一些关于MQ的知识。

一、消息中间件在系统中的作用

MQ在系统中到底有哪些作用呢?抛开基本的消息发布订阅不说,还有以下几点:

1、分布式系统解耦

2、不需要立即返回的业务异步处理

3、削峰填谷,不直接访问服务,缓解服务压力,增加性能

4、日志记录

分布式系统解耦:

 

 

 在分布式系统中,要么是通过rest调用,要么是通过dubbo等RPC调用,但是有些场景需要解耦设计,不能直接调用,比如消息驱动的系统中,消息发送者完成本地业务,发送消息,多平台的消息消费者服务需要收到推送的消息,然后继续处理其他业务。

看这两个架构图,第一种BC都是直接依赖A服务,那么如果A中的接口修改,BC都要跟着做修改,耦合度高,第二种,通过MQ来作为中间件接收消息,BC只依赖收到的消息而不是具体的接口,这样即使A服务修改或者增加其他服务,都只要订阅MQ就行。

不要求实时的业务异步处理

以用户注册业务流程为例:

1、用户注册入库

2、用户验证邮件发送

3、用户验证短信发送

原来的系统设计,这样的服务流程会串行处理,即先1-2-3,但是这里可以思考一下,如果单个服务单台机器的情况下,注册用户特别多,系统能不能抗住?

这里假设哥哥阶段的时间1=50ms,2=50ms,3=50ms,那么一个请求下来all=150ms,这个再假设,这个服务器CPU=1,且只能处理单线程,那么以这种单台服务器单线程的QPS来算,QPS=1000/150≈7现在我让这个QPS*3,提升三陪,这个时候引入MQ服务作为中间 如图可见,我在A服务用户组测完成后,就直接返回了,这个时候,MQ用来发送异步处理消息,B、C服务分别处理,A不用等待B、C的返回结果,这样用户体验就是只有50ms等待时间,而再邮件、短息这个阶段,因为网络延迟原因,用户可以接收一定时间的等待。

削峰填谷

一般的服务,我们的请求访问系统都是直接请求,这样的模式再用户访问量不大的情况下,问题不是很大,但是如果用户请求打到了一定的瓶颈或者产生了一些问题,我们就需要考虑优化我们的系统架构,MQ中间件正式解决办法之一。

下面以秒杀系统为例分析问题,秒杀系统瞬间百万并发,怎么处理?一般秒杀系统会进行请求过滤,无效、重复都会被过滤一遍,剩下的才真正进入到秒杀服务、订单服务。但即使这样并发仍然很高,如果网关把全部请求都转发到下优订单服务,一样会压垮下游系统,造成服务不可用甚至雪崩

 

 

 

 

 

 真实的秒杀系统更复杂,包含Nginx、网关、注册中心、redis缓存、数据库集群、消息队列集群

解决方式就是将上游处理的较快的任务,加入到队列处理,下游逐一消费队列。直到所有队列消费完成。加入秒杀服务处理请求数:1000/s,下游订单服务处理请求为:10/s,为了不给下游订单服务造成压力,秒杀后的信息发送到队列,订单服务就可以从容淡定的10/s的速度来逐个处理了,而不是直接塞1000哥请求,也不管人家愿不愿意。

到这里,可以总结下秒杀系统的过滤方式:

1、页面按钮点击一次置灰

2、每秒通过请求数限制,例如100/s,可以使用Nginx,sentinel

3、过滤同一用户的重复请求,通过用户唯一标识,商品信息。

4、通过消息队列储存成功的秒杀信息,下游订单系统处理

日志

所有服务都将日期发送到MQ服务用来作为日志存储,MQ作为中间件对日志进行持久化、转发、大数据服务对MQ读取和进行日志分析。

二、 MQ怎么选

有人上来就是一通性能比较,然后说RabbitMQ是世界上最好的MQ,你把挑选MQ比作挑老婆吧,上来就要全套,肤白貌美、前凸后翘、性感火辣、勤劳能干……真是缺乏社会的教育啊,兄弟,养的起来吗?动不动一套保养套餐,1W/月守得住吗?隔壁老王经常来你家吃饭吧,吃得消吗?红枣+枸杞+补肾片,怕是心有余而力不足吧。

言归正传,其实我觉得这是一个思考题,首先我们要看的应该是条件是哪些?

1、用途?用来做日志、解耦、还是异步处理

2、公司情况?人员是否充足,现有人员技术栈情况、人员的技术栈实力

3、项目情况?项目周期、人员、用户量、架构设计、是否老项目

4、主流MQ现状?稳定可靠度、社区活跃度、文档全面性、云服务支持情况

上图的例子日志消息就是用的kafka,为什么是kafka?kafka是LinkedIn开源的分布式发布-订阅消息系统,属于Apache顶级项目,社区活越。kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,后来版本升级开始支持复制,不支持事务,对消息的重复、丢失、错误没有严格要求,适合产生大量数据的互联网服务的数据收集业务。但是kafka相对来说很重要,需要依赖zookeeper,大公司里使用没有问题,也少不了专人维护。

RocketMQ是案里开源的一套可靠消息系统,已经捐赠Apache为顶级项目。刚开始定位于非日志的可靠消息传输,其实再日志处理方面性能也不错。目前支持的客户端包括java、c++、go,社区比较活越,文档还算全面,但是涉及到核心的要修改还是有难度的,毕竟阿里云靠买这个服务赚钱呢。所以如果公司实例不自信还是慎重选择吧,实在不行可以直接购买云服务,省心省力,还是那句话,看实际情况。

三、主流MQ的特点:

四、如何确保消息不被重复消费

这里简单说说,后面有时间我会就这个问题详细说明。大致就是一些特殊原因例如网络原因,服务重启造成消息消费未被记录,造成重复消费的可能,一般的处理方式就是确保接口设计的幂等性,主旨通过唯一标识判断是否存在。

1、redis缓存使用,唯一性token保存redis,每次消费后删除token

2、唯一主键判断,数据库判断是否存在该逐渐记录,存在则更新,不存在则插入

加载全部内容

相关教程
猜你喜欢
用户评论