做超市管理系统这类项目难度往往不在框架本身而在业务复杂度。Spring Boot 在后端圈子的成熟度已经不需要我再吹捧真正拉开差距的是库存、订单、权限、促销这几块业务揉在一起之后的整体把控力。最近我完整做完了一个基于 Spring Boot 的大型超市前后台系统覆盖门店收银、后台管理、会员营销、进销存和经营报表踩了不少坑也沉淀了一些可以直接复用的经验。这篇文章就把整个系统的架构拆解、核心模块实现、关键问题排查和优化过程完整记录下来适合正在做类似订单管理、库存系统、超市/零售管理项目的开发者参考。1. 系统整体设计与架构拆解1.1 超市业务为什么需要“前后台”分离很多人会把“前后台”单纯理解成前端页面和后端接口但在超市项目里这两个字更多指的是两类完全不同使用场景的业务端。后台端面向的是店长、采购员、财务、仓管员操作场景是在办公室或者仓库用 PC 浏览器业务特点是数据量大、操作密集、权限敏感。比如商品档案管理、采购入库、库存盘点、供应商结算这些功能必须支持批量操作、复杂查询和权限审计。前台端则分成两类一类是门店收银操作员是收银员界面要求简洁、迅速、防错扫码枪扫一下、收钱、打印小票整个流程必须控制在几秒钟内另一类是顾客自助端也就是常说的会员小程序或者线上商城顾客可以自己浏览商品、加购物车、下单支付。这两类前台的使用习惯完全不同绝对不能塞进同一个界面。我当时的第一版设计犯过一个典型错误——试图做一套“既能给收银员用又能给顾客用”的通用界面结果两边都觉得难用。后来彻底拆开收银端用简洁的键位操作和大字号商品列表顾客端走微信小程序风格前后台通过同一套 API 网关对接数据层完全共用才真正跑通。1.2 技术选型背后的取舍逻辑后端核心框架选了 Spring Boot 2.7原因很现实稳定、生态全、招人好招。2.x 的版本在国内企业项目里存量最大遇到问题搜索资料几乎都有答案不像新版本某些 API 调整后社区解决方案还没跟上。ORM 用的是 MyBatis-Plus超市业务有大量动态查询和报表 SQL用它写条件构造器非常顺手分页插件也是开箱即用。数据库方面用了 MySQL 8.0配合 Redis 做缓存和分布式会话。这里有两个很关键的考虑。第一个是库存场景下数据库锁和缓存一致性必须精细控制不能把 Redis 当成万能缓存乱用第二个是报表统计走 MySQL 的聚合查询已经足够前期不需要引入大数据组件过度设计反而拖慢开发节奏。认证授权用的是 Spring Security JWT状态存储放在 Redis。这个组合的好处是后台管理端可以精细控制按钮级权限收银机端的会话又能在 Redis 里统一管理万一某台收银机故障换一台机器登录不需要重新录入所有权限信息。还有一个容易忽略的选择是文件存储。商品图片、供应商合同、盘点表这些附件直接存服务器本地路径会带来备份和扩容问题我用了 MinIO 搭私有对象存储配合 Nginx 做访问代理整体成本和后期维护都很可控。1.3 数据库模型设计的几个关键决策大型超市的表结构往往动辄几十张表但真正核心的链路只有一条商品档案 - 库存流水 - 采购/销售订单 - 财务结算。在设计阶段就要先保证这条链路上的表不出现逻辑漏洞。商品表必须区分SPU标准产品单元和SKU库存量单位。超市里一提“农夫山泉550ml”这就是 SPU“550ml*24 瓶整箱装”和“550ml 单瓶装”就是两个 SKU。如果只建一张商品表促销活动、库存管理、价格体系全都会乱成团。我在商品表之外单独建了 sku 表和 sku_attr_value 表规格属性用 KV 结构存储虽然多写了一点代码但后续做规格筛选和价格策略时非常顺手。库存表不单单存“当前库存数”还要加“锁定库存数”。顾客下单后先锁定库存支付超时再自动释放这样可以有效降低超卖风险。库存流水表单独建一张所有库存变动必须落流水方便对账和排查异常。价格体系也要单独拆表。超市的价格不是一成不变的有会员价、促销价、采购价、成本价。我只在 sku 表里存了一个默认售价其他价格全部放 price_policy 表用商品ID 价格类型 生效时间段作为联合维度。这样做的好处是促销活动审批通过后直接插入一条价格策就可以不需要回改商品主表。2. 后台管理端核心模块实现2.1 员工权限设计别再搞“万能管理员”了后台管理端的使用者分店长、采购、仓管、财务、收银员五个角色不同角色能看到的数据和能点的按钮完全不同。我用 RBAC 模型实现五张表用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。实际开发中真正麻烦的不是表结构而是权限的粒度控制。比如“采购员只能查看自己负责品类的商品”这种数据级权限靠 RBAC 的菜单/按钮权限解决不了必须在业务代码里加数据范围过滤。我的做法是在用户表里加 data_scope 字段分为全部、本部门、仅本人三档然后在 MyBatis 的查询条件里动态拼接。这里提供一个核心过滤的写法// 数据权限动态拼接示例 LambdaQueryWrapperProduct wrapper Wrappers.lambdaQuery(); if (user.getDataScope().equals(DataScope.DEPT_ONLY)) { // 查询当前用户所属部门负责的品类ID列表 ListLong categoryIds categoryService.getManagedCategoryIds(deptId); wrapper.in(Product::getCategoryId, categoryIds); }权限拦截这块我用 Spring Security 的PreAuthorize注解配合自定义的权限校验器。踩过的一个坑是拦截器配置顺序出错会导致登录接口也被拦截。解决方案是在 SecurityConfig 里明确放行/api/auth/login、/api/auth/captcha等匿名接口再统一拦截其余路径。2.2 商品与SKU管理批量操作必须做到事务内后台的商品管理功能最常用的是批量导入、批量改价、批量上下架。很多新手会写一个 for 循环逐个调用单条更新方法数据少的时候没问题数据一多就慢得一塌糊涂而且一旦中间出错前面改的已经提交后面没改数据直接错乱。我最终实现了一个统一的批量更新入口方法上加Transactional内部用分组批量更新 SQLTransactional(rollbackFor Exception.class) public void batchUpdatePrice(ListSkuPriceUpdateDTO list) { // 前置校验商品状态是否允许改价、价格是否低于成本价 validateSkuUpdate(list); // 按50条一组分片使用 CASE WHEN 一次性更新 MapLong, BigDecimal priceMap list.stream() .collect(Collectors.toMap(SkuPriceUpdateDTO::getSkuId, SkuPriceUpdateDTO::getPrice)); skuMapper.batchUpdatePriceByIds(priceMap); // 记录操作日志 operationLogService.record(OperationType.PRICE_UPDATE, list); }这里有个特别重要的点批量操作的校验必须在事务开始之后、更新之前统一完成不能边改边校验。比如批量改价时绝不能出现“前十条成功第十一条发现价格低于成本价回滚失败”的局面。我写完这个事务方法之后还专门加了一组针对异常分支的测试用例确保一旦校验失败整个批次全部回滚。2.3 采购入库与库存流水先锁库存再动数据采购入库是仓库管理的核心动作。采购员下单采购单供应商送货后仓库验收并做入库确认。入库操作的流程我设计为查询采购单 - 校验状态 - 锁单 - 写入库存流水 - 更新库存表 - 更新采购单状态全程走一个事务。库存扣减这里我用的是数据库行锁配合乐观锁的方式。具体来说库存表加了一个 version 字段更新时校验版本号UPDATE inventory SET stock stock - #{count}, version version 1 WHERE sku_id #{skuId} AND version #{oldVersion} AND stock #{count}只靠数据库的乐观锁还不够因为超市的库存操作并发很高。我在 Service 层又加了一层分布式锁锁的粒度是 skuId用 Redis 的 SETNX 实现public boolean lockSku(Long skuId, Long timeout) { String key lock:sku: skuId; Boolean result redisTemplate.opsForValue() .setIfAbsent(key, 1, timeout, TimeUnit.SECONDS); return Boolean.TRUE.equals(result); }值得注意的是锁一定要设置过期时间否则一旦某台服务器宕机锁永远不会释放整个商品的库存操作会被卡死。我设置的是 10 秒过期实际业务操作都在几百毫秒内完成足够安全。2.4 数据分析报表别让报表拖垮主库超市管理后台的报表模块一般是老板最看重的。营业额趋势、品类销售排行、毛利分析、库存周转率这些报表数据来自不同的维度表聚合计算量很大。第一版我直接在主库上写复杂查询结果一到月底结账时期报表页面加载要几十秒甚至影响了线上收银的交易响应速度。后来做了两层优化。第一层是“报表专用读库”。从主库通过 Binlog 同步一份只读数据到报表库所有聚合查询都走报表库主库只负责交易和基础数据写入。不需要引入复杂的中间件直接用 MySQL 的复制功能就能实现。第二层是“预聚合表”。日报表每天凌晨定时跑批把当天的销售数据按“门店、品类、时间”三个维度聚合后写入 summary 表。老板早上看昨天的数据时直接查 summary 表不需要再去扫明细表。这套方案上线后原来 30 秒的日报查询直接降到了 200 毫秒以内。3. 收银端与顾客前端的设计实现3.1 门店收银快是要害防错是底线收银端第一版是纯 Web 页面配扫码枪输入后来发现收银员在高峰期最烦的就是页面组件太重、输入框要鼠标点击定位。优化之后我把收银端改成了“聚焦输入框 键盘快捷键 大字号商品信息 即时小票预览”的模式。扫码枪本质上是一个 USB 键盘扫一下条码就相当于用极快的速度输入一串数字后回车所以页面上的条码输入框必须默认获得焦点并且监听回车事件触发商品查询。查询商品时直接走 Redis 缓存key 是条码value 是商品JSON。Redis 没命中再查数据库并回填缓存。这样一台收银机一天扫码近千次数据库压力也几乎为零public SkuVO getSkuByBarcode(String barcode) { String key cache:sku:barcode: barcode; String json redisTemplate.opsForValue().get(key); if (StringUtils.isNotBlank(json)) { return JSONUtil.toBean(json, SkuVO.class); } SkuVO sku skuMapper.selectByBarcode(barcode); if (sku ! null) { // 设置过期时间避免商品长期不更新导致脏数据 redisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(sku), 30, TimeUnit.MINUTES); } return sku; }收银还有一个必须要处理的问题手动输入条码时容易漏扫或错扫。我的做法是所有扫码商品先进入“待结算列表”确认前可以逐条删除提交结算时再一次打包创建订单。这个交互逻辑虽然多了一步但能极大减少因为误扫导致的价格纠纷。3.2 购物车、下单与库存扣减顾客端的购物车模块我用 Redis Hash 存储每个用户一个 key商品 skuId 是 field数量是 value。这样购物车的增删改查都快而且不需要在数据库建临时表。真正复杂的是下单时的库存校验和扣减。刚才提到的锁定库存机制在这里就发挥作用了顾客提交订单时先锁定库存然后创建订单和订单明细再扣减实际库存、释放锁定库存最后清空购物车。这四步必须在一个事务里完成。这里给出一个简化版的下单服务Transactional public Long createOrder(OrderCreateDTO dto) { // 1. 逐个商品锁定库存 for (OrderItemDTO item : dto.getItems()) { boolean locked inventoryService.lockSku(item.getSkuId(), item.getQuantity()); if (!locked) { throw new BusinessException(商品库存不足 item.getSkuId()); } } // 2. 创建订单主表 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(dto.getUserId()); order.setTotalAmount(calcTotal(dto.getItems())); order.setStatus(OrderStatus.PENDING_PAYMENT); orderMapper.insert(order); // 3. 创建订单明细 orderItemService.batchInsert(dto.getItems(), order.getId()); // 4. 更新实际库存 inventoryService.deductStock(dto.getItems()); return order.getId(); }这里必须提前考虑“锁定库存后的超时释放”。如果顾客下单后一直不支付锁定的库存要定期释放。我启动了一个定时任务每分钟扫描超过 15 分钟未支付的锁定单自动释放库存并取消订单。没做这一步之前曾经出现过促销活动开始后大量用户疯狂下单但不支付热销商品全部被锁定真正想买的人买不到的情况。3.3 会员积分与促销规则系统的隐性复杂度超市行业的促销规则比一般电商平台更复杂。常见的有“满 100 减 20”“第二件半价”“会员双倍积分”“指定品类折扣”“买 A 赠 B”。我用了策略模式来实现这些规则每个促销类型一个策略类通过工厂根据促销编码获取对应的策略执行器public interface PromotionStrategy { ListPromotionResult apply(OrderContext context); } Component(FULL_REDUCTION) public class FullReductionStrategy implements PromotionStrategy { Override public ListPromotionResult apply(OrderContext context) { // 根据订单金额和满减梯度计算优惠 return buildResult(context); } }促销规则的优先级也很关键。例如“满减”和“会员折扣”一般不能叠加需要预设一个规则优先级表下单时先取最优规则再计算。如果不做规则引擎而是把这些逻辑全写在订单服务的 if-else 里代码迟早变成一坨不可维护的面条。积分这块相对简单核心是会员表加一个积分余额字段交易完成后异步增加积分。注意这里的异步不能影响主交易流程我用消息队列来解耦即使积分服务挂了也不影响用户下单支付后续再补发。4. 项目落地过程中的疑难问题与优化实录4.1 事务失效的三个真实场景事务失效是 Spring Boot 项目最容易踩但最难排查的问题。我在这个项目里遇到了三种典型情况。第一种是方法内部调用。同一个类中 A 方法调用 B 方法B 方法上有Transactional但 Spring 的 AOP 代理不会生效相当于没加事务。我一开始在商品校验方法里调用了批量入库方法测试时发现异常后数据竟然没有回滚定位半天才发现是自调用问题。解决办法是注入自身代理或者把那个方法拆到独立 Service。第二种是异常被吞掉。事务注解默认只回滚 RuntimeException如果你在事务方法里 catch 了所有异常Spring 根本感知不到自然不会回滚。我把订单创建方法的异常捕获改成不捕获或者捕获后手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。第三种是事务和锁的顺序问题。分布式锁必须在事务外层获取而里层操作数据库否则锁释放完了但事务还没提交下一个线程读到的是旧数据。4.2 MySQL 慢查询优化一次排查实录运营反馈后台的销售明细报表很慢每次查询都像死机。我打开慢查询日志定位到一条 SQL发现是订单明细表关联商品表再关联品类表而且订单明细表的查询条件里用了status字段但该字段上没有索引。优化动作有两个层面。第一个是给高频过滤字段建立联合索引(store_id, status, create_time)。这三个字段正好覆盖了报表查询最常见的过滤条件。第二个是改写法把原来关联查询中的子查询改成 JOIN避免 MySQL 对子查询生成低效的执行计划。改造后这条 SQL 从 8 秒降到了 0.3 秒。这里有一个很容易忽略的前提——MySQL 索引不是越多越好。我在商品表上一度建了 10 个索引结果写入性能明显下降。后来删掉了那些只在极端场景才会用到的低频索引只保留真正服务于高频查询的索引写入效率恢复了正常。4.3 缓存穿透与缓存雪崩超市的收银端并发很高如果缓存设计得不好Redis 一旦出问题数据库立刻会被打爆。穿透和雪崩我都真实遇到过。穿透的场景是顾客反复扫码枪扫一个根本不存在的条码这个条码既不在缓存也不在数据库。我加了一层“空值缓存”查询不到就把空结果也缓存 3 分钟防止大量恶意请求直接打到数据库。雪崩的场景是所有商品的缓存同时过期高峰期缓存全部失效后请求全部涌向数据库。我的处理方案是给缓存过期时间加了一个随机 1~5 分钟的抖动让过期时间分散开避免同时失效。4.4 打包部署与上线环境部署方案我用了经典的 Docker Compose 编排一套脚本同时拉起 MySQL、Redis、MinIO、Spring Boot 应用、Nginx 前端。启动脚本里最关键的一点是等待数据库初始化完成否则应用启动时连不上库直接退出version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ${DB_PASSWORD} MYSQL_DATABASE: supermarket volumes: - ./mysql-data:/var/lib/mysql app: build: . depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/supermarket ports: - 8080:8080上线前除了检查配置还要注意两件事。第一件是 JVM 内存参数超市高峰期交易量不小我设置了-Xms512m -Xmx1024m -XX:UseG1GC并根据实际监控再调整。第二件是日志收集我把应用日志统一输出到 JSON 格式并接入日志平台出了线上问题可以快速检索订单号对应的完整链路。5. 写在最后的实操建议整个项目从零到现在跑通最深的体会是Spring Boot 只是起点业务才是真正的护城河。网上随手能搜到的 CRUD 模板帮不了你处理库存锁定、促销叠加、报表性能这些问题这些场景必须靠着对超市业务流程的深入理解去设计解决方案。给准备做类似系统的开发者几个建议。第一数据库设计一定要按“商品、库存、订单、财务”四条主链路去梳理先画链路图再建表千万不要边写接口边加表。第二权限设计宁可前期多做一点也不能偷懒尤其是数据权限后面补远比前面做难。第三所有和钱、库存相关的操作一定要加事务、加锁、加操作日志缺一个早晚出事。第四缓存不是银弹先想清楚数据一致性要求再决定哪里放缓存。最后分享一个小技巧交易类的高频接口在响应体里统一包一层带 traceId 的结果对象排查问题直接按 traceId 去查日志能省掉非常多沟通成本。这套系统后续我还会继续扩展移动端、供应商协同和自动化盘点模块希望这篇记录能给正在做类似项目的人提供一点参考。
