标签：高并发

回头看这个活动商品与订单系统，它并不是一开始就需要复杂架构。最早只有商品页、下单接口和一张订单表。后来商品详情访问量上来了，于是加缓存；订单表变大了，于是优化索引、冷热分离；活动峰值来了，于是引入 …

用户说页面慢，客服说订单偶尔失败，运营说活动转化掉了。开发打开服务器看 CPU，好像还行；看数据库，好像也没完全打满；翻日志，日志很多，但不知道该搜什么。最后大家只能在群里互相问：刚才谁发版了？哪个…

活动系统最怕的，不一定是全站流量都高。更麻烦的是一个商品突然爆了。首页总 QPS 看起来还能接受，但某个商品详情页、某条库存记录、某个活动资格接口被集中访问。平均值很好看，局部资源已经被打穿。热点和…

活动高峰时，库存服务先慢了。订单服务调用库存服务，原本 100ms 返回，现在变成 2 秒。订单服务等不住，开始超时；客户端看到失败，又发起重试；订单服务自己也配置了重试；库存服务本来已经吃紧，又被…

系统没拆开之前，下单这件事很简单。一个数据库事务里，创建订单、扣库存、核销优惠券。提交成功就是成功，回滚失败就是失败，边界很清楚。后来系统拆开了。订单是订单服务，库存是库存服务，优惠券是营销服务，支…

活动开始后，下单接口最先扛不住。用户点击下单，接口里要校验活动、检查库存、创建订单、扣优惠券、发通知、更新报表。平时这条链路没问题，活动流量一上来，接口开始超时。这时候很多人会说：加 MQ。这个判断…

活动系统运行了几个月后，最先被抱怨的不是下单，而是后台订单列表。运营同学按时间筛选订单，页面从 200ms 变成 3 秒，再后来变成 8 秒。开发第一反应通常是：SQL 慢了，优化一下。但数据库问题…

活动刚开始的前十分钟，商品详情页先慢了。下单接口还没到峰值，支付也没出问题，但数据库 CPU 已经开始往上冲。排查后发现，大量请求都在查同一个商品详情、活动配置和库存展示。每个请求都不复杂，可它们太…

很多系统一开始都很朴素。一个商品详情页，一个下单接口，一张订单表，再加一个后台列表。访问量不大时，一切都很顺：页面打开很快，订单写入正常，后台报表也能查出来。后来业务做了一场活动。活动页被转发，商品…