聊聊mq的使用场景

  

mq的作用

  
      <李>通过异步方式对系统解耦李   <李>增加系统的并发处理能力李   
  

通过异步方式对系统解耦

  

<强>以用户注册为例,一般情况下:
聊聊mq的使用场景

  

<>强分下一下,上面过程存在的一些问题:

  
      <李>注册过程会调用4个服务(注册服务,邮件服务,短信服务,积分服务),服务之间依赖性太强,任何一个服务不可用,直接影响整个注册业务李   <李>接口耗时太长,每个服务耗时100 ms,注册流程耗时400 ms李   <李>对用户来说,用户信息入库是主要的业务流程,其他并不是响应用户过程中直接关注的逻辑,可以异步进行处理李   
  

<>强采用mq的方式实现:
聊聊mq的使用场景

  

<>强过程:

  
      <李>调用注册服务,注册信息入库,耗时100 ms李   <李>投递注册消息到mq李   <李>返回注册成功李   <李>对于用户来说耗时200 ms李   <李>其他3个操作(发邮件,发短信,增加积分)从消息队列中拉取消息进行处理,对于主流程来说是异步操作李   
  

将依赖于3个服务转换为只依赖于mq服务,只需要保证注册服务,mq服务高可用,即可以保证注册服务的高可用,相比保证其他3个服务高可用上容易了许多。

  

增加系统的并发处理能力

  

以电商中的秒杀场景为例,采用同步处理:

  
      <李>用户点击秒杀李   <李>调用订单服务,验证库存,锁定库存李   <李>跳转到支付页面进行支付李   
  

<>强分析一下,存在的问题:

  
      <李>验证库存,锁定库存会访问数据库李   <李>   

    秒杀场景,商品数量有限,请求量非常大,每个请求来了都做以上处理,直接会把数据库压垮,导致数据库无法对外提供服务,数据库的不可用直接导致整个业务的不可用,秒杀活动打水漂。

      李   <李>大量请求会同时到达,同时去访问数据库,数据库连接有限,导致很多请求会处于等待状态,导致并发性能急剧下降李   <李>大量用户同时操作库存,存在争抢数据库锁的情况,容易导致死锁李   <李>秒杀中数量一般是有限,大量用户抢购,其实最终只有很少的用户能够抢购到李   
  

大家都有在银行办理业务的经验,银行处理业务的流程:<强>领号,排的队,等待叫号办理业务

  

<强>秒杀中我们也可以参考银行办理业务的流程:

  
      <李>用户点击描述李   <李>系统接受到用户请求后,生成一个唯一的编号,然后投递一条消息(秒杀下单)到mq李   <李>响应用户:秒杀正在处理中李   <李>秒杀系统从mq中拉取消息进行处理,处理完成之后告知用户,这步操作对于用户来说是异步处理的过程李   
  

从上面可以看的出,从接受用户请求到响应用户请求,未访问数据库,只有生成编号和发送消息的操作,这部分处理速度是非常快的,不存在性能的问题,数据库也不存在压力的问题了,所有用户的请求都被作为一条消息投递到mq进行异步处理,从而解决了秒杀中同步处理遇到的各种问题。

  

<强>其他一些使用场景

  
      <李>系统日志的处理
    系统手机日志,异步发送到mq,日志服务队从mq中拉取消息进行各种处理,关于这个以后我们会专门讨论。   <李>通过事件驱动的一些业务,也可以使用mq实现李   
  

总结

  
      <李> mq是采用<强>异步的方式来强解决系统耦合性的问题,并发处理的问题;重点是在于<强>异步强,那么什么情况下使用异步呢?当调用方不强依赖于被调用方的结果的时候,可以采用异步的方式进行处理,此时可以使用mq。   <李>当调用方强依赖于被调用方的结果的时候,需要使用同步的方式,不能使用mq李   
  

<强> mq系列整个内容,我们将讨论:

  
      <李> mq的使用场景李   <李>业务系统中投递消息的几种方式?李   <李>如何确保投递消息一定成功?李   <李>消息消费的几种方式李   <李>如何确保消息至少消费一次李   <李>如何保证消息消费的幂等性李   

    聊聊mq的使用场景