基于springBoot企业级进销存ERP系统源码 java源码
Spring Boot的企业级进销存系统开发中，最让人头疼的不是功能实现，而是如何在高并发场景下保证库存数据的准确性。去年我们团队重构老系统时，曾在促销活动中出现过库存超卖500件的重大事故——就因为这个契机，我们彻底重构了库存模块。
先看一个典型的库存扣减场景。常规做法是在数据库执行update stock set quantity=quantity-? where sku_id=?，但当QPS超过2000时，数据库连接池直接被打满。后来我们引入Redis+Lua脚本做预扣减：
// 库存扣减Lua脚本 String script = "local current = redis.call('get', KEYS[1])\n" + "if current and tonumber(current) >= tonumber(ARGV[1]) then\n" + " return redis.call('decrby', KEYS[1], ARGV[1])\n" + "end\n" + "return -1"; // 执行脚本 Long result = redisTemplate.execute( new DefaultRedisScript<>(script, Long.class), Collections.singletonList("stock:" + skuId), String.valueOf(quantity) ); if(result == null || result <0){ throw new BizException("库存不足"); }这里有个坑：Redis扣减成功后必须记录预扣日志，否则系统重启会导致数据不一致。我们在MySQL设计了stock_precut表，通过定时任务同步预扣数据到正式库存表。这种异步处理让库存吞吐量提升了8倍。
订单模块的分表策略也值得一说。订单号生成规则采用雪花算法+业务前缀：
public class OrderNoGenerator { // 雪花实例放在ThreadLocal避免线程竞争 private static final ThreadLocal<Snowflake> snowflake = ThreadLocal.withInitial( () -> new Snowflake(workerId(), datacenterId()) ); public static String gen() { return "DD" + LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE) + snowflake.get().nextId(); } // 根据IP末两位生成workerId private static long workerId() {...} }订单号包含日期前缀，配合ShardingSphere的分片算法YYYYMM % 64，实现按月分表的同时均匀分布数据。查询最近订单时只需访问当前月份分片，历史订单走归档库，避免全表扫描。
基于springBoot企业级进销存ERP系统源码 java源码
权限系统最容易过度设计。我们采用RBAC模型但做了简化：
@PostMapping("/api/**") @PreAuthorize("@permCheck.hasPermission('{httpMethod}', '{requestURI}')") public ResponseEntity<?> genericApi() {...} // 权限校验Bean @Component public class PermCheck { public boolean hasPermission(String method, String uri) { // 从Redis获取用户角色对应的权限列表 Set<String> perms = getUserPerms(SecurityUtils.getUserId()); return perms.contains(buildPermKey(method, uri)); } private String buildPermKey(String method, String uri) { return method.toUpperCase() + ":" + uri.replaceAll("/\\d+", "/*"); } }这种动态权限匹配机制，配合注解实现方法级控制。正则替换路径参数为通配符，让权限配置更灵活。比如配置POST:/api/orders即可控制所有订单创建请求。
系统监控方面，我们在关键链路上植入埋点：
@Around("@annotation(com.erp.monitor.ApiMetric)") public Object metric(ProceedingJoinPoint joinPoint) throws Throwable { String metricName = getMetricName(joinPoint); MetricRegistry.timer(metricName).time(() -> { try { return joinPoint.proceed(); } finally { // 异常统计 if(e != null) { MetricRegistry.meter(metricName+".error").mark(); } } }); }结合Grafana看板，能实时发现某个接口的TP99异常上涨。曾经通过这个监控发现物流接口超时导致订单积压，及时切换备用通道避免了客诉。
源码中最大的惊喜是库存调整的版本控制实现。采用MyBatis的乐观锁插件：
<update id="updateStock"> UPDATE product_stock SET quantity=#{quantity}, version=version+1 WHERE sku_id=#{skuId} AND version=#{version} </update> // 重试策略 @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 100)) public void adjustStock(Long skuId, int delta) { Stock stock = stockMapper.selectForUpdate(skuId); stock.setQuantity(stock.getQuantity() + delta); int rows = stockMapper.updateStock(stock); if(rows == 0) { throw new OptimisticLockException("库存版本冲突"); } }结合Spring Retry实现自动重试，在保证数据一致性的前提下，比传统悲观锁性能提升40%。但要注意重试次数不宜过多，否则会引发线程阻塞。
这套源码的价值不仅在于实现标准ERP功能，更在于处理了企业级应用的真实痛点——比如分布式事务使用Seata的AT模式解决跨服务库存扣减，审计日志通过EntityListener自动记录修改人，这些设计都让系统更贴合实际生产需求。建议重点研究其异常处理机制，比如使用Hystrix做资源隔离防止雪崩，这对构建高可用系统至关重要。
