之前做过保险项目的一个秒杀活动平台，当时做过秒杀系统的架构，所以也来谈谈秒杀系统架构。秒杀系统主要两大块，一块是订单一块是支付，我们将订单库存存放在Redis里面，有请求过来，判断Redis是否有库存，如果有则生成订单，秒杀库存减1，然后生成的订单进入消息队列之中，进入以后就算是抢购成功了，直接反馈给前端用户，表示抢购成功。
这时候唤起支付页面，库存DB慢慢消费消息队列中的订单，扣减实际库存。支付定义为15分钟，15分钟不支持则标为支付失败，取消支付的订单也为支付失败，支付失败的订单反馈给订单服务，订单服务再退回库存DB。扣除库存主流两种方式，一种是支付扣除、一种是下单扣除，因为我们秒杀压力比较大，所以我们是下单扣除的方式，而且我们活动有多轮，秒杀结束以后后面还会有，所以库存退回捡漏是容许的。
这里面无论是支付服务还是订单服务都要加事物锁，以（用户+接口名）为唯一标示，所有请求只能生成一个事物，防止幂等性问题，同时redis库存数据使用悲观锁。
除此以外，很多保证秒杀的技术细节，例如CDN、断路器等等，这里就不具体列举了，根据不同场景去处理。
