1.前言
消息队列大家都知道，是分布式系统中十分重要的组件，其主要的使用场景，有如下5种：
- 解耦
- 异步处理
- 削锋
- 日志收集
- 事务最终一致性
我尝试用言简意赅的方式把这5种场景阐述清楚。
2.消息队列应用场景
2.1 解耦
应用解耦
应用解耦
如上图，我们知道，在实际操作中，每次一个订单系统对库存系统调用增删改查，都是以此sql操作，如果并发量大，那么响应的时间会急剧上升。这个时候，我们只需要中间加一个消息队列，对其进行解耦，一旦订单系统塞入消息队列的消息持久化成功，就即刻返回，库存系统可以随后以推/拉的方式对队列中的消息进行消费（ps：就是一个消费者，生产者模型）。
2.2 异步处理
很简单，拿上面解耦的图片，在订单系统塞入库存系统的过程中，可能还会经过其他部门的模块（因为别的部门可能需要相应的订单数据，比如下面说的日志模块，进行实时统计，比如大数据部拿到模块进行数据处理和分析等等）。如果以同步的方式，那么等待每个部门响应完，才能继续走下一步，就如同接力跑一样。其实这相关的数据其实就是一个通知，模块间也没有什么关系，改成异步可以加快数据消费速度。就如同100米跑时，裁判打枪，大家听到消息通知同时跑，可能有的人慢有的人快，表示有的机器or集群or模块处理的数据程度的快慢，但是这样肯定比n*100接力要快多了。
2.3 削锋
削锋
在互联网行业中，可能会在某一个小的特点的时刻，网站or服务器or集群会突然迎来用户请求高峰期的情况。在这种情况下，最简单粗暴的方式就是买来更多的服务器，进行削减来达到减少并发量的结果。但是这种special time很少出现，一般情况下买来的多余的服务器就是浪费资源了。就像之前微博一样，一个超大流量的热搜一来就挂了，然后租借阿里服务器来应付。因此常见的做法就是使用消息队列，先将短时间高并发的请求持久化，然后逐步处理，将这些消息慢慢吃掉。
2.4 日志收集
随着公司数据规模增大，日志这个非常重要的部分，其数据量也是随之而增长，为了应对写入日志时某些故障导致系统访问阻塞等，日志的收集系统就应运而生，如大数据中kafka+flume就是衍生出来的组件，可以做到离线和实时的日志统计。
2.5 事务最终一致性
以支付宝中的余额宝为例，我们知道支付宝中扣除钱，再把钱加到余额宝中，其实是两个事务，如果系统很小在同一个数据库中，这两个事务肯定好做，但是在分布式系统中，这两个事务就不好做了，还是举个例子：
比如在饭店吃饭，付了钱后，他们并不会直接把你点的菜给你，而是给你一张小票，然后让你拿着小票到出货区排队去取。为什么他们要将付钱和取货两个动作分开呢？原因很多，其中一个很重要的原因是为了使他们接待能力增强（并发量更高）。
只要这张小票在，你最终是能拿到菜的。同理转账服务也是如此，当支付宝账户扣除1万后，我们只要生成一个凭证（消息）即可，这个凭证（消息）上写着“让余额宝账户增加 1万”，只要这个凭证（消息）能可靠保存（即消息持久化），我们最终是可以拿着这个凭证（消息）让余额宝账户增加1万的，即我们能依靠这个凭证（消息）完成最终一致性。
当然，如果在你小票还没消费前，你反悔了（当然，餐馆不可能这么做），发送一个消息告诉我不想要菜了，那么这边就不会给你做菜，同理，当支付宝扣除1w后，如果出现各种原因，比如宕机，取消等，那么支付宝的钱回滚，余额宝的钱纹丝不动。
0.总结
其实说白了，不管是解耦（防止系统故障时长时间停顿从而改善系统的性能），还是异步（减少响应时间改善系统的性能），亦或是削锋（减少某时间高并发而导致系统雪崩从而改善系统的性能）等等，消息队列所做的就是改善系统的性能。
希望大家看了以后能有所收获，有问题也可以留言或私信，谢谢！
网友评论