消息队列MQ ，本质是个队列，其最简单的操作就是入队和出队，既按照程序决定何时何条件入队，和何时何条件出队。也就是说，遇到入队系统和出队系统的业务诉求不一致时的场景，就可以考虑是否用消息队列来实现了。可应用场景有很多，以下是几个常见的场景和解释。

场景：主业务对子业务的处理结果并不关心时。

案例：电商系统中订单系统、物流系统、财务系统以及操作日志记录系统之间的关系。

通俗解释：小明是个蛋糕店员。他做好蛋糕后，放在橱窗中，在对应订单上标记『已完成』，然后继续做下一个蛋糕，并不关心蛋糕后续是怎么卖出的，也不关心啥时候卖出。
实现：使用一个队列的中间件或者中间系统来存放几个业务系统的共用部分，并独立进行处理。可以使用每个系统各自的独立标记，对各系统的处理进度进行记录。在所有系统均完成操作后，进行出队操作，或者持久化存储数据。

注意点：需要考虑中间数据的容灾能力，当故障发生并恢复时，保证业务流程可以恢复。保证每条数据都可以正确地完成处理。

场景：流量在各个时间点不均衡

案例：秒杀、抢购

解释：小明制作蛋糕的时间比较长，订单来到后先登记成一个清单，然后逐次按顺序制作，订单量过大时，会暂时挂出『已售完』的牌子。

实现： 使用单线程的工具将业务需求进行排队处理。当业务请求达到阀值时，给出友好提示并拒绝用户的需求。

注意点：对于消峰需求，可以高峰期挂出『暂时无法购买，请稍等』等提示，防止流量对后续业务的冲击。对于秒杀等抢完即停的需求，需要考虑超发问题，可以添加一个名额计数器，或者在秒杀名额已满员时，发放一个秒杀完成标记，后续处理程序检测到完成标记后，再进行后续处理。

场景：内容需要逐条严格执行，并保证执行成功，执行不成功或者中断时，可以恢复

案例：银行、财务类系统，需提升容灾能力的系统

解释：小明制作的蛋糕需要客户验货签收后，才可以继续制作下一个蛋糕。

实现：入队系统将业务需求写入消息队列后，即进行下一次业务处理。后续处理程序对队列内容进行逐条处理，处理完成后发放『完成许可』。消息队列中的内容，只有取得『完成许可』后，才可以从消息队列中删除。

注意点：重点考虑容灾相关问题，如业务恢复问题、重复处理问题。

场景：消息队列中的内容有严格的顺序。

案例：抢号排队等系统

解释：小明制作蛋糕的顺序需要严格按下单顺序来制作。

实现：入队系统将内容逐条写入消息队列，并按单线排列，按先进先出的顺序来提出数据并进行后续处理。

注意点：需要使用单线程，保证只有一条生产线。

场景：采用发布-订阅模式时，添加新的订阅者
案例：注册用户后，发送成功短信的模型中，追加一个发送email的功能
实现： 由多个消费者订阅一个消息的中间层，然后发布者将信息发布到中间层中。 订阅了这个中间层的消费者均可以收到这个消息，并进行后续处理。在这个结构中。如果想添加一个消息的后续处理组件 ，只需要将这个组件订阅到中间层即可
注意点：保证业务之间没有深度耦合，防止扩展时造成干扰。

以上就是消息队列比较常用的几种场景，消息队列可以平覆系统之间的差异，提高系统稳定性，适用场景还有很多。

在消息队列介质选择时，建议同学们不用在一开始就一定要将条件和目标最大化，一定要以什么样的条件完善完美的解决问题，程序还是需要一个长久维护与优化的过程。

虽然Redis在高流量且需要大量持久化数据等情况下，性能下降还是很严重的，但是还是建议大家从Redis来学习队列，在课程中仅是通过改流程理解队列的应用场景和思路，任何线上项目都是不断优化与完善的，如果想通过一套视频完善的解决所有的问题，对不起臣妾做不到，每个工作的需求和应用场景都不同所以在有不同需求时就根据具体需求进行完善。

在判断队列需求时候，需要判断队列条件应用时添加计数器字段在每次压入队列时判断当前队列的长度数量，如果数量超过限定的秒杀数量不在进入队列程序。

在实际使用时，并不需要刻意追求哪些地方需要添加消息队列。而应该按照实际情况，在进行业务分离和解耦合，以及一些特殊诉求时合理地选择和运用。

--- Wicon.Wang