基于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做资源隔离防止雪崩，这对构建高可用系统至关重要。