前后端压力隔离：自建子库把压力挡在第三方资源方和关系型数据层之外

抢购系统的商品数据来自第三方资源方，如果业务层每次查询”商品还有没有”都直接回源到第三方接口，抢购高峰会让这个高频请求同比放大到第三方接口上，给合作方带来额外压力；同样地，如果每次查询都直接打到自建的商品库（关系型存储），也会把业务层的高并发压力和数据层耦合在一起。解法是做两层解耦：一是自建商品库，把第三方数据主动拉取或接收推送到自己的存储里，业务层从此不再需要为了查询库存直接访问第三方接口，第三方的压力因此完全被隔离在外；二是业务层单独维护一个”抢购库”，它是商品库的一个子集（只包含运营勾选进当前抢购场次的商品及配额），这个抢购库专门用NoSQL（如Redis）来承载抢购高峰期”查询库存”这个最高频的请求，而不是直接查询关系型的商品库——因为可以预见抢购高峰期间”商品还有没有”这类查询的量级会远超其他操作，如果不单独抽出一层来扛，业务和数据层就会被这个高频查询绑在一起，一旦查询压力上去，连累的是整个数据层。这个案例体现了一条通用的压力分解原则：互联网系统里的大流量最终一定会落到某个具体环节，架构设计真正要解决的问题是决定这股压力最终落在哪一层、以及如何避免它一路畅通无阻地传导到最脆弱或代价最高的环节（比如第三方接口、关系型数据库）——通过主动在压力传导路径上插入专门设计的缓冲层（自建库、NoSQL子库），把压力挡在早期，是比”让每一层都努力扛住”更经济的做法。