简介一份以京东商城为蓝本的超大型电商系统架构设计方案PDF面向电商平台架构师、技术负责人及后端开发者系统讲解从架构目标到落地原则的完整路径。内容覆盖业务架构、应用架构、数据架构设计原则以及技术架构总览与系统运维原则并结合自营、商城、三方平台等混合模式给出主流程与辅流程分离、核心与非核心业务隔离、水平扩展与分库分表等可借鉴做法。方案明确提出整体系统可用性99.99%、单个系统可用性99.999%等关键指标并围绕低成本、高扩展、高可用展开说明对关注稳定性与性能的团队尤其有参考价值。包体为1个PDF文件大小2.51MB内含清晰目录便于按章节查阅学习。已有186人学习适合希望参考京东实践来优化自身电商系统设计、提升高并发与高可用能力的读者。1. 当流量过了千万级电商架构方案就开始变成一门概率与成本的艺术做电商系统架构设计超过五年的人大多经历过一次类似的认知刷新当系统日活和订单量还小时JSP 加两个 Tomcat 完全够用当大促流量像周期性潮汐一样涌来时付费墙、幽灵库存、超卖订单就会变成比业务逻辑更要命的技术问题。超大型电商系统架构设计方案本质上就是围绕这几个核心矛盾展开的——高并发读、高一致性写、高可用容灾、以及成本约束下的弹性伸缩。这篇博文会按照一线从业者在图纸阶段就会遵循的路径把超大型电商系统从流量分层到数据分片、从缓存策略到最终一致性方案完整过一遍。适合正在设计下一个版本架构的团队负责人、以及刚接触大规模分布式系统但已有基础后端经验的人阅读目标是让方案落地时每个参数都有据可查、每个模块都能被运维和研发同事接手。2. 超大型电商系统架构设计的前提先定流量模型与业务边界2.1 流量模型的三类核心指标在动笔画架构图之前必须先把业务侧的数字钉死。超大型电商系统通常具备以下可量化的特征每日订单量在百万级到千万级之间商品 SKU 数量过亿同时在线用户数突破百万。架构设计不能围绕峰值流量展开那样成本会失控也不能围绕均值展开那样大促必然雪崩。常见做法是定义三个指标日常峰值 QPS、大促目标 QPS、以及可接受的尾延迟。以商品详情页为例日常峰值 QPS 在十万量级时Redis 缓存命中率若能保持在 99% 以上后端数据库实际承压的读 QPS 就只有一千左右。但当大促目标 QPS 定为百万级时缓存击穿、热点 Key 分散、以及专有网络带宽上限都会成为新的瓶颈。因此第一个需要明确的设计原则是流量数字决定架构图中每个组件的节点数而不是反过来。设计文档开头应该附一张表列出核心接口在三种场景下的 QPS、响应时间要求、以及数据量级这是后续所有容量规划的唯一依据。2.2 业务边界划分的三种常见模式超大型电商系统的业务域拆分一般遵循三种思路。第一种是商城前台域包含商品浏览、搜索、购物车第二种是交易中台域包含订单、支付、库存第三种是支撑域包含会员、营销、消息通知。划分的标准以“变更频率”和“数据一致性要求”为准商品信息变更频率极低但读取量极高可以走缓存加异步索引库存和订单变更频率高且强一致必须走分布式事务或事务消息。三种模式里我一般会在设计文档里单独画出“订单状态机”的边界因为订单从创建到完成涉及至少六个状态流转、三次外部系统调用每一处网络超时都会把分布式系统的一致性推向最终一致。明确边界的目的不是追求微服务的完美划分而是让团队在“某个商品模块的改动是否会影响交易链路的稳定性”这个问题上快速达成一致。3. 分层架构与每层的关键实现从接入层到数据层全部打通3.1 接入层的负载均衡与 Web 防火墙策略接入层是整个超大型电商系统架构设计方案的入口也是抵御恶意流量和大促洪峰的第一道防线。生产环境中常规部署方案是 LVSLinux Virtual Server做四层负载均衡Nginx 做七层负载均衡两者配合使用。四层负责转发七层负责请求路由、限流和简单的黑白名单。这时必须设定两个参数Nginx 的worker_processes通常设置为服务器物理核数worker_connections根据内存大小配置常见生产配置为worker_connections 65535单个 worker 进程能承载的并发连接数由此决定。upstream product_server_pool { least_conn; server 10.0.0.11:8080 max_fails3 fail_timeout30s; server 10.0.0.12:8080 max_fails3 fail_timeout30s; keepalive 64; } server { listen 80; location /api/product { limit_req zoneapi_limit burst2000 nodelay; proxy_pass http://product_server_pool; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这段 Nginx 配置定义了商品接口的负载均衡池least_conn算法会把新请求转发给当前活跃连接最少的节点适合长连接较多的场景。keepalive 64表示每个 worker 进程与上游服务器保持的空闲长连接数能省去大量握手开销。limit_req burst2000 nodelay是在接入层做最粗粒度的限流防线——允许每秒固定速率加上最多 2000 个突发请求超出部分直接返回 503。参数要结合业务压测结果调整通常商品接口配 2000搜索接口配 500写接口配 200。3.2 微服务治理与无状态化改造应用层是整个系统架构设计中最容易膨胀的部分。超大型电商的服务数量往往会超过两百个此时如果不做无状态化改造弹性伸缩就无从谈起。无状态化的含义是任何一台应用服务器都不保存用户会话、临时文件或本地缓存所有状态都外置到 Redis 或对象存储中。JWTJSON Web Token取代 Session 后登录状态校验就从有状态的内存查询变成了无状态验签应用节点从 10 台扩到 50 台时不需要重新同步会话。服务治理目前的主流方案依旧是 Kubernetes 加 Spring Cloud Alibaba 或 Istio。这里不得不提服务发现与配置管理的联动。以 Nacos 为例它会同时承担注册中心和配置中心两个角色服务实例上下线可以在秒级被感知而配置变更通过监听器自动推送到客户端。常见配置项是nacos.config.retry-time重试拉取配置的间隔和nacos.discovery.heart-beat-interval心跳间隔默认 5000ms。spring: cloud: nacos: discovery: server-addr: nacos-cs:8848 heart-beat-interval: 5000 heart-beat-timeout: 15000 ip-delete-timeout: 30000 config: server-addr: nacos-cs:8848 file-extension: yaml max-retry: 10配置中heart-beat-timeout是服务端判定实例失活的超时时间三次心跳未收到则剔除。这个参数不宜设得太小否则 GC垃圾回收停顿或网络抖动会导致误杀也不宜过大否则故障转移要等很久。生产环境 15 秒是经过实测的折中值。3.3 数据层的分库分表与读写分离实践数据层是超大型电商系统架构设计中最容易踩坑的环节没有之一。当单表数据量超过两千万行或者单库 QPS 超过一万时分库分表就不是可选项而是必选项。分库分表需要提前确定分片键通常选择订单 ID 或用户 ID。订单表用order_id做分片键可以保证同一笔订单的所有数据都在同一分片省去跨库 JOIN用户维度的查询则是通过冗余表或中间表解决。ShardingSphere 是目前最常见的接入方式之一它可以作为应用层驱动嵌入也可以部署为独立代理。以标准分片算法为例分片表达式基于 Groovy 脚本rules: - !SHARDING tables: t_order: actualDataNodes: ds_$-{0..3}.t_order_$-{0..1} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: order_id_alg keyGenerateStrategy: column: id keyGeneratorName: snowflake shardingAlgorithms: order_id_alg: type: HASH_MOD props: sharding-count: 8 keyGenerators: snowflake: type: SNOWFLAKE这段配置的含义是订单表分布在 4 个数据库实例上每个实例再拆成 2 张物理表共 8 个分片。分片算法是HASH_MOD即对order_id取哈希后取模sharding-count 为 8这样某一笔订单只会出现在一个分片中。主键用雪花算法生成保证全局唯一且趋势递增。需要注意查询条件里不带order_id的 SQL会走全分片路由大促时的全分片扫描性能极差设计时要把这类查询提前转化到宽表或搜索引擎。3.3.1 主从延迟的补偿方案读写分离会把主从延迟问题暴露得非常明显用户在支付成功后刷新页面却看到“待支付”状态这在电商场景完全不可接受。我一般会在设计文档里写明三种补偿手段核心读流量强制走主库、异步任务把订单状态变更同步到 Redis、以及前端轮询时设置 500ms 的容忍窗口。真正要避免的误用是把强一致性读流量丢给从库同时把从库的seconds_behind_master当成唯一指标盯——主从延迟在批量更新场景下会瞬间飙升到数十秒单纯加大从库规格并不能根治。4. 超大型电商系统架构设计中的一致性与高可用实战4.1 库存扣减的最终一致性落地方案超卖的根源是并发场景下查与扣之间出现了时间窗口。常见设计方案是把库存从数据库搬到 Redis用 Lua 脚本保证原子扣减然后异步把结果同步回数据库。扣减脚本如下-- KEYS[1] 是库存 keyKEYS[2] 是已扣减明细 keyARGV[1] 是本次扣减量 local current tonumber(redis.call(GET, KEYS[1]) or 0) local cost tonumber(ARGV[1]) if current cost then return -1 end redis.call(DECRBY, KEYS[1], cost) redis.call(INCRBY, KEYS[2], cost) return current - cost这段 Lua 脚本之所以安全是因为 Redis 会以原子方式执行整个脚本中间不会插入其他命令从而消除了“查超卖”与“扣库存”之间的竞态条件。设计时要注意 Redis 的库存 key 需要设置过期时间兜底比如 24 小时防止冷门商品长期占用内存但过期时间又要在脚本之外通过定时任务刷新避免大促期间 key 过期导致库存“凭空消失”。数据库侧的库存同步一般通过 binlog 监听或消息队列异步完成最终一致性在这里足够了——如果 Redis 宕机系统需要直接切到数据库扣减同时暂停秒杀入口。4.2 缓存穿透、缓存击穿与缓存雪崩的差异化处理这三类故障常常被混为一谈但处理方式完全不同。缓存穿透查的是不存在的 key常规方案是布隆过滤器拦截或缓存空值但空值缓存时间不宜超过 5 分钟缓存击穿是热点 key 在失效瞬间被大量请求直接打到数据库解决办法是分布式锁重建缓存缓存雪崩是大量 key 在同一时间过期解决办法是在过期时间上增加随机值。// 热点 key 重建缓存时的互斥逻辑 public String getProductDetail(String productId) { String cacheKey product:detail: productId; String value redisTemplate.opsForValue().get(cacheKey); if (value ! null) return value; // 两个线程同时发现缓存失效只有拿到锁的线程能回源数据库 String lockKey lock:product:detail: productId; boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(3)); if (!locked) { // 没拿到锁的线程短暂自旋后返回旧缓存或默认值 Thread.sleep(50); return redisTemplate.opsForValue().get(cacheKey); } try { value productService.queryFromDatabase(productId); redisTemplate.opsForValue().set(cacheKey, value, Duration.ofMinutes(30)); return value; } finally { redisTemplate.delete(lockKey); } }这段代码的关键在于锁必须带过期时间防止持有锁的线程崩溃后锁永久不释放同时锁的过期时间不能小于数据库查询耗时否则会把还在执行回源的线程和其他等待线程一并放进临界区。大促场景下热点商品会同时被多个线程请求这里的自旋重试只做一次避免连接池被大量睡眠线程占满。4.3 分布式事务的三种可选路径订单、支付、库存、积分分属不同服务跨服务事务是超大型电商系统架构设计里躲不开的话题。强一致的 2PC两阶段提交在互联网业务中基本已不采用原因是同步阻塞和协调者单点。可靠消息最终一致是目前的主流方案本地事务执行时同时写入一条待发送消息事务提交成功后消息中间件才允许消费者拉取这样保证了业务操作与消息发送的原子性。另一种常见方案是事务消息以 Apache RocketMQ 为消息中间件。生产者发送半消息半消息对消费者不可见本地事务执行成功后提交确认消息变为可消费若事务回滚消息被删除。如果长时间没有收到确认消息中间件会回查生产者的本地事务状态。设计时要把回查接口的耗时控制在 100ms 内查询主表的订单状态即可不要做复杂的聚合计算。方案一致性类型业务侵入度适用场景可靠消息最终一致低订单状态、库存扣减后的通知事务消息最终一致中需要保证业务与消息同生共死TCC弱最终一致高资金类、高价值的库存预留5. 全链路压测、容量规划与压测模型的一处关键复核架构设计图纸画得再漂亮最终都要在全链路压测中接受检验。超大型电商系统的压测不能只压单个服务而在每个大促日历节点前进行全链路压测从 Nginx 入口灌流量、经过网关、应用、Redis、数据库直到下游的物流和支付模拟器。压测模型要基于上一轮大促的真实访问日志去重放而不是用随机数据生成流量否则缓存命中率、热点分布和数据库访问模式都会失真。压测过程中有一个关键复核点写流量与读流量的比值。很多团队按 8:2 的读写比去扩容器但电商系统的写链路往往还包含多个下游写操作一个创建订单接口实际会产生五次以上的写调用。只看接口层 QPS 而忽略链路放大系数会导致下游数据库和消息队列的容量预留偏差极大。我一般会导出链路追踪数据计算出每个核心链路的 DAG有向无环图中所有节点 QPS 的累加值与最末端的数据库 QPS 对照比值就是链路放大系数这个数字通常稳定在 3 到 5 之间。限流与降级的复核同样需要落到具体开关上。Sentinel 中配置的熔断规则要能一键触达每个服务在依赖不可用时必须有降级预案。系统架构设计实施方案中要单独维护一张“大促降级清单”标明每个降级动作的影响范围——例如关闭商品详情页的个性化推荐能节省多少 CPU、降级秒杀服务到消息队列模式后用户看到什么提示。设计文档规划再好降级演练没有做就不算完。压测中发现的每次 CPU 毛刺或 GC 抖动都值得查根因这些问题背后往往藏着新加的一个正则表达式或一次无索引查询而这类排查恰恰就是架构方案从纸面走向稳定的最后一公里。本文还有配套的精品资源点击获取 超大型电商系统架构设计：高并发、最终一致性与全链路压测
简介一份以京东商城为蓝本的超大型电商系统架构设计方案PDF面向电商平台架构师、技术负责人及后端开发者系统讲解从架构目标到落地原则的完整路径。内容覆盖业务架构、应用架构、数据架构设计原则以及技术架构总览与系统运维原则并结合自营、商城、三方平台等混合模式给出主流程与辅流程分离、核心与非核心业务隔离、水平扩展与分库分表等可借鉴做法。方案明确提出整体系统可用性99.99%、单个系统可用性99.999%等关键指标并围绕低成本、高扩展、高可用展开说明对关注稳定性与性能的团队尤其有参考价值。包体为1个PDF文件大小2.51MB内含清晰目录便于按章节查阅学习。已有186人学习适合希望参考京东实践来优化自身电商系统设计、提升高并发与高可用能力的读者。1. 当流量过了千万级电商架构方案就开始变成一门概率与成本的艺术做电商系统架构设计超过五年的人大多经历过一次类似的认知刷新当系统日活和订单量还小时JSP 加两个 Tomcat 完全够用当大促流量像周期性潮汐一样涌来时付费墙、幽灵库存、超卖订单就会变成比业务逻辑更要命的技术问题。超大型电商系统架构设计方案本质上就是围绕这几个核心矛盾展开的——高并发读、高一致性写、高可用容灾、以及成本约束下的弹性伸缩。这篇博文会按照一线从业者在图纸阶段就会遵循的路径把超大型电商系统从流量分层到数据分片、从缓存策略到最终一致性方案完整过一遍。适合正在设计下一个版本架构的团队负责人、以及刚接触大规模分布式系统但已有基础后端经验的人阅读目标是让方案落地时每个参数都有据可查、每个模块都能被运维和研发同事接手。2. 超大型电商系统架构设计的前提先定流量模型与业务边界2.1 流量模型的三类核心指标在动笔画架构图之前必须先把业务侧的数字钉死。超大型电商系统通常具备以下可量化的特征每日订单量在百万级到千万级之间商品 SKU 数量过亿同时在线用户数突破百万。架构设计不能围绕峰值流量展开那样成本会失控也不能围绕均值展开那样大促必然雪崩。常见做法是定义三个指标日常峰值 QPS、大促目标 QPS、以及可接受的尾延迟。以商品详情页为例日常峰值 QPS 在十万量级时Redis 缓存命中率若能保持在 99% 以上后端数据库实际承压的读 QPS 就只有一千左右。但当大促目标 QPS 定为百万级时缓存击穿、热点 Key 分散、以及专有网络带宽上限都会成为新的瓶颈。因此第一个需要明确的设计原则是流量数字决定架构图中每个组件的节点数而不是反过来。设计文档开头应该附一张表列出核心接口在三种场景下的 QPS、响应时间要求、以及数据量级这是后续所有容量规划的唯一依据。2.2 业务边界划分的三种常见模式超大型电商系统的业务域拆分一般遵循三种思路。第一种是商城前台域包含商品浏览、搜索、购物车第二种是交易中台域包含订单、支付、库存第三种是支撑域包含会员、营销、消息通知。划分的标准以“变更频率”和“数据一致性要求”为准商品信息变更频率极低但读取量极高可以走缓存加异步索引库存和订单变更频率高且强一致必须走分布式事务或事务消息。三种模式里我一般会在设计文档里单独画出“订单状态机”的边界因为订单从创建到完成涉及至少六个状态流转、三次外部系统调用每一处网络超时都会把分布式系统的一致性推向最终一致。明确边界的目的不是追求微服务的完美划分而是让团队在“某个商品模块的改动是否会影响交易链路的稳定性”这个问题上快速达成一致。3. 分层架构与每层的关键实现从接入层到数据层全部打通3.1 接入层的负载均衡与 Web 防火墙策略接入层是整个超大型电商系统架构设计方案的入口也是抵御恶意流量和大促洪峰的第一道防线。生产环境中常规部署方案是 LVSLinux Virtual Server做四层负载均衡Nginx 做七层负载均衡两者配合使用。四层负责转发七层负责请求路由、限流和简单的黑白名单。这时必须设定两个参数Nginx 的worker_processes通常设置为服务器物理核数worker_connections根据内存大小配置常见生产配置为worker_connections 65535单个 worker 进程能承载的并发连接数由此决定。upstream product_server_pool { least_conn; server 10.0.0.11:8080 max_fails3 fail_timeout30s; server 10.0.0.12:8080 max_fails3 fail_timeout30s; keepalive 64; } server { listen 80; location /api/product { limit_req zoneapi_limit burst2000 nodelay; proxy_pass http://product_server_pool; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这段 Nginx 配置定义了商品接口的负载均衡池least_conn算法会把新请求转发给当前活跃连接最少的节点适合长连接较多的场景。keepalive 64表示每个 worker 进程与上游服务器保持的空闲长连接数能省去大量握手开销。limit_req burst2000 nodelay是在接入层做最粗粒度的限流防线——允许每秒固定速率加上最多 2000 个突发请求超出部分直接返回 503。参数要结合业务压测结果调整通常商品接口配 2000搜索接口配 500写接口配 200。3.2 微服务治理与无状态化改造应用层是整个系统架构设计中最容易膨胀的部分。超大型电商的服务数量往往会超过两百个此时如果不做无状态化改造弹性伸缩就无从谈起。无状态化的含义是任何一台应用服务器都不保存用户会话、临时文件或本地缓存所有状态都外置到 Redis 或对象存储中。JWTJSON Web Token取代 Session 后登录状态校验就从有状态的内存查询变成了无状态验签应用节点从 10 台扩到 50 台时不需要重新同步会话。服务治理目前的主流方案依旧是 Kubernetes 加 Spring Cloud Alibaba 或 Istio。这里不得不提服务发现与配置管理的联动。以 Nacos 为例它会同时承担注册中心和配置中心两个角色服务实例上下线可以在秒级被感知而配置变更通过监听器自动推送到客户端。常见配置项是nacos.config.retry-time重试拉取配置的间隔和nacos.discovery.heart-beat-interval心跳间隔默认 5000ms。spring: cloud: nacos: discovery: server-addr: nacos-cs:8848 heart-beat-interval: 5000 heart-beat-timeout: 15000 ip-delete-timeout: 30000 config: server-addr: nacos-cs:8848 file-extension: yaml max-retry: 10配置中heart-beat-timeout是服务端判定实例失活的超时时间三次心跳未收到则剔除。这个参数不宜设得太小否则 GC垃圾回收停顿或网络抖动会导致误杀也不宜过大否则故障转移要等很久。生产环境 15 秒是经过实测的折中值。3.3 数据层的分库分表与读写分离实践数据层是超大型电商系统架构设计中最容易踩坑的环节没有之一。当单表数据量超过两千万行或者单库 QPS 超过一万时分库分表就不是可选项而是必选项。分库分表需要提前确定分片键通常选择订单 ID 或用户 ID。订单表用order_id做分片键可以保证同一笔订单的所有数据都在同一分片省去跨库 JOIN用户维度的查询则是通过冗余表或中间表解决。ShardingSphere 是目前最常见的接入方式之一它可以作为应用层驱动嵌入也可以部署为独立代理。以标准分片算法为例分片表达式基于 Groovy 脚本rules: - !SHARDING tables: t_order: actualDataNodes: ds_$-{0..3}.t_order_$-{0..1} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: order_id_alg keyGenerateStrategy: column: id keyGeneratorName: snowflake shardingAlgorithms: order_id_alg: type: HASH_MOD props: sharding-count: 8 keyGenerators: snowflake: type: SNOWFLAKE这段配置的含义是订单表分布在 4 个数据库实例上每个实例再拆成 2 张物理表共 8 个分片。分片算法是HASH_MOD即对order_id取哈希后取模sharding-count 为 8这样某一笔订单只会出现在一个分片中。主键用雪花算法生成保证全局唯一且趋势递增。需要注意查询条件里不带order_id的 SQL会走全分片路由大促时的全分片扫描性能极差设计时要把这类查询提前转化到宽表或搜索引擎。3.3.1 主从延迟的补偿方案读写分离会把主从延迟问题暴露得非常明显用户在支付成功后刷新页面却看到“待支付”状态这在电商场景完全不可接受。我一般会在设计文档里写明三种补偿手段核心读流量强制走主库、异步任务把订单状态变更同步到 Redis、以及前端轮询时设置 500ms 的容忍窗口。真正要避免的误用是把强一致性读流量丢给从库同时把从库的seconds_behind_master当成唯一指标盯——主从延迟在批量更新场景下会瞬间飙升到数十秒单纯加大从库规格并不能根治。4. 超大型电商系统架构设计中的一致性与高可用实战4.1 库存扣减的最终一致性落地方案超卖的根源是并发场景下查与扣之间出现了时间窗口。常见设计方案是把库存从数据库搬到 Redis用 Lua 脚本保证原子扣减然后异步把结果同步回数据库。扣减脚本如下-- KEYS[1] 是库存 keyKEYS[2] 是已扣减明细 keyARGV[1] 是本次扣减量 local current tonumber(redis.call(GET, KEYS[1]) or 0) local cost tonumber(ARGV[1]) if current cost then return -1 end redis.call(DECRBY, KEYS[1], cost) redis.call(INCRBY, KEYS[2], cost) return current - cost这段 Lua 脚本之所以安全是因为 Redis 会以原子方式执行整个脚本中间不会插入其他命令从而消除了“查超卖”与“扣库存”之间的竞态条件。设计时要注意 Redis 的库存 key 需要设置过期时间兜底比如 24 小时防止冷门商品长期占用内存但过期时间又要在脚本之外通过定时任务刷新避免大促期间 key 过期导致库存“凭空消失”。数据库侧的库存同步一般通过 binlog 监听或消息队列异步完成最终一致性在这里足够了——如果 Redis 宕机系统需要直接切到数据库扣减同时暂停秒杀入口。4.2 缓存穿透、缓存击穿与缓存雪崩的差异化处理这三类故障常常被混为一谈但处理方式完全不同。缓存穿透查的是不存在的 key常规方案是布隆过滤器拦截或缓存空值但空值缓存时间不宜超过 5 分钟缓存击穿是热点 key 在失效瞬间被大量请求直接打到数据库解决办法是分布式锁重建缓存缓存雪崩是大量 key 在同一时间过期解决办法是在过期时间上增加随机值。// 热点 key 重建缓存时的互斥逻辑 public String getProductDetail(String productId) { String cacheKey product:detail: productId; String value redisTemplate.opsForValue().get(cacheKey); if (value ! null) return value; // 两个线程同时发现缓存失效只有拿到锁的线程能回源数据库 String lockKey lock:product:detail: productId; boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(3)); if (!locked) { // 没拿到锁的线程短暂自旋后返回旧缓存或默认值 Thread.sleep(50); return redisTemplate.opsForValue().get(cacheKey); } try { value productService.queryFromDatabase(productId); redisTemplate.opsForValue().set(cacheKey, value, Duration.ofMinutes(30)); return value; } finally { redisTemplate.delete(lockKey); } }这段代码的关键在于锁必须带过期时间防止持有锁的线程崩溃后锁永久不释放同时锁的过期时间不能小于数据库查询耗时否则会把还在执行回源的线程和其他等待线程一并放进临界区。大促场景下热点商品会同时被多个线程请求这里的自旋重试只做一次避免连接池被大量睡眠线程占满。4.3 分布式事务的三种可选路径订单、支付、库存、积分分属不同服务跨服务事务是超大型电商系统架构设计里躲不开的话题。强一致的 2PC两阶段提交在互联网业务中基本已不采用原因是同步阻塞和协调者单点。可靠消息最终一致是目前的主流方案本地事务执行时同时写入一条待发送消息事务提交成功后消息中间件才允许消费者拉取这样保证了业务操作与消息发送的原子性。另一种常见方案是事务消息以 Apache RocketMQ 为消息中间件。生产者发送半消息半消息对消费者不可见本地事务执行成功后提交确认消息变为可消费若事务回滚消息被删除。如果长时间没有收到确认消息中间件会回查生产者的本地事务状态。设计时要把回查接口的耗时控制在 100ms 内查询主表的订单状态即可不要做复杂的聚合计算。方案一致性类型业务侵入度适用场景可靠消息最终一致低订单状态、库存扣减后的通知事务消息最终一致中需要保证业务与消息同生共死TCC弱最终一致高资金类、高价值的库存预留5. 全链路压测、容量规划与压测模型的一处关键复核架构设计图纸画得再漂亮最终都要在全链路压测中接受检验。超大型电商系统的压测不能只压单个服务而在每个大促日历节点前进行全链路压测从 Nginx 入口灌流量、经过网关、应用、Redis、数据库直到下游的物流和支付模拟器。压测模型要基于上一轮大促的真实访问日志去重放而不是用随机数据生成流量否则缓存命中率、热点分布和数据库访问模式都会失真。压测过程中有一个关键复核点写流量与读流量的比值。很多团队按 8:2 的读写比去扩容器但电商系统的写链路往往还包含多个下游写操作一个创建订单接口实际会产生五次以上的写调用。只看接口层 QPS 而忽略链路放大系数会导致下游数据库和消息队列的容量预留偏差极大。我一般会导出链路追踪数据计算出每个核心链路的 DAG有向无环图中所有节点 QPS 的累加值与最末端的数据库 QPS 对照比值就是链路放大系数这个数字通常稳定在 3 到 5 之间。限流与降级的复核同样需要落到具体开关上。Sentinel 中配置的熔断规则要能一键触达每个服务在依赖不可用时必须有降级预案。系统架构设计实施方案中要单独维护一张“大促降级清单”标明每个降级动作的影响范围——例如关闭商品详情页的个性化推荐能节省多少 CPU、降级秒杀服务到消息队列模式后用户看到什么提示。设计文档规划再好降级演练没有做就不算完。压测中发现的每次 CPU 毛刺或 GC 抖动都值得查根因这些问题背后往往藏着新加的一个正则表达式或一次无索引查询而这类排查恰恰就是架构方案从纸面走向稳定的最后一公里。本文还有配套的精品资源点击获取