Java物资采购管理系统设计与高并发优化实践

1. 项目背景与核心需求

去年帮学校开发防疫物资管理系统时，我深刻体会到传统采购方式的痛点：教务处老师需要手动统计各学院需求，电话联系供应商比价，Excel表格传来传去经常出现版本混乱。特别是疫情紧张时期，口罩、消毒液等物资的调配经常出现信息滞后，导致部分学院库存积压而另一些学院却物资紧缺。

这个基于Java的物资采购管理系统正是为了解决这些实际问题而设计。系统采用B/S架构，前端使用主流的Vue.js+ElementUI组合，后端基于Spring Boot框架，数据库选用MySQL 8.0。整个系统围绕物资采购全生命周期设计，包含12个核心功能模块，从供应商管理、物资展示到订单跟踪、物流监控形成完整闭环。

关键设计原则：确保高并发场景下的系统稳定性，采购高峰期预计每分钟需处理300+订单；实现端到端操作留痕，满足审计要求；预留API接口方便与现有OA系统对接。

2. 技术架构设计解析

2.1 整体技术栈选型

后端采用Spring Boot 2.7 + MyBatis Plus组合，相比传统SSM框架：

• 启动时间缩短40%（实测从8s降至4.8s）
• 配置文件减少60%
• 内置Tomcat 9.0支持200+并发连接

数据库选择MySQL 8.0而非5.7版本，主要考虑：

1. 窗口函数简化物资库存趋势分析
2. JSON字段便于存储物流动态信息
3. 原子DDL操作降低系统升级风险

前端技术栈对比：

2.2 高并发场景设计

针对采购高峰期的系统优化方案：

1. 使用Redis缓存热点物资数据（如口罩、消毒液）

   java复制@Cacheable(value = "hotItems", key = "#categoryId")
   public List<Material> getHotMaterials(Integer categoryId) {
       return materialMapper.selectHotList(categoryId);
   }
   

2. 订单服务采用分布式锁防止超卖：

   java复制public boolean placeOrder(Order order) {
       String lockKey = "material_" + order.getMaterialId();
       try {
           Boolean locked = redisTemplate.opsForValue()
               .setIfAbsent(lockKey, "locked", 30, TimeUnit.SECONDS);
           if(locked) {
               // 扣减库存逻辑
           }
       } finally {
           redisTemplate.delete(lockKey);
       }
   }
   

3. 数据库读写分离，查询走从库

3. 核心功能实现细节

3.1 智能采购推荐模块

传统采购系统只是简单展示物资列表，我们增加了智能推荐算法：

1. 基于用户历史采购记录计算相似度
2. 结合当前库存预警级别（红色/黄色/绿色）
3. 参考近期同类机构采购趋势

核心算法实现：

java复制public List<Material> recommendMaterials(Long userId) {
    // 获取用户历史采购特征向量
    double[] userVector = getUserFeatureVector(userId); 
    
    // 获取物资特征矩阵
    List<Material> materials = materialMapper.selectAll();
    Map<Long, double[]> itemVectors = new HashMap<>();
    
    // 计算余弦相似度
    materials.sort((m1, m2) -> {
        double sim1 = cosineSimilarity(userVector, itemVectors.get(m1.getId()));
        double sim2 = cosineSimilarity(userVector, itemVectors.get(m2.getId()));
        return Double.compare(sim2, sim1);
    });
    
    return materials.subList(0, Math.min(5, materials.size()));
}

3.2 物流实时追踪方案

为解决传统物流信息更新延迟问题，我们设计了三层更新机制：

1. 供应商端：扫描快递单号后自动同步到系统
2. 物流公司API：每小时自动获取最新轨迹
3. 收件人确认：签收时二次验证

物流状态机设计：

code复制[待发货] → [已发货] → [运输中] → [配送中] 
           ↑               ↓
        [退货中] ← [已签收]

4. 数据库优化实践

4.1 关键表结构设计

物资表核心字段优化：

sql复制CREATE TABLE `material` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `code` VARCHAR(20) NOT NULL COMMENT '物资编码规则：分类+日期+序号',
  `name` VARCHAR(100) NOT NULL,
  `category_id` INT NOT NULL,
  `specification` JSON COMMENT '存储JSON格式的规格参数',
  `stock` INT NOT NULL DEFAULT 0,
  `safety_stock` INT COMMENT '安全库存阈值',
  `price` DECIMAL(10,2) NOT NULL,
  `supplier_id` BIGINT NOT NULL,
  `status` TINYINT DEFAULT 1 COMMENT '0-下架 1-正常',
  `version` INT DEFAULT 0 COMMENT '乐观锁版本号',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_code` (`code`),
  KEY `idx_category` (`category_id`),
  KEY `idx_supplier` (`supplier_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

