MQ简介
-
<李>
什么是MQ
跨进程的消息队列,主要角色包括生产者与消费者。
生产者只负责生产信息,无法感知消费者是谁,消息怎么处理,处理结果是什么。
消费者负责接收及处理消息,无法感知生产者是谁,怎么产生的。
Mq能做什么?
Mq特性一般有异步,吞吐量大,延时低;
适合做:
-
<李>投递异步通知。
<李>限流,削峰谷。
<李>可靠事件,处理数据一致性。
<李>利用一些特性,可以做定时任务。
等…。
由于MQ是异步处理消息的,所以MQ不适合做同步处理操作,如果需要及时的返回处理结果请不要用MQ;
-
<李>
MQ个系统带来了什么?
缺点:增加了系统的复杂性,除了代码组件接入以外还需要考虑,高可用,集群,消息的可靠性等问题!
生产者:消息发送怎么保证可靠性,怎么保证不重复!
消费者:怎么保证幂等性,接收到重复消息怎么处理!
还有会带来的处理延时等问题!
李优点:解耦,利用MQ我们可以很好的给我们系统解耦,特别是分布式/微服系统。
原来的同步操作,可以用异步处理,也可以带来更快的响应速度;
-
<李>哪些场景可以使用MQ李
<>强场景(1)
系统解耦,用户系统或者其他系统需要发送短信可以通过MQ执行;很好的将用户系统和短信系统进行解耦;
<>强场景(2)
顺序执行的任务场景,假设A B C三个任务,B需要等待一个完成才去执行,C需要等待B完成才去执行;
我见过一些同学的做法是,用三个定时器错开时间去执行的,假设一个定时器9点执行,B定时器10点执行,C 11点执行,类似这样子;
这样做其实是不安全的,因为后一个任务无法知道前一个任务是否真的执行了!假设一个宕机了,到10点B定时去执行,这时候数据就会产生异常!
当我们引入MQ后可以这么做,一个执行完了发送消息给B, B收到消息后执行,C类似,收到B消息后执行;
<>强场景(3)
支付网关的通知,我们的系统常常需要接入支付功能,微信或者支付宝通常会以回调的形式通知我们系统支付结果。
我们可以将我们的支付网关独立出来,通过MQ通知我们业务系统进行处理,这样处理有利于系统的解耦和扩展!
假设我们还有一个积分系统,用户支付成功,给用户添加积分。只需要积分系统监听这个消息,并处理积分就好,无需去修改再去修改网关层代码!
如果没有使用MQ,我是不是还得去修改网关系统的代码,远程调用增加积分的接口?
这就是使用了MQ的好处,解耦和扩展!
当然我们的转发规则也要保证每个感兴趣的队列能获取到消息!
<>强场景(4)
微服/分布式系统,分布式事务——最终一致性处理方案!
详情:分布式事务处理方案,微服事务处理方案
<>强场景(5)
-
<李>消息延时队列,可做些定时任务,不固定时间执行的定时任务。
<李>例如:用户下单后如果24小时未支付订单取消;李
<李>确认收货后2天后没有评价自动好评;
等…
我们以前的做法是通常启用一个定时器,每分钟或者每小时,去跑一次取出需要处理的订单或其他数据进行处理。
这种做法一个是效率比较低,如果数据量大的话,每次都要扫库,非常要命!
再者时效性不是很高,最差的时候可能需要等待一轮时长!
还有可能出现重复执行的结果,时效和轮询的频率难以平衡!
利用MQ (Rabbitmq) DLX(死信交流)和消息的TTL (time - to - live扩展)特性。我们可以高效的完成这个任务场景!不需要扫库,时效性更好!
DLX: http://www.rabbitmq.com/dlx.html
TTL: http://www.rabbitmq.com/ttl.html per-message-ttl
原理:
发送到队列的消息,可以设置一个存活时间TTL,在存活时间内没有被消费,可以设置这个消息转发到其他队列里面去,然后我们从这个其他队列里面消费执行我们的任务,这样就可以达到一个消息延时的效果!
