消息中间件的应用场景

发表于 | 分类于

前言

简单的记录一下消息中间件的一些应用场景。

通过异步处理提高系统性能

你想输入的替代文字

如上图，在不使用消息队列服务器的时候，用户的请求数据直接写入数据库，在高并发的情况下数据库压力剧增，使得响应速度变慢。

但是在使用消息队列之后，用户的请求数据发送给消息队列之后立即 返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理速度快于数据库（消息队列也比数据库有更好的伸缩性），因此响应速度得到大幅改善。

但是如果后面写入出现错误怎么办？？！前面已经回应了用户，这个时候如何保证消息与业务操作一致，不丢失？！？

首先用户是在消息队列写入成功后得到的响应，所以只要保证写入消息队列中的消息能被成功消费即可。所以如果出列的消息执行失败是不会失效或者消失的。主流的MQ产品都具有持久化消息的功能。如果消费者宕机或者消费失败，都可以执行重试机制的。

应用解耦

简单来讲就是如果下单的操作，涉及到订单入库、商家发货等业务。一般的情况就是如下：

1
2
3
4
public void Order(){
	insertOrderDB(); //订单入库
    remindDelivery(); //商家发货
}

但是如果有新的业务逻辑，希望下单的时候再添加一个用户积分的操作，情况就如下：

1
2
3
4
5
public void Order(){
	insertOrderDB(); //订单入库
    remindDelivery(); //商家发货
    integralPro(); //积分操作
}

每单有新的业务都要改变代码，对代码侵入太大。而且每个服务的耦合度太高，如果上面商家发货出现错误，会导致程序终止，积分操作执行失败。

引入消息中间件之后，对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。

1
2
3
4
public void Order(){
	insertOrderDB(); //订单入库
    insertMQ(); //写入消息队列中，对该订单有涉及的业务直接去获取消息队列
}

流量削峰

你想输入的替代文字

场景:秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用前端加入消息队列。

  1. 可以控制活动人数，超过此一定阀值的订单直接丢弃

  2. 可以缓解短时间的高流量压垮应用(应用程序按自己的最大处理能力获取订单)

    1.用户的请求,服务器收到之后,首先写入消息队列,加入消息队列长度超过最大值,则直接抛弃用户请求或跳转到错误页面.

    2.秒杀业务根据消息队列中的请求信息，再做后续处理.