目录
消息队列的作用
自从有了系统之间的通信就有了消息队列的概念，由此可见，消息对队列是最古老的中间件之一。
想给消息队列下个定义并不容易。顾名思义，它是用来发送消息的，当然不只是发送消息这么简单。
生产一块巧克力为例
- 研磨可可粉，
- 可可粉加热加入糖变成巧克力酱，倒入模具
- 冷却后取出就是巧克力了
为了增加生产效率，以上步骤可以分工制作，研磨的研磨，加糖加热的加糖加热，冷却的冷却。只要在中间用传送带连接，就是一个生产线。
把各个步骤比作一个系统，那么传送带就是中间件消息队列。
然而当研磨可可粉的人速度过快，加热加糖的人不能及时把可可粉消费完，那就需要这个传送带有缓存可可粉的功能这个功能叫做“流量控制”，
这样研磨可可粉的人在一定时间内都可以不间断的工作，并不关心加热加糖的人忙不忙的过来。这中模式叫做“异步处理”。
哪些问题适合使用消息队列来解决
1.异步处理
以秒杀系统为例：
秒杀系统需要解决的核心问题是，如何利用有限的系统资源来尽可能多的处理短时间内的海量请求。处理一个秒杀请求包括：
- 风险控制
- 库存锁定
- 生成订单
- 短信通知
- 更新系统数据
如果没有对这个功能进行优化，就像刚开始做巧克力的流程，一定是一个流程要依次经历每个步骤才能出成品。正如一个请求必须经过以上5个步骤才算是秒杀成功。但事实上只需要经历1，2两个步骤就算秒杀成功了。对于后续的三个步骤并不一定要在秒杀请求中完成。
所以我们可以在前两个步骤完成后就响应用户秒杀成功，将请求数据放入消息队列后，由消息队列异步的做后续操作
如此由之前的五个步骤优化成两个步骤，这样能更快的响应秒杀请求，而且可以将尽可能多的资源用在前两个步骤上面。
这个场景中，消息队列用于实现服务的异步处理。好处是：
- 可以更快的响应秒杀请求
- 自然实现了步骤之间的并发提升看系统的性能
2.流量控制
上面我们实现看了部分系统间的异步处理，但还有一个问题是必须要解决的，那就是：如何避免过多的请求压垮我们的系统？
一个成熟的系统，安全的系统可能是要考虑自我保护能力的，在能力范围内，尽可能多的处理请求，有拒绝处理不了请求的能力，这是终极目标。
说到这点，不得不吐槽国内某通信设备厂商。他们发售的手机是要用抢的，笔者层多次参与这种抢购活动，有几次尽然都生成订单了，付款的时候说我抢购不成功，别人把消费者当上帝，他们把消费者当屌丝，呵呵！
言归正传，为了设计有能力保护自身的健壮的系统，设计思路是用消息队列来隔离网关和后端服务，用来达到流量控制和保护后端服务的目的。
- 网关在收到请求后将消息放到消息队列
- 后端服务消费消息队列中的APP请求，完成后续步骤
短时间大量请求到达网关的时候不会直接冲击到后端服务而是压进消息队列，后端服务尽可能的多处理请求。对于超时的请求可以拒绝处理，直接丢弃。而且我们可以水平扩展后端服务，不需要对其他部分做修改，这样很大提高消费效率。
这样做的优点是：可以调节下游服务处理能力，达到“削峰填谷”之目的。
这样做的代价也是有的：增加了系统环节导致响应时间变长，异步调用增加了系统的复杂度
更简单的流量控制
预估出系统的处理能力，用消息队列实现一个令牌桶：
单位时间发固定个数的令牌到令牌桶，规定服务在处理请求之前必须先从令牌桶中拿到一个令牌如果令牌桶中没有令牌则拒绝请求保证单位时间内能处理的请求不超过发放的令牌数，起到了限制流量的目的。只需要在网关在处理请求的时候增加一个能获取令牌的逻辑。
令牌桶：固定容量的消息队列+令牌生成器
令牌生成器：匀速生成令牌放到令牌桶，如果令牌桶满了就丢弃令牌。
网关：在收到请求的时候去令牌桶消费一个令牌，去调用后端秒杀服务，如果获取不到令牌直接返回秒杀失败
3.服务解耦
消息队列实现了系统与系统之间的解耦。
拿订单系统来说，电商的订单系统下游系统越来越多而且不断变化的情况下，下游系统可能只需要订单数据的一个子集。这样订单系统对下游系统的接口可能就会需要不断进行修改来满足需求。没修改一次就意味着要重新上线一次。这是不可接受的。
所以引入了消息队列，订单变化后订单系统只需要将消息发送到队列中的一个主题Order中，下游订阅这个主题的系统都可以获取到一份“新鲜”的订单数据。这样订单系统就不会被下游系统所影响了。实现了解耦的目的。
总结
消息队列常用的三种场景：异步处理，流量控制，服务解耦
当然不只是这三种场景，还有：
- 作为发布/订阅系统实现一个微服务系统的观察者模式
- 连接流计算任务和数据
- 用于广播消息给大量接收者
当然也有局限性：
- 对消息进行了缓存，势必会延迟消息的传播
- 增加了系统的复杂度
- 可能产生数据不一致的问题（当然这不是消息队列本身的问题，而是设计者设计的问题）
扫一扫
824
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
