秒杀是电商系统中常见的业务，用于吸引用户，刺激留存及消费所做的一种活动。经典的秒杀包含限时秒杀和限量秒杀。很多公司有专门的秒杀系统。哪个业务要做活动，就来对接这个系统。
系统特点
1、瞬时流量极大，过了秒杀时间点流量结束。
2、秒杀商户库存极少，例如百万用户去抢2个iphone。
3、秒杀时间点没到的时候，刷新量大，静态资源访问量剧增。
一般流程
事前：运营侧建活动，并将秒杀数据、库存等信息写入缓存。技术侧预估资源等情况是否能支撑。
事中：秒杀快开始时，用户可能会疯狂刷新。开始后用户秒杀。
事后：履约。
映射到技术层面，有如下考虑点
1、高并发、快响应：除了秒杀开始后的流量激增，还要防止 机器人刷单、 页面访问量大和 秒杀前防止请求打到后端。
2、防超卖。
3、订单履约。
4、应急处理。
高并发、快响应
严格准入，比如手机验证、真人验证手段防止机器人刷单。
使用页面静态化、CDN加速、静态资源缓存及压缩对应 页面访问量大。
秒杀按钮置灰、秒杀真链接隐藏来防止 秒杀前请求打到后 端，同时也可以防止一些机器人、黄牛提前知道链接，使得真正的用户抢不到 。还可以针对同一用户、同一IP做限流，比如10QPS，这已经基本不是人可以做到的手速了。
对于 秒杀开始后的流量激增，首先要做好压测，找出薄弱点进行代码优化、服务支撑优化。如果公司支持弹性扩缩，要提前测试。如果公司不支持，容量要提前扩容到位并压测。
防超卖
技术上一般采用redis+热数据缓存+MQ。库存一般会在秒杀前同步到redis中。秒杀时判断库存是否充足，充足则可进行扣减。可以借助Redis+lua脚本来保证原子性，防止数据不准确造成超卖。
订单履约
秒杀可以采用两阶段处理，第一阶段如果秒杀成功，则将这个消息放入消息队列来做履约。这样可以提高响应速度，也可以减少秒杀并发的压力。这个消息要做成可靠消息，如果消费失败，需要有重试。重试失败则需要持久化到数据库等方式保存，定时扫描重新处理。同时要有告警机制，确保成功。
应急处理
要有降级开关来保证确实出了问题的情况下及时止损。
