Spring Cloud电商后端：用户登录与商品库存核心设计实践

做电商后端有一段时间的同学应该都有个感受：业务功能其实是最好写的，真正耗时间的是怎么把用户的登录态、商品的库存、详情页的抗压这些事在分布式环境里做稳。上一篇文章把项目骨架、服务划分和注册中心这些基础讲完了，这篇就直接进正题，聊用户模块和商品模块在下半场里那些躲不开的细节。我尽量不念PPT，把我实际开发里趟过的坑、改过的方案、最后留下来在用的代码结构都摆出来。内容适合正在做Spring Cloud电商项目、或者准备做毕业设计和简历项目的同学参考，尤其是想搞明白用户登录、分布式会话、SPU/SKU建模、库存扣减这些点的时候，这篇能给到一些可以直接抄的答案。

1. 整体设计与模块边界：用户与商品在电商系统里的定位

先纠正一个容易犯的错：很多人一开始做用户模块和商品模块，就直接照着“用户表”和“商品表”去设计CRUD，结果做到后面发现，用户模块里塞了地址、积分、优惠券，商品模块里塞了库存、评价、分类，一个服务变成大杂烩。我的建议是，先从系统边界和领域模型入手，想清楚每个服务的职责和边界，再动代码。

1.1 为什么用户和商品要拆成独立服务而不是一个大后端

单体应用里用户和商品放一起没什么问题，但一旦上了Spring Cloud，服务的拆分粒度直接决定了后面维护成本。我在这套电商系统里把用户和商品各拆成一个独立服务，不是跟风微服务，而是因为这俩的访问特征完全不同。

用户模块的特点是：读多写少，但读的瓶颈集中在登录态校验和用户信息查询上；并发峰值跟着活动走，比如秒杀前的一波登录。商品模块的特点是：详情页读流量巨大，SKU维度的库存操作是强一致性的硬骨头，而且商品的写操作（上下架、改价格、调库存）都集中在运营后台，QPS不高但强一致要求极高。

把这两个模块拆开，好处有三点：一是两边的数据库可以独立选型和扩容，用户库用MySQL做主从，商品库可以挂Redis缓存扛详情；二是发布节奏可以分开，运营改商品配置不需要重启用户服务；三是故障隔离，用户服务挂了不至于影响商品详情浏览。这也是Spring Cloud微服务架构在这个场景里最朴素的意义。

1.2 服务间调用关系与数据隔离策略

在这套系统里，服务调用的基本规则是：能不同步调用的就不同步调用，能走缓存的绝不穿透到数据库。用户服务和商品服务之间唯一的强关联场景是购物车和下单预览，其他场景基本都是靠Feign接口做轻量查询，比如在订单服务里要展示商品名称和缩略图，直接调商品服务的Feign接口。

这里有个实践上的建议：不要让下游服务直接查上游服务的数据库。哪怕你图省事在代码里配了双数据源直接查用户表，也要忍住。用户表的数据结构一旦调整，商品服务那边就可能出问题，而且这种隐式依赖排查起来特别费劲。我在代码里强行规定，所有跨服务的数据获取都必须走Feign接口，哪怕多一次网络开销，换来的是边界清晰。

1.3 配置中心与注册中心的取舍：Alibaba套件停更背景下怎么选

热词里提到“Spring Cloud Alibaba停更了”，这个确实是很多人焦虑的点，我单独说一下我的理解。Spring Cloud Alibaba本身并不是停更，而是部分组件（比如Nacos的某些旧版本）的维护节奏变化，加上Spring Cloud官方的版本策略调整，导致很多人误以为整条链路都废了。实际上我在这个项目里用的就是Spring Cloud Alibaba的Nacos做注册中心和配置中心，目前生产环境跑得挺稳。

不过选型上我会做一个折中：注册中心和配置中心用Nacos，但服务间调用的负载均衡和熔断降级，采用Spring Cloud LoadBalancer加Sentinel的组合，而不是死等老版本的Ribbon或Hystrix。原因很简单，Ribbon进入了维护模式，Hystrix也停止开发很久了，新项目再往这两个组件上投入不是不行，而是后续做版本升级会比较痛苦。既然热词里都提到Spring Cloud Sentinel datasource redis集群，说明很多人已经在拿Sentinel做流控和熔断的数据持久化，这个方向是对的。

2. 用户模块的核心设计与关键代码落地

用户模块看着简单，无非注册登录改资料，但真正生产级的用户模块要考虑的东西很多：密码怎么存、登录态怎么保持、分布式场景下Session怎么处理、接口怎么防刷、用户信息变更之后怎么通知下游。下面逐个讲我在这套系统里的落地方式。

