消息队列使用场景

消息队列使用场景

1、异步处理：

　　减少等待时间，更快的返回处理结果，提高系统性能以及更好的用户体验。

　　fe: 在一个秒杀系统中，可能需要如下几步：风险控制，锁定库存，生成订单，消息通知以及统计数据，在未优化的情况下，用户请求到达网关后进入服务端要至少

经历这五个步骤，但是对于秒杀系统而言关键的步骤在于风险控制和锁定库存 后用户的秒杀已经完成，所以后续的生成订单，消息通知，统计数据，这些不影响主要业务

流程的操作我们可以采用异步的方式，来更快的处理用户请求，从而也是服务器端可以更多的处理秒杀请求。

 

2、流量控制（削峰填谷）：

　　当海量请求到服务器端时会压垮服务器，所以此时可以使用消息队列。

　　fe：首先流程是这样的：请求->网关->服务端，当海量请求达到网关（软硬件负载均衡：软件负载均衡nginx,支持十万级并发；硬件负载均衡f5，支持百万级并发）后，

所有的请求到达服务端，会压垮服务端，所以在网关和服务器端加一中间过程：消息队列。所有请求入队列，此时不需要担心 消息队列的存储能力，当硬盘容量足够时，可

无限存储，之后服务器端根据自己的消费能力去消息队列中获取请求进行处理，达到保护后台服务的作用。

　　fe:流量控制可以采用令牌桶的形式，有令牌生成器，根据规定流量生成指定数量令牌，服务器端获取请求时，首先获取令牌，拿到令牌后放开处理请求，没有令牌则

不能进行请求处理

　　当然在做优化时也会有相应代价：调用链增长，增加响应时间；同步请求改为异步请求，增加了系统的复杂度。 凡是有利便有弊，权衡项目所需。

 

3、服务解耦

　　在当下微服务横行的时代，脱离的单体应用，一个项目会根据不同的粒度拆分为几十个甚至几百个项目，当从几个到几十个再到几百个时复杂度是以直线上升的，各系统之间

的互相调用，在系统类图中可以看见密密麻麻的连线，项目耦合在一起，所以此时可以使用消息队列进行解耦。而且当下游服务发生变化时，所有调用的上游服务都会发生变化，这个是

不允许的，所以在应用过程中，可以采用消息队列

 

4、分布式事务

　　通过消息中间件，来保证分布式事物的最终一致性。这是一种比较提倡的解决方案，有利于服务之间解耦，虽然是异步的，但基本上事物也是即时性的。

　　fe:将业务A的提交操作和发送消息的记录 写在同一个事物中(把消息发送记录在本地库中)，然后业务B接收到消息之后进行相应的操作，成功后，向A发送成功通知。失败则通知A，进行回滚。 当A中的消息发送不成功的时候，则会通过定时任务轮训来进行发送，从而保证消息最终肯定可以到达B。 但是当A接收到B的成功通知后 应该删除消息记录或者修改记录状态，但是突然A挂掉了，A就没有及时修改本地消息记录，导致定时轮训的时候会重发，如果此时B中业务不是幂等的则会出现问题，所以如何避免这种消息重发呢？  在B方也对消息进行记录，当A中发送过来消息后，B判断消息是否执行过，来避免这种问题

　　

 

 5、发布/订阅者模式