秒杀系统每秒上万订单请求，我们是这么去设计的

前面连续好几天的时间都在讲怎么去提升我们系统的性能，将数据库改造成分布式存储，同时还讲到了各种缓存的原理以及我们生产中使用的技巧，其实都是因为我们的业务绝大部分都是读多写少的场景。

比如，微博中肯定是发微博的用户比看微博的人要少很多很多。这个时候，对于系统而言，整体流量就会不太大，而写流量很可能只占到总体的 1% 。这样的话，即使我们系统 QPS 达到了 10000次/s ，那写请求每秒也只有100 次，所以花大的精力去优化写请求是没有必要的，对于业务并没有什么影响。

但是，如果是对于突如其来的超大流量，可能就会出现高并发的写请求的场景，例如最经典的秒杀场景。如果我们的商城在双十二零点要搞一个秒杀活动，限制前 200 个用户，那么在秒杀活动即将开始之前，就会有很多的用户疯狂的去刷新APP或者浏览器，为了就是不错过这次秒杀。

在这个时候，我们系统面临着的依旧是大量的读请求，那我们应该怎么去应对呢？

因为这个秒杀场景中，用户查询的是少量的商品，属于查询热点数据，我们就可以采用缓存策略啊，将用户请求放在服务之外，或者是将静态资源放CDN等等，这些方案之前都教给大家了，自行查看哈，比如（你一定要掌握这种缓存读写策略，开发必备，CDN加速技术，作为开发的我们真的不需要懂吗？）

当秒杀活动在零点准时开始之后 ，就会有大量的用户瞬时向我们商城系统提交订单，扣减库存，这个时候用户的这一操作是不经过缓存的，而是直接落到数据库中的。1 秒内，会有 1 万个数据库连接产生，这个时候数据库就会很快崩溃，那我们该怎么办呢？一般这里我们会使用一个组件那就是消息队列。

 

消息队列是什么

消息队列的概念以及有什么作用，前面有讲到相关中间件的时候提到过（