2.1 用户注册与账号体系：用户名、手机号、第三方登录的统一处理

账号体系上我没有搞复杂，采用邮箱或者手机号作为登录凭证，同时支持一个可选的用户名用于展示。数据库设计上，用户主表存的是uid、登录名、密码散列值、盐、手机号、邮箱、状态、创建时间、最后登录时间等字段。重点说一下密码存储，这是很多新手项目最容易被人拿出来问的点。

密码绝对不能明文，也不能只做一次MD5，因为MD5已经被彩虹表干穿了。我的做法是每个用户独立随机盐，然后使用PBKDF2或bcrypt做加盐散列。项目中我选择的是bcrypt，因为它内部自带盐，且计算成本可调，不需要额外存盐字段，代码维护起来更省事。Spring Security自带的BCryptPasswordEncoder就能直接接入，接口代码大致是这样：

@Service public class UserRegisterService { @Autowired private UserMapper userMapper; @Autowired private BCryptPasswordEncoder passwordEncoder; public Result<Long> register(RegisterCommand cmd) { // 校验登录名唯一 if (userMapper.countByLoginName(cmd.getLoginName()) > 0) { return Result.fail("该账号已被注册"); } UserAccount account = new UserAccount(); account.setLoginName(cmd.getLoginName()); // 使用bcrypt哈希密码，encode内部自动生成盐，推荐强度10 account.setPasswordHash(passwordEncoder.encode(cmd.getPassword())); account.setCreateTime(LocalDateTime.now()); userMapper.insert(account); return Result.ok(account.getUid()); } }

这里有个实操细节：注册接口要加一个全局唯一约束，不光是代码查一遍就完，数据库层面要对login_name加唯一索引，否则并发注册的时候可能插入两条相同的数据。这是我在项目里真实遇到过的，压力测试阶段回调注册接口，瞬间插入了好几条重复账号。

2.2 登录态与分布式会话：Session共享还是JWT

用户登录之后的状态保持是电商系统绕不开的问题。很多单体项目直接扔HttpSession里，但一旦服务部署多实例，Session默认是不共享的。常规方案有两种：Session共享（存Redis）和JWT无状态令牌。我在这套系统里最终选择了JWT为主、Redis黑名单兜底的方案。

选JWT的原因首先是服务无状态化，用户服务水平扩展的时候不需要关心用户的Session在哪个节点上；其次是网关层可以直接解析令牌做身份识别，而不需要把请求转发到用户服务去查会话。但这套方案有个致命短板：令牌在签发之后没法主动失效。所以我又加了一层Redis存储，把每个签发的token的jti作为key存到Redis，过期时间跟token保持一致，登出或者改密码的时候直接删掉这个key，实现逻辑上的主动失效。

登录接口的核心代码大概是：

public LoginResponse login(LoginCommand cmd) { UserAccount account = userMapper.findByLoginName(cmd.getLoginName()); if (account == null || !passwordEncoder.matches(cmd.getPassword(), account.getPasswordHash())) { throw new BizException("用户名或密码错误"); } if (Objects.equals(account.getStatus(), 1)) { throw new BizException("账号已被禁用"); } // 生成JWT，携带uid、loginName和jti String jti = UUID.randomUUID().toString().replace("-", ""); Map<String, Object> claims = new HashMap<>(); claims.put("uid", account.getUid()); claims.put("jti", jti); String token = Jwts.builder() .setClaims(claims) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000L)) .signWith(SignatureAlgorithm.HS256, jwtSecret) .compact(); // 把jti存入Redis，设置与token一致的过期时间 redisTemplate.opsForValue().set("login:token:" + jti, account.getUid().toString(), 7, TimeUnit.DAYS); return new LoginResponse(token, account.getUid()); }

配套的登录校验写成一个HandlerInterceptor或者网关处的全局过滤器，每次请求都先从Redis里查一下jti是否有效，DevTools热加载的时候这个逻辑也不会出岔子。

2.3 用户状态管理与分布式下的幂等控制

用户资料查询接口有一个容易被忽略的问题：它要面对大量读请求，而这些请求最好有缓存支撑，但用户资料又有很强的实时性要求。我的方案是Redis缓存加过期时间，缓存key设计成user:info:{uid}，修改资料的时候主动删除缓存，下次查询再回源。

这里我踩过一个坑，就是刚开始只用了expire机制，没有主动删除缓存，结果用户改完头像之后，详情页那边头像一直不变，过了缓存过期时间才刷新。后来统一改成“更新数据库-删除缓存”的模式，凡是通过用户服务修改资料的请求，事务提交后立刻删除相关缓存的key。这个模式虽然引入了一点点缓存穿透的风险，但对用户资料的并发度来说完全在可控范围内，而且可以用一条简单的delete操作避免脏数据。

用户服务的写接口还需要注意幂等性，比如用户注册、绑定手机号这种操作，如果用户手滑点了两下提交按钮，前端又没有做防止重复提交，后端就会产生脏数据。我在这套系统里用Redis setnx做了简易的分布式锁，key是业务维度加用户维度，比如register:lock:{loginName}，加锁失败直接返回“请勿重复提交”。

3. 商品模块的核心建模与详情页性能方案

商品模块是电商系统里最容易被低估的部分。表面上看就是增删改查几张表，但实际上要处理SPU、SKU、类目、品牌、上下架、详情、库存、价格这批数据关系，还要在高并发读的场景下保证详情页能扛得住。这一节把模型设计和关键接口写法都过一遍。

3.1 SPU与SKU数据模型：电商商品的标准建模方式

商品模型我采用的是SPU和SKU两层结构。SPU（Standard Product Unit）是标准化产品单元，可以理解成一个商品的概念，比如“iPhone 15 Pro Max”；SKU（Stock Keeping Unit）是库存量单位，是具体到某个规格可卖的实物，比如“iPhone 15 Pro Max 黑色 256G”。在电商系统里，用户下单买的是SKU，运营管理的是SPU，商品详情页展示的则是SPU维度的聚合信息。

库表设计上是：spu表存商品主信息（标题、副标题、详情、类目id、品牌id、状态），sku表存规格组合（spu_id、规格值JSON、图片、价格、库存），类目和品牌单独建表，规格模板单独建表。这层设计的关键是一定要把sku的规格值设计成JSON列，数据库层面不需要为每种规格建字段，前端渲染时拿JSON去解析就行，省去大量动态列变更的麻烦。

商品上下架的操作核心其实是状态流转：spu有草稿、上架、下架三个状态，sku有启用、停用两个状态。上架商品时先校验是否有至少一个启用的sku，不然一个能卖的规格都没有，商品挂上去就是空壳；下架商品时如果还有未支付订单关联，要提前做拦截提示，避免用户下单了却没货可发。

3.2 商品详情页性能方案：缓存穿透、击穿、雪崩的应对

商品详情页是读并发最高的场景之一，所有优化都围绕缓存展开。我的方案是把详情页拆成三个缓存维度：基础信息、销售属性、详情描述，分别设置不同的过期时间，再在接口层做组装。这样做的好处是细粒度更新，比如运营改了库存，只需要刷新sku缓存，不需要把整个详情缓存全部删掉重建。

缓存穿透是第一道拦路虎。恶意请求拿不存在的商品id反复刷接口，每次都打到数据库，能把库拖垮。我的处理方式是在接口层加一个布隆过滤器，拦截掉明显不存在的id。因为商品id是雪花算法生成的，相对连续但分布比较稀疏，布隆过滤器的误判率控制在1%以内，几乎可以忽略。实际写代码时，我用Redisson自带的RBloomFilter就能实现，不需要额外引入组件。

缓存击穿是我更关注的场景。秒杀前某爆款商品的详情缓存刚好过期，瞬间涌入大量请求全部回源数据库，这个瞬间的流量其实很致命。我用的是互斥锁方案，在缓存过期后重建缓存时，让第一个线程去数据库加载数据并写入缓存，其他线程短暂自旋等待，拿到值后直接返回。代码逻辑用Redis的setnx加锁，锁的过期时间不能太短，我设置成5秒，重建过程通常只需几十毫秒。

这里给一个真实场景的补充：详情页还要配合Sentinel做接口限流。热词里不是提到了Sentinel datasource redis集群嘛，我在这套系统里就是把Sentinel的限流规则持久化在Redis集群里，而不是存在本地内存。

# Sentinel datasource配置，规则存储在Redis spring: cloud: sentinel: transport: dashboard: localhost:8858 datasource: ds-redis: redis: host: redis-master port: 6379 password: ${REDIS_PWD} channel: sentinel-rules rule-type: flow

这样每次在控制台上调整限流规则，规则会同步到Redis，多个商品服务节点共享同一份规则配置，不需要逐个节点去改配置文件。这也是很多若依Spring Cloud改造方案里提到的做法，用配置中心加Redis把Sentinel规则做成动态下发。

3.3 库存扣减方案：数据库扣减、缓存预扣减与事务一致

库存是商品模块里最考验设计能力的地方。我在这套系统里把库存操作分成两个场景：普通加购时的库存预占，和下单时的扣减。普通场景直接读Redis里的sku库存缓存，显示给用户“可购买数量”；真正下单的时候再走库存服务扣减数据库库存，然后反向同步缓存。

我最终选用的扣减方案是“预扣库存+支付回调确认”模式。用户提交订单时：

1. 在Redis里先扣减缓存库存，使用Lua脚本保证原子性，如果缓存库存不足，直接返回失败；
2. 在订单服务创建订单，数据状态置为待支付；
3. 同步调库存服务扣减MySQL库存，并记录一条库存流水；
4. 用户支付成功后，异步任务把订单状态改成已支付，如果超时未支付，系统自动取消订单并回补库存。

这里最核心的代码是Redis+Lua的原子扣减脚本，我直接贴出来：

-- KEYS[1] 是库存key -- KEYS[2] 是已售key -- ARGV[1] 是扣减数量 local stock = tonumber(redis.call('get', KEYS[1]) or '0') if stock < tonumber(ARGV[1]) then return -1 end if stock - tonumber(ARGV[1]) < 0 then return -1 end redis.call('decrby', KEYS[1], ARGV[1]) redis.call('incrby', KEYS[2], ARGV[1]) return 1

用Redis集群跑这套脚本时，要注意key的哈希槽落在同一个节点上，否则跨节点执行会报错。我当时的做法是给库存相关的key统一加上哈希tag，比如{sku:1001}:stock和{sku:1001}:sold，这样两个key落到同一个slot，Lua脚本才能正常执行。

MySQL库存扣减用一条条件更新实现防超卖：

UPDATE sku_stock SET stock = stock - #{count} WHERE sku_id = #{skuId} AND stock >= #{count}

执行后如果影响行数为0，说明库存不足，抛出库存不足异常，同时删掉Redis缓存，下次查询时回源数据库获取最新值。

4. 用户与商品模块联动的核心业务场景落地

用户模块和商品模块拆成了两个服务，但真实电商业务里它俩是要频繁联动的。购物车、收藏夹、商品评价、优惠券领取这些操作，都要同时涉及用户身份和商品数据。这一节讲讲这些联动场景里我觉得最值得注意的代码和设计。

4.1 购物车模块：Redis存储还是数据库存储

购物车是典型的高频读、低频写模块，而且每个用户的数据量很小，特别适合放Redis。我用Hash结构存储购物车数据，key是cart:{uid}，field是skuId，value是商品数量。这样用户加购、改数量、删商品都只需要操作Redis，性能极佳，也不需要为购物车建一堆MySQL表。

唯一的问题是购物车数据不能长期丢，所以我在购物车服务里加了一个异步落库定时任务，每隔5分钟把Redis里的购物车数据增量同步到MySQL，作为兜底备份。用户重装App或者登录新设备之后，如果Redis数据丢失了，就从MySQL恢复购物车。这样做既保证了读写性能，又不会让用户辛苦添加的商品直接蒸发。

4.2 收藏夹与关注商品：异步解耦思路

用户收藏商品这个动作的特点是操作频繁、实时性要求不高，完全没必要同步去写商品服务的数据库。我的方案是收藏服务直接操作自己的收藏表，表里存uid、skuId、spuId、创建时间，之后通过Spring Cloud Stream发一条收藏事件到RabbitMQ，商品服务订阅消息，更新商品的热度值，用户服务更新用户的收藏数量。

这个异步解耦在代码上的体现是：收藏接口只负责写库和发消息，用户看到的是“收藏成功”，至于热度异步更新、推荐位异步刷新这些都是后台慢慢完成的事。这样真实业务里你能少调至少两个Feign接口，接口响应时间也能缩短不少。

这里顺手提一个RabbitMQ消息可靠性的配置：发送消息时我开启了publisher-confirm和publisher-returns，消费者使用手动ack模式。一旦消息发送失败或者消费失败，就进本地消息表做补偿，每30秒扫描一次未成功处理的记录，重新发送。这套机制看起来简单，但非常管用。

4.3 下单过程中的用户与商品数据一致性

订单服务在下单时要同时读取用户地址和商品信息。这两个数据分布在两个不同服务里，我选择了编排式开发，而不是链式调用：订单控制器同时并行调用用户服务的地址查询接口和商品服务的sku查询接口（使用CompletableFuture并行组装），最后聚合成下单预览数据。

这样做的好处有一个非常实在的点：避免串联调用导致的总耗时累加。如果用Feign先查用户地址再查商品信息，一次下单预览最少要串行等两个RPC，差不多50毫秒才能拿到全部数据；并行调用的话，总耗时基本等于最慢的那个接口，一般能控制在25到30毫秒左右。

还有个细节是用户下单后要扣减积分、更新用户等级这些联动操作，也全部走消息队列异步处理，不在下单主链路里同步等待，确保交易核心链路的响应速度。

5. 压测、监控与常见问题的排查实录

这一节我专门整理一些项目跑起来之后才会遇到的真实问题。这些细节常规教程里很少讲，但做项目的时候几乎一定会碰上。

5.1 压力测试结果与性能瓶颈定位

这套系统我用JMeter做了三轮简单压测，先给出吞吐量的基准数据：单机8C16G云服务器，商品详情接口在缓存命中率超过95%的情况下，QPS大概在2800左右，用户登录接口因为有密码哈希计算，而且bcrypt强度设为10，单机QPS只能到500左右。这个数据说明用户登录接口会成为整个系统的瓶颈点，因为bcrypt的哈希计算本来就是故意的CPU密集型操作。

优化思路有几个：一是加盐哈希计算强度降到合理的中间值，不要一上来就上12这种重型参数，我降到10之后单机QPS能提升约30%；二是网关层对登录接口做Sentinel限流，比如单机每秒只允许通过200个请求，防止被打爆；三是横向扩展用户服务节点，把登录流量分摊到多台机器。

压测时我遇到过接口线程池被打满的问题，表现为Tomcat默认线程池200个线程用尽，后续请求全部排队甚至超时。排查思路是先看Sentinel监控面板，看哪个接口被限流了；再看Tomcat线程状态和JVM堆占用，确认是线程阻塞还是内存溢出。这个排查路径比较通用，我把它整理成一个速查表供参考：

5.2 分布式场景下的数据一致性与缓存一致性复查

用户和商品模块最常见的坑就是缓存一致性问题。我在这里单独列一下我在项目中坚持的几条纪律：

第一，所有更新数据库的操作成功后，立即删除对应的Redis缓存，而不是更新缓存。删除比更新简单，而且能避免并发更新导致的时序错乱。

第二，如果允许缓存短暂不一致，可以在删除缓存后发一条延迟消息，比如延迟1秒后再删一次，作为双删策略的兜底。我第一次做的就是删缓存，结果遇到并发读把旧值重新写进缓存的情况，后来加了第二次延迟删除，这个问题就基本消失了。

第三，商品库存这类强一致数据不能直接依赖缓存，数据库永远是真源；Redis中的库存可以有一小段时间不一致，但最终必须通过定时任务和流水记录校准回数据库的值。

5.3 面试追问与简历项目提点

这套基于Spring Cloud的电商系统写到简历上，面试官大概率会追问这几个方向：为什么用Spring Cloud Alibaba、Sentinel限流规则怎么做持久化、缓存与数据库一致性怎么解决、库存防超卖怎么做、分布式Session方案怎么选的。这篇里我基本把每个问题对应的方案设计都讲到了，面试前还可以把Sentinel加Redis数据源和库存Lua脚本这两个点再细扣一遍，这两个最容易被追问编码细节。

如果简历上还写了Redis集群，那热词里提到的“Sentinel datasource redis集群”就是很好的一条扩展线，可以主动讲：你用Sentinel配合Redis集群，把限流规则做成动态下发，避免了传统Sentinel规则只存在单个控制台内存里、重启丢失的问题。这个点能体现你对生产级配置的思考，而不仅仅是会用注解。不过我还是要多提醒一句：想把这个写成简历亮点，前提是你真在项目里跑过这套配置，别把别人的经验背过来当自己的，面试官顺着细节多问两轮就容易露馅。

写在最后的个人体会

整个用户与商品模块从搭建到稳定运行，我最大的体会是：做微服务最容易翻车的不是技术选型，而是边界感的缺失。用户和商品这两个模块，业务边界划清楚、数据存储独立、缓存设计分层、跨服务通信走接口，在Spring Cloud这套体系下其实没有太多玄学，按部就班做，每个环节都扎实一点，系统自然不会差到哪里去。

最后再分享一个小技巧，如果你是在做毕业设计或者个人项目，建议在商品模块里把SPU和SKU的建模、在用户模块里把JWT加Redis黑名单这套方案做扎实，这两块最能体现你是不是真的理解电商核心业务，而不只是会用几个框架注解。先把这两个点讲明白，再去聊Nacos、Sentinel这些组件，整个项目的含金量会高很多。