4.2 查询性能优化案例

物资列表页的慢查询优化过程：

1. 原始SQL（执行时间1.2s）：

   sql复制SELECT * FROM material 
   WHERE category_id = 5 
   AND status = 1
   ORDER BY create_time DESC;
   

2. 优化方案：

   • 添加复合索引：(category_id, status, create_time)
   • 改用分页查询
   • 只返回必要字段

3. 优化后SQL（执行时间68ms）：

   sql复制SELECT id,code,name,price,stock 
   FROM material 
   WHERE category_id = 5 
   AND status = 1
   ORDER BY create_time DESC
   LIMIT 0, 10;
   

5. 部署与运维实战

5.1 服务器配置建议

根据压力测试结果给出的配置方案：

5.2 监控指标配置

必须监控的5个关键指标：

1. 订单创建成功率（阈值>99.5%）
2. 平均响应时间（阈值<1.5s）
3. 数据库连接池使用率（阈值<80%）
4. JVM老年代GC频率（阈值<1次/小时）
5. 磁盘IO等待时间（阈值<20ms）

Prometheus配置示例：

yaml复制- job_name: 'material_app'
  metrics_path: '/actuator/prometheus'
  static_configs:
    - targets: ['192.168.1.100:8080']

6. 典型问题排查记录

6.1 订单超卖问题

现象：促销活动期间出现库存减为负数
排查过程：

1. 检查日志发现多个线程同时扣减同一商品
2. 原代码缺少并发控制：

   java复制// 错误实现
   int stock = material.getStock();
   if(stock >= orderNum) {
       material.setStock(stock - orderNum);
       materialMapper.updateById(material);
   }
   

解决方案：

1. 数据库加乐观锁：

   sql复制UPDATE material 
   SET stock = stock - #{num}, 
       version = version + 1 
   WHERE id = #{id} AND version = #{version}
   

2. 引入Redis分布式锁（见2.2节代码）

6.2 物流信息延迟

现象：部分订单物流状态更新滞后
根本原因：

1. 第三方API调用超时设置不合理（默认2s）
2. 没有重试机制
3. 消息队列积压

优化措施：

1. 增加超时时间到10s
2. 加入指数退避重试：

   java复制@Retryable(maxAttempts=3, backoff=@Backoff(delay=1000, multiplier=2))
   public void syncLogistics(String orderNo) {
       // 调用物流API
   }
   

3. 升级RabbitMQ配置

7. 开发经验总结

1. 物资编码生成避坑：

   • 不要使用数据库自增ID作为对外编码
   • 推荐格式：分类(2位)+日期(6位)+序列号(4位)
   • 示例：KF202305150023（口罩类2023年5月15日第23笔）

2. 库存变更必须记录操作日志：

   sql复制CREATE TABLE `inventory_log` (
     `id` BIGINT NOT NULL AUTO_INCREMENT,
     `material_code` VARCHAR(20) NOT NULL,
     `before_quantity` INT NOT NULL,
     `change_quantity` INT NOT NULL COMMENT '正数表示入库',
     `after_quantity` INT NOT NULL,
     `operator` VARCHAR(50) NOT NULL,
     `operate_time` DATETIME NOT NULL,
     `biz_no` VARCHAR(50) COMMENT '关联业务单号',
     PRIMARY KEY (`id`),
     KEY `idx_material` (`material_code`),
     KEY `idx_time` (`operate_time`)
   );
   

3. 接口设计原则：

   • 创建类接口返回完整资源对象
   • 更新类接口返回变更字段
   • 查询类接口必须支持分页
   • 删除类接口返回操作结果状态

这个项目让我深刻体会到，一个好的管理系统不仅要功能完备，更需要从实际业务场景出发，解决用户的真实痛点。特别是在应急物资管理领域，系统的稳定性和实时性直接关系到防疫工作的效率。在后续迭代中，我们计划加入智能预测功能，通过历史数据预测未来物资需求，让采购工作更加精准高效。