SpringBoot整合RabbitMQ之典型应用场景实战二

实战前言
RabbitMQ 作为目前应用相当广泛的消息中间件，在企业级应用、微服务应用中充当着重要的角色。特别是在一些典型的应用场景以及业务模块中具有重要的作用，比如业务服务模块解耦、异步通信、高并发限流、超时业务、数据延迟处理等。上篇博文我介绍分享了RabbitMQ在业务服务模块异步解耦以及通信的实战业务场景，感兴趣童鞋可以前往阅读：https://www.roncoo.com/article/detail/134309

这边博文我们继续介绍分享RabbitMQ消息确认机制以及并发量的配置，并介绍分享其在高并发系统场景下的实战！

RabbitMQ 实战：并发量配置与消息确认机制

实战背景
对于消息模型中的 listener 而言，默认情况下是“单消费实例”的配置，即“一个 listener 对应一个消费者”，这种配置对于上面所讲的“异步记录用户操作日志”、“异步发送邮件”等并发量不高的场景下是适用的。但是在对于秒杀系统、商城抢单等场景下可能会显得很吃力！
我们都知道，秒杀系统跟商城抢单均有一个共同的明显的特征，即在某个时刻会有成百上千万的请求到达我们的接口，即瞬间这股巨大的流量将涌入我们的系统，我们可以采用下面一图来大致体现这一现象：

当到了“开始秒杀”、“开始抢单”的时刻，此时系统可能会出现这样的几种现象：

应用系统配置承载不了这股瞬间流量，导致系统直接挂掉，即传说中的“宕机”现象；
接口逻辑没有考虑并发情况，数据库读写锁发生冲突，导致最终处理结果跟理论上的结果数据不一致（如商品存库量只有 100，但是高并发情况下，实际表记录的抢到的用户记录数据量却远远大于 100）；
应用占据服务器的资源直接飙高，如 CPU、内存、宽带等瞬间直接飙升，导致同库同表甚至可能同 host 的其他服务或者系统出现卡顿或者挂掉的现象；

于是乎，我们需要寻找解决方案&#