技术文章

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

有一次团队以为自己有备份，直到真的需要恢复。备份文件确实存在，但恢复脚本很久没跑过；恢复出来的数据还要校验；应用连接怎么切，缓存怎么处理，消息积压怎么补，都没有完整演练。那一刻才会明白：高可用不是文…

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

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

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

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

活动系统最开始只有几万条订单，大家不会认真讨论“数据生命周期”。后台想查就查，运营想导出就导出，日志临时塞数据库也没人觉得有问题。直到半年后，订单表越来越大，报表越来越慢，备份时间越来越长，连一次普…

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

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

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