高并发是大型架构核心，下面我重点详解电商秒杀TPS@mikechen
电商秒杀
电商秒杀场景下，TPS（Transactions Per Second，系统每秒处理的请求数），是衡量系统稳定性与可用性的核心指标。
秒杀活动，具有短时高并发、突发性强的特点。
应先估算峰值并发量：预估参与人数、单人请求频率、秒杀持续时间及请求类型（下单、库存查询、支付跳转等）。
将峰值并发转换为TPS，考虑并发请求中只有部分为最终写请求（如下单、扣库存），读请求（如商品页面）可通过缓存缓解。
电商秒杀TPS
电商秒杀“TPS 多少才稳”，没有一个放之四海皆准的固定数字。
必须结合你的用户量、业务设计、限流策略和机房/集群规模来推算目标 TPS 区间，然后用压测验证。
整体经验是：中小型电商秒杀活动，核心下单链路能稳定在 1 000～5 000 TPS 已经相当可观，大型平台会做到 1 万 ～10万TPS 甚至更高。
要实现高 TPS 且不宕机，必须遵循 “分层过滤，逐级减压” 的原则：
① 静态化与边缘抗压 (减少 90% 流量)
CDN 加速： 秒杀页面、图片、JS 脚本全部放在 CDN。
动态按钮置灰： 在前端控制点击频率（如点击一次后置灰 3 秒），防止用户暴力点击。
② 缓存热点数据 (解决 9% 流量)
Redis 预热： 商品库存、限购信息必须提前写入 Redis。
Lua 脚本扣减： 使用 Redis + Lua 实现原子性扣库存，避免请求透传到数据库。
本地缓存： 对极热点数据（如秒杀活动详情）使用 Caffeine 或 Guava 在应用内存中做二级缓存。
③ 异步削峰 (保护核心 DB)
消息队列 (MQ)： 用户点击后，后端校验完库存立即返回“排队中”，将订单创建请求写入 Kafka/RocketMQ。
慢处理： 后端订单服务根据自身处理能力（如 5000 TPS）平稳消费 MQ，避免数据库连接池被瞬间爆掉。
④ 数据库保护 (最后的防线)
行锁优化： 绝对禁止在秒杀瞬间用 UPDATE … WHERE id=1 更新库存，这会导致数据库死锁。
分库分表： 将订单数据分散到多个物理库，提升整体 IO 能力。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》