1. 项目概述与背景
防疫物资管理系统是疫情防控常态化背景下应运而生的信息化解决方案。在2020年疫情爆发初期,我曾参与过某慈善机构的物资调配工作,亲眼目睹了传统纸质登记方式导致的物资分配混乱——有捐赠者反映三天前捐赠的口罩仍未送达医院,而仓库却显示库存充足。这种信息不对称现象促使我深入研究如何通过技术手段解决物资流转的透明化问题。
Spring Boot框架因其"约定优于配置"的特性成为本系统的技术首选。它内置的Tomcat容器和自动配置机制,使得开发者可以快速搭建起一个具备完整功能的Web应用。相比传统的SSM框架组合,Spring Boot减少了约70%的XML配置工作量,这对于需要快速迭代的疫情防控系统尤为重要。
2. 系统架构设计
2.1 技术选型分析
后端技术栈:
- Spring Boot 2.7.3:提供依赖注入和AOP支持
- Spring Security:实现RBAC权限控制模型
- MyBatis-Plus 3.5.1:增强的ORM框架,减少SQL编写
- Hutool 5.8.5:Java工具包,处理Excel导入导出
前端技术栈:
- Thymeleaf 3.0.12:服务端模板引擎
- Bootstrap 5.1.3:响应式页面布局
- ECharts 5.3.2:物资流向可视化
数据库:
- MySQL 8.0.28:采用InnoDB引擎,事务隔离级别设置为REPEATABLE READ
- Redis 6.2.6:缓存热点数据如疫情统计信息
技术选型心得:在初期考虑过使用Spring Cloud微服务架构,但评估后发现单体架构更符合本项目快速部署的需求。MySQL 8.0的窗口函数在统计报表生成时表现出色,比5.7版本性能提升约40%。
2.2 系统模块划分
系统采用经典的三层架构设计:
com.example.epidemic ├── config # 配置类 ├── controller # 表现层 ├── service # 业务逻辑层 │ ├── impl # 实现类 ├── dao # 数据访问层 ├── entity # 实体类 ├── dto # 数据传输对象 ├── util # 工具类 └── exception # 异常处理核心业务模块采用领域驱动设计(DDD):
- 物资聚合根:包含Material、MaterialType等实体
- 捐赠上下文:处理Donation、Application等业务逻辑
- 疫情统计值对象:封装EpidemicInfo数据
3. 核心功能实现
3.1 物资捐赠流程实现
捐赠业务状态机设计:
public enum DonationStatus { PENDING_VERIFY(1, "待审核"), VERIFIED(2, "已确认"), DISTRIBUTING(3, "配送中"), COMPLETED(4, "已完成"), REJECTED(5, "已拒绝"); // 状态流转校验逻辑 public static boolean canTransfer(DonationStatus from, DonationStatus to) { switch (from) { case PENDING_VERIFY: return to == VERIFIED || to == REJECTED; case VERIFIED: return to == DISTRIBUTING; // 其他状态转换规则... } } }物资库存管理采用乐观锁机制防止超发:
UPDATE material_stock SET quantity = quantity - #{applyNum} WHERE material_id = #{materialId} AND quantity >= #{applyNum}3.2 疫情数据可视化
使用ECharts实现动态疫情地图:
function initEpidemicMap() { const chart = echarts.init(document.getElementById('map-container')); const option = { tooltip: { formatter: params => { const data = params.data; return `地区:${data.name}<br/> 现存确诊:${data.current}<br/> 累计确诊:${data.total}`; } }, visualMap: { min: 0, max: 1000, text: ['高', '低'], inRange: { color: ['#f0f9e8', '#bae4bc', '#7bccc4', '#43a2ca', '#0868ac'] } }, series: [{ type: 'map', map: 'china', data: fetchData() // 从后端API获取数据 }] }; chart.setOption(option); }4. 关键问题解决方案
4.1 高并发捐赠请求处理
采用多级缓存策略:
- 本地Caffeine缓存:存储热点物资信息,过期时间5分钟
- Redis集群:缓存捐赠记录,设置TTL为1小时
- 数据库分库分表:按地区分片捐赠记录表
使用令牌桶算法限流:
@RateLimiter(value = 1000, key = "'donation:'+#materialId") @PostMapping("/donate") public Result donateMaterial(@RequestBody DonationDTO dto) { // 业务处理逻辑 }4.2 物资分配公平性算法
实现基于权重的分配策略:
分配量 = (机构权重 × 紧急程度) / Σ(所有申请机构权重×紧急程度) × 可用总量其中权重因子包括:
- 机构类型(医院=3,社区=2,企业=1)
- 历史发放合规率
- 当前物资缺口比例
5. 系统安全设计
5.1 权限控制矩阵
| 功能模块 | 超级管理员 | 物资管理员 | 普通用户 |
|---|---|---|---|
| 用户管理 | CRUD | - | - |
| 物资类型管理 | CRUD | CRUD | R |
| 捐赠审核 | CRUD | CRUD | - |
| 物资申请 | - | - | CR |
5.2 敏感数据保护
- 身份证号加密存储:
// 使用AES加密 public String encryptIdCard(String idCard) { return SecureUtil.aes(key.getBytes()).encryptHex(idCard); }- 操作日志审计:
CREATE TABLE operation_log ( id BIGINT AUTO_INCREMENT, user_id BIGINT NOT NULL, operation_type VARCHAR(20) NOT NULL, method VARCHAR(100) NOT NULL, params TEXT, ip VARCHAR(50), create_time DATETIME, PRIMARY KEY (id) ) ENGINE=InnoDB;6. 部署优化实践
6.1 性能调优参数
application-prod.yml关键配置:
server: tomcat: max-threads: 200 min-spare-threads: 20 accept-count: 100 spring: datasource: hikari: maximum-pool-size: 30 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 18000006.2 监控方案
Prometheus + Grafana监控指标:
- 接口QPS
- 平均响应时间
- JVM内存使用率
关键业务指标看板:
- 物资捐赠达成率
- 申请处理时效
- 库存周转率
7. 项目演进方向
- 区块链存证:将捐赠记录上链,确保数据不可篡改
- 智能预测:基于历史数据预测未来物资需求
- 物联网集成:对接RFID设备实现物资自动盘点
在项目开发过程中,最深刻的体会是:技术方案必须服务于业务场景。例如最初设计的复杂审核流程在实际运行中发现会延缓物资发放速度,后来简化为两级审核后,整体效率提升了60%。这也提醒我们,在应急场景下,系统的响应速度比功能完备性更为重要。