简介基于SSM框架的物流配送管理系统设计与实现.docx是一份面向高校毕业设计、课程设计及企业物流信息化项目开发者的完整设计文档。内容以中国联通秦皇岛分公司与上海德邦物流的合作优化为背景从经济、技术可行性分析入手完成用户需求梳理后提出基于J2EE平台、采用SpringStrutsMybatis三层框架、客户端界面使用Extjs4.0的系统设计方案。文档详细说明了用户系统管理、客服中心、配送管理、库房管理、调度管理、车辆信息管理六大功能模块及其子模块的设计与实现覆盖客户下单、员工管理、订单查询与完善、订单配送、出入库和库房信息维护、调度优化、车辆状态与历史记录管理等场景同时给出客户、员工、部门、订单、库房、调拨、车辆等核心数据库表设计并记录了系统界面与性能测试结果。资源包仅含1个docx文档大小约9KB内容精炼。已有354人学习适合需要参考SSM框架项目架构、模块划分、数据库设计或论文写作结构的读者。1. 物流配送管理系统为什么值得从 SSM 框架入手接触物流配送系统的第一周最容易被卡住的往往不是业务算法而是 SSM 框架里的容器边界和事务边界。运单状态在多个表之间流转司机接单存在并发冲突轨迹数据持续写入Spring、Spring MVC、MyBatis 三者只要有一个配置错位线上就会出现“接口通了但数据没变”“状态能跳但查不到操作记录”这类问题。“基于 SSM 框架的物流配送管理系统设计与实现”这个标题看起来像课堂项目拆开来看要解决的事情并不少先要有一套合理的运单数据模型然后把配送流程抽象成状态机最后用 Spring 的事务和 MyBatis 的条件更新保证数据不打架。这个系统适合用来理解 Java Web 后台从骨架到上线的完整路径也适合作为内部配送管理后台的起点。2. SSM 项目骨架搭建与 Spring 容器配置2.1 SSM 的组件边界与选型理由很多团队第一次把 SSM 项目跑起来后会发现Transactional不生效、ResponseBody返回 406 或者 Mapper Bean 找不到。这些问题大多不是代码逻辑问题而是没有搞清楚 SSM 三个框架各自的职责。Spring 负责对象创建、依赖注入和事务管理是整个应用的大管家Spring MVC 负责接收 HTTP 请求、参数绑定和返回视图或 JSONMyBatis 负责数据库访问SQL 写在 Mapper XML 里由 Spring 管理 SqlSession 的生命周期。在物流配送系统里这种分层带来的直接收益是问题定位变得直观接口返回异常查 Controller状态更新错乱查 Service 和 Mapper连接池满了查 Druid 配置。为什么不直接上 Spring Boot如果是在现有 SSM 项目上做迭代重新搭一套 Boot 环境反而增加迁移成本。新项目当然可以选 Boot但物流配送这类数据模型稳定、查询条件固定的管理系统用 SSM 并不慢而且 XML 格式的 SQL 在复杂报表场景里更容易做版本对比和走查。选型时的关键是明确 Spring 父容器和 Spring MVC 子容器的扫描范围否则后面会踩很多隐性坑。容器负责内容典型配置Spring 父容器数据源、事务管理器、SqlSessionFactory、Service、MapperapplicationContext.xmlSpring MVC 子容器Controller、HandlerMapping、拦截器、视图解析器、消息转换器spring-mvc.xml2.2 用 Maven 把 SSM 框架依赖一次配齐搭建 SSM 骨架时我一般不会在 pom 里把三个框架拆开单独管版本而是统一用属性占位由团队维护一份版本基线。下面是一份可落地的依赖集合覆盖了 Web、JDBC、MyBatis、Druid、Jackson 和 Servlet API。properties spring.version5.3.x/spring.version mybatis.version3.5.x/mybatis.version mybatis-spring.version2.1.x/mybatis-spring.version druid.version1.2.x/druid.version mysql.version8.0.x/mysql.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-jdbc/artifactId version${spring.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version${mybatis.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version${mybatis-spring.version}/version /dependency dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version${druid.version}/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version${mysql.version}/version /dependency dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId scopeprovided/scope /dependency dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.13.x/version /dependency /dependencies这里有两个容易忽略的细节。spring-jdbc提供了DataSourceTransactionManager如果只引入spring-webmvc事务管理器的 class 会找不到javax.servlet-api必须用providedscope否则会和 Tomcat 自带的 Servlet 实现冲突。数据源方面Druid 适合 SSM 传统项目因为它自带监控页面和慢 SQL 统计省去额外搭监控组件的成本。连接参数我习惯放到jdbc.properties不让数据源配置散落在 Spring XML 里。jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/logistics?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.passwordyourpassword druid.initialSize2 druid.maxActive20 druid.maxWait60000initialSize是启动时预创建的连接数maxActive是最大活跃连接数maxWait是获取连接的超时时间。配送系统在晚高峰会有大量司机刷新运单列表maxWait设置过短会出现大量连接获取异常设置过长会让请求堆积在线程池里建议从 60 秒开始调。2.3 让 Spring 与 Spring MVC 各司其职的关键配置SSM 的 web.xml 只需要做两件事让 ContextLoaderListener 加载 Spring 父容器让 DispatcherServlet 加载 Spring MVC 子容器。context-param param-namecontextConfigLocation/param-name param-valueclasspath:applicationContext.xml/param-value /context-param listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-valueclasspath:spring-mvc.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern//url-pattern /servlet-mappingload-on-startup设置为 1让应用启动时立即初始化 DispatcherServlet而不是等第一个请求进来才加载。url-pattern使用/把包括静态资源在内的所有请求都交给 Spring MVC 路由。spring-mvc.xml 里的核心是扫描边界和注解驱动。context:component-scan base-packagecom.example.logistics.controller/ mvc:annotation-driven/ bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/views// property namesuffix value.jsp/ /beancomponent-scan 只扫 controller 包不扫 service。mvc:annotation-driven负责注册 RequestMappingHandlerAdapter、Jackson 消息转换器等组件缺少它时ResponseBody返回对象会直接走进 ViewResolver表现为接口返回的是一串视图路径或者直接报 406。提示在同一个应用里spring-mvc.xml 不要为省事把 service 包也扫进去否则 Spring 父容器和 Spring MVC 子容器会创建两套 Service事务代理可能只挂在其中一套上调用接口时会出现“查询正常但更新不提交”的诡异问题。3. 物流配送核心表设计与 MyBatis 持久层实现3.1 运单主表设计字段类型和索引取舍配送域的核心实体是运单不是订单。订单来自上游业务运单才属于配送流程。设计表时要先区分哪些字段会被频繁更新哪些字段只读。运单表中的status、driver_id、update_time是高频更新字段waybill_no、create_time是高频查询字段。下面是配送系统最基础的运单表结构。CREATE TABLE delivery_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, waybill_no VARCHAR(32) NOT NULL COMMENT 运单号, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待分配 1-已分配 2-运输中 3-已签收 4-异常, sender_name VARCHAR(64), sender_phone VARCHAR(20), receiver_name VARCHAR(64), receiver_phone VARCHAR(20), driver_id BIGINT DEFAULT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_waybill_no (waybill_no), KEY idx_status_create (status, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;关键字段说明如下字段类型设计原因waybill_noVARCHAR(32)业务唯一键独立唯一索引statusTINYINT状态值少存储小适合做组合索引前缀driver_idBIGINT分配后才写入可空不单独建索引create_timeDATETIME列表页按时间倒序常用加入组合索引update_timeDATETIME配合ON UPDATE自动维护便于排查状态变更时间status使用 TINYINT 而不是 VARCHAR是因为状态变化在 Java 代码里有枚举定义数据库只需要存枚举对应的 code。TINYINT 在高并发更新时占用的锁空间更小索引页能容纳更多行。idx_status_create这个组合索引直接服务列表页的典型查询按状态过滤再按创建时间倒序。如果只有单列索引MySQL 通常只能用到 status 列排序动作会额外触发 filesort。3.2 MyBatis Generator 生成基础代码的合理范围SSM 项目里使用 MyBatis Generator 生成实体、Mapper 接口和基础 XML 是常见做法但要注意控制生成范围。生成器生成的代码适合做单表增删改查不适合承载业务关联查询。我在 generatorConfig.xml 里一般只配置 JavaModelGenerator、SqlMapGenerator 和 JavaClientGenerator不生成 Service。Maven 插件配置如下。plugin groupIdorg.mybatis.generator/groupId artifactIdmybatis-generator-maven-plugin/artifactId version1.4.x/version configuration configurationFile${basedir}/src/main/resources/generatorConfig.xml/configurationFile overwritetrue/overwrite verbosetrue/verbose /configuration /plugin执行生成命令mvn mybatis-generator:generate生成完成后我建议立刻把overwrite改回false。因为生成器再次运行会覆盖 XML 中手写的 SQL如果一个项目里多个成员同时在扩展同一个 Mapper覆盖的后果很麻烦。生成的 Example 类不是不能用而是不要滥用。criteria.andEqualTo拼接起来确实很方便但复杂条件组合多了之后SQL 执行计划很可能走偏索引选择变得不可控。管理后台的简单筛选可以用 Example配送链路里的状态更新、轨迹插入和分页查询建议手写 SQL。3.3 手写 Mapper SQL 的三个高频写法配送系统里最常手写的 SQL 有三类条件更新、批量插入、动态列表查询。条件更新运单状态时用set标签自动处理逗号。update idupdateStatusById parameterTypemap UPDATE delivery_order set if testnewStatus ! null status #{newStatus}, /if if testdriverId ! null driver_id #{driverId}, /if update_time NOW() /set WHERE id #{id} /updateNOW()由数据库生成时间避免多个应用实例服务器时间不一致导致状态更新时间漂移。这个 update 方法只做普通更新不做状态条件校验因此只适合在 Service 层已经校验过状态流转的场景中使用。配送轨迹表需要批量写入否则在途节点多时容易产生大量单条 INSERT。insert idbatchInsertTrace parameterTypelist INSERT INTO delivery_trace (waybill_no, op_type, op_desc, operator, create_time) VALUES foreach collectionlist itemtrace separator, (#{trace.waybillNo}, #{trace.opType}, #{trace.opDesc}, #{trace.operator}, NOW()) /foreach /insertforeach的 separator 用逗号把多条记录拼进一条 INSERT。批量写入时要注意 MySQL 对 SQL 语句大小和参数数量的限制单批建议控制在 200 到 500 条超过后拆成多批。列表查询要处理动态筛选条件分页由应用层传入 offset 和 size。select idselectPageByStatus resultTypecom.example.logistics.entity.DeliveryOrder SELECT id, waybill_no, order_no, status, driver_id, create_time FROM delivery_order where if teststatus ! null AND status #{status} /if if testdriverId ! null AND driver_id #{driverId} /if /where ORDER BY create_time DESC LIMIT #{offset}, #{limit} /select分页参数由 Service 层计算offset (page - 1) * size。如果使用 PageHelper要清楚它基于 ThreadLocal 生效只对紧接着的一条查询起作用在异步线程或批量循环里容易误伤其他 SQL我一般不用。4. 配送状态机与并发接单的实现4.1 状态机如何映射到 Service 代码配送流程可以简化为四个核心状态待分配、已分配、运输中、已签收。每个状态能跳转到哪里必须事先确定。当前状态允许转变到待分配已分配、异常已分配运输中、异常运输中已签收、异常已签收无状态表在 Java 代码里用枚举表达。public enum DeliveryStatus { WAIT_ASSIGN(0, 待分配), ASSIGNED(1, 已分配), TRANSPORTING(2, 运输中), SIGNED(3, 已签收), EXCEPTION(4, 异常); private final int code; private final String desc; DeliveryStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }状态机不一定非要引入框架。Spring Statemachine 在状态分支多、事件复杂的场景下有价值但配送流程只有四五个状态再套一层框架会让新成员看代码时要跳好几层配置。我比较推荐用枚举定义状态然后在一个 Service 里收口所有状态变更入口。签收操作的 Service 方法如下。Transactional(rollbackFor Exception.class) public void signOrder(Long orderId, String operator) { DeliveryOrder order deliveryOrderMapper.selectByPrimaryKey(orderId); if (!DeliveryStatus.TRANSPORTING.getCode().equals(order.getStatus())) { throw new BusinessException(当前状态不支持签收); } deliveryOrderMapper.updateStatusById(orderId, DeliveryStatus.SIGNED.getCode(), null); deliveryTraceService.record(order.getWaybillNo(), SIGN, operator); }在 Service 层先查一次状态再执行更新这种做法能挡掉大部分非法操作但存在时间窗口。两个请求同时读到运输中状态理论上都能通过校验。要彻底避免并发问题需要依赖数据库层面的条件更新。4.2 接单接口的乐观锁与事务边界司机接单是并发场景最集中的操作。同一个运单不能被两个司机同时接走这是典型的行级竞争问题。常见做法是使用乐观锁条件更新。Mapper 接口中定义带状态条件的方法。int casUpdateStatus(Param(orderId) Long orderId, Param(oldStatus) Integer oldStatus, Param(newStatus) Integer newStatus, Param(driverId) Long driverId);对应 XML 写条件更新。update idcasUpdateStatus UPDATE delivery_order SET status #{newStatus}, driver_id #{driverId}, update_time NOW() WHERE id #{orderId} AND status #{oldStatus} /updateService 层调用该方法通过影响行数判断是否抢单成功。Transactional(rollbackFor Exception.class) public void acceptOrder(Long orderId, Long driverId) { int updated deliveryOrderMapper.casUpdateStatus( orderId, DeliveryStatus.WAIT_ASSIGN.getCode(), DeliveryStatus.ASSIGNED.getCode(), driverId ); if (updated 0) { throw new BusinessException(运单已被其他司机接走请刷新列表); } deliveryTraceService.record(orderId, ACCEPT, driverId); }WHERE status #{oldStatus}是并发控制的核心。数据库在更新时会对命中的行加锁两个并发请求同时执行这条 UPDATE只有一个会匹配到旧状态并成功更新另一个影响行数为 0由代码主动抛出业务异常。这里不需要SELECT ... FOR UPDATE因为条件更新本身已经完成了行锁不需要再额外持有一把读锁。事务边界要注意状态更新和轨迹插入必须放在同一个事务里。要么状态变了轨迹也记上要么全部回滚不能出现运单显示已接单但轨迹查不到操作记录的脏状态。方法上的Transactional(rollbackFor Exception.class)把casUpdateStatus和record放在同一个事务中任何异常都会回滚。4.3 定时扫描与自动分单的线程配置配送系统里总有一部分运单长时间没有司机接单需要在后台定时扫描并重新分配。常见做法是使用 Spring 的Scheduled注解。Component public class DeliveryTimeoutJob { Scheduled(fixedDelay 5000) public void processTimeoutWaybill() { ListLong timeoutIds deliveryOrderMapper.selectTimeoutIds(30); for (Long orderId : timeoutIds) { deliveryOrderService.autoReassign(orderId); } } }fixedDelay 5000表示上一次任务执行完成后间隔 5 秒再执行下一次。如果使用fixedRate则按固定频率触发任务执行时间过长时会累计等待导致线程阻塞。Scheduled默认是单线程执行。一个应用里只要有两个定时任务就会互相排队。其中一个任务访问数据库慢另一个任务可能延迟十几秒。需要在 Spring 配置里增加调度线程池。task:scheduler idlogisticsScheduler pool-size4/ task:annotation-driven schedulerlogisticsScheduler/pool-size根据业务量设置配送系统后台定时任务不多4 个线程足够。autoReassign内部要避免在大循环里频繁更新同一条记录可以先批量查出超时运单再按司机在线状态批量分配最后逐条写入分配结果减少数据库往返。5. 上线前把 SSM 应用调稳的验证手段5.1 用 Druid 慢 SQL 监控抓住索引缺失SSM 项目接入 Druid 监控的成本很低。在 web.xml 中注册 Druid 的 WebStatFilter 和 StatViewServlet启动后就可以通过/druid/sql.html查看 SQL 执行次数、耗时和并发情况。在 Druid 数据源配置中加上慢 SQL 过滤参数bean idstatFilter classcom.alibaba.druid.filter.stat.StatFilter property nameslowSqlMillis value1000/ property namelogSlowSql valuetrue/ /beanslowSqlMillis设置 1000 毫秒超过阈值的 SQL 会记录到日志并出现在监控页。上线后先看执行次数高的查询再看平均耗时。如果运单列表页慢用EXPLAIN查看执行计划重点看type列是否为ref或rangekey列是否真正用了idx_status_create。很多慢查询并不是 SQL 写错而是SELECT *返回了过多字段MySQL 不得不做回表或者排序。5.2 用 Spring Test 与 MockMvc 覆盖并发接单SSM 项目的 Service 层测试可以直接加载 Spring 容器来验证事务和状态流转。RunWith(SpringJUnit4ClassRunner.class) ContextConfiguration(locations {classpath:applicationContext.xml}) public class DeliveryOrderServiceTest { Autowired private DeliveryOrderService deliveryOrderService; Test(expected BusinessException.class) public void acceptTwice_shouldThrow() { deliveryOrderService.acceptOrder(1001L, 10L); deliveryOrderService.acceptOrder(1001L, 11L); } }这个测试验证的是第二次接单因为casUpdateStatus影响行数为 0 而抛出异常第一次接单成功后第二次不能覆盖原来的司机。它没有真正模拟多线程但能保证状态分支逻辑的正确性。Controller 层用 MockMvc 验证接口参数绑定和返回结构。mockMvc.perform(post(/order/accept) .param(orderId, 1001) .param(driverId, 10)) .andExpect(status().isOk()) .andExpect(jsonPath($.code).value(0));测试库要尽量用真实 MySQL不要用 H2。H2 对UPDATE影响行数的判断、隐式类型转换和主键生成行为与 MySQL 不完全一致容易把并发问题掩盖掉。SSM 项目里手写 SQL 和生成器 SQL 混用只有在真实数据库上跑过回归上线时才敢放心。本文还有配套的精品资源点击获取 SSM框架在物流配送管理系统中的核心设计与实践
简介基于SSM框架的物流配送管理系统设计与实现.docx是一份面向高校毕业设计、课程设计及企业物流信息化项目开发者的完整设计文档。内容以中国联通秦皇岛分公司与上海德邦物流的合作优化为背景从经济、技术可行性分析入手完成用户需求梳理后提出基于J2EE平台、采用SpringStrutsMybatis三层框架、客户端界面使用Extjs4.0的系统设计方案。文档详细说明了用户系统管理、客服中心、配送管理、库房管理、调度管理、车辆信息管理六大功能模块及其子模块的设计与实现覆盖客户下单、员工管理、订单查询与完善、订单配送、出入库和库房信息维护、调度优化、车辆状态与历史记录管理等场景同时给出客户、员工、部门、订单、库房、调拨、车辆等核心数据库表设计并记录了系统界面与性能测试结果。资源包仅含1个docx文档大小约9KB内容精炼。已有354人学习适合需要参考SSM框架项目架构、模块划分、数据库设计或论文写作结构的读者。1. 物流配送管理系统为什么值得从 SSM 框架入手接触物流配送系统的第一周最容易被卡住的往往不是业务算法而是 SSM 框架里的容器边界和事务边界。运单状态在多个表之间流转司机接单存在并发冲突轨迹数据持续写入Spring、Spring MVC、MyBatis 三者只要有一个配置错位线上就会出现“接口通了但数据没变”“状态能跳但查不到操作记录”这类问题。“基于 SSM 框架的物流配送管理系统设计与实现”这个标题看起来像课堂项目拆开来看要解决的事情并不少先要有一套合理的运单数据模型然后把配送流程抽象成状态机最后用 Spring 的事务和 MyBatis 的条件更新保证数据不打架。这个系统适合用来理解 Java Web 后台从骨架到上线的完整路径也适合作为内部配送管理后台的起点。2. SSM 项目骨架搭建与 Spring 容器配置2.1 SSM 的组件边界与选型理由很多团队第一次把 SSM 项目跑起来后会发现Transactional不生效、ResponseBody返回 406 或者 Mapper Bean 找不到。这些问题大多不是代码逻辑问题而是没有搞清楚 SSM 三个框架各自的职责。Spring 负责对象创建、依赖注入和事务管理是整个应用的大管家Spring MVC 负责接收 HTTP 请求、参数绑定和返回视图或 JSONMyBatis 负责数据库访问SQL 写在 Mapper XML 里由 Spring 管理 SqlSession 的生命周期。在物流配送系统里这种分层带来的直接收益是问题定位变得直观接口返回异常查 Controller状态更新错乱查 Service 和 Mapper连接池满了查 Druid 配置。为什么不直接上 Spring Boot如果是在现有 SSM 项目上做迭代重新搭一套 Boot 环境反而增加迁移成本。新项目当然可以选 Boot但物流配送这类数据模型稳定、查询条件固定的管理系统用 SSM 并不慢而且 XML 格式的 SQL 在复杂报表场景里更容易做版本对比和走查。选型时的关键是明确 Spring 父容器和 Spring MVC 子容器的扫描范围否则后面会踩很多隐性坑。容器负责内容典型配置Spring 父容器数据源、事务管理器、SqlSessionFactory、Service、MapperapplicationContext.xmlSpring MVC 子容器Controller、HandlerMapping、拦截器、视图解析器、消息转换器spring-mvc.xml2.2 用 Maven 把 SSM 框架依赖一次配齐搭建 SSM 骨架时我一般不会在 pom 里把三个框架拆开单独管版本而是统一用属性占位由团队维护一份版本基线。下面是一份可落地的依赖集合覆盖了 Web、JDBC、MyBatis、Druid、Jackson 和 Servlet API。properties spring.version5.3.x/spring.version mybatis.version3.5.x/mybatis.version mybatis-spring.version2.1.x/mybatis-spring.version druid.version1.2.x/druid.version mysql.version8.0.x/mysql.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-jdbc/artifactId version${spring.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version${mybatis.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version${mybatis-spring.version}/version /dependency dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version${druid.version}/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version${mysql.version}/version /dependency dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId scopeprovided/scope /dependency dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.13.x/version /dependency /dependencies这里有两个容易忽略的细节。spring-jdbc提供了DataSourceTransactionManager如果只引入spring-webmvc事务管理器的 class 会找不到javax.servlet-api必须用providedscope否则会和 Tomcat 自带的 Servlet 实现冲突。数据源方面Druid 适合 SSM 传统项目因为它自带监控页面和慢 SQL 统计省去额外搭监控组件的成本。连接参数我习惯放到jdbc.properties不让数据源配置散落在 Spring XML 里。jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/logistics?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.passwordyourpassword druid.initialSize2 druid.maxActive20 druid.maxWait60000initialSize是启动时预创建的连接数maxActive是最大活跃连接数maxWait是获取连接的超时时间。配送系统在晚高峰会有大量司机刷新运单列表maxWait设置过短会出现大量连接获取异常设置过长会让请求堆积在线程池里建议从 60 秒开始调。2.3 让 Spring 与 Spring MVC 各司其职的关键配置SSM 的 web.xml 只需要做两件事让 ContextLoaderListener 加载 Spring 父容器让 DispatcherServlet 加载 Spring MVC 子容器。context-param param-namecontextConfigLocation/param-name param-valueclasspath:applicationContext.xml/param-value /context-param listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-valueclasspath:spring-mvc.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern//url-pattern /servlet-mappingload-on-startup设置为 1让应用启动时立即初始化 DispatcherServlet而不是等第一个请求进来才加载。url-pattern使用/把包括静态资源在内的所有请求都交给 Spring MVC 路由。spring-mvc.xml 里的核心是扫描边界和注解驱动。context:component-scan base-packagecom.example.logistics.controller/ mvc:annotation-driven/ bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/views// property namesuffix value.jsp/ /beancomponent-scan 只扫 controller 包不扫 service。mvc:annotation-driven负责注册 RequestMappingHandlerAdapter、Jackson 消息转换器等组件缺少它时ResponseBody返回对象会直接走进 ViewResolver表现为接口返回的是一串视图路径或者直接报 406。提示在同一个应用里spring-mvc.xml 不要为省事把 service 包也扫进去否则 Spring 父容器和 Spring MVC 子容器会创建两套 Service事务代理可能只挂在其中一套上调用接口时会出现“查询正常但更新不提交”的诡异问题。3. 物流配送核心表设计与 MyBatis 持久层实现3.1 运单主表设计字段类型和索引取舍配送域的核心实体是运单不是订单。订单来自上游业务运单才属于配送流程。设计表时要先区分哪些字段会被频繁更新哪些字段只读。运单表中的status、driver_id、update_time是高频更新字段waybill_no、create_time是高频查询字段。下面是配送系统最基础的运单表结构。CREATE TABLE delivery_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, waybill_no VARCHAR(32) NOT NULL COMMENT 运单号, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待分配 1-已分配 2-运输中 3-已签收 4-异常, sender_name VARCHAR(64), sender_phone VARCHAR(20), receiver_name VARCHAR(64), receiver_phone VARCHAR(20), driver_id BIGINT DEFAULT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_waybill_no (waybill_no), KEY idx_status_create (status, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;关键字段说明如下字段类型设计原因waybill_noVARCHAR(32)业务唯一键独立唯一索引statusTINYINT状态值少存储小适合做组合索引前缀driver_idBIGINT分配后才写入可空不单独建索引create_timeDATETIME列表页按时间倒序常用加入组合索引update_timeDATETIME配合ON UPDATE自动维护便于排查状态变更时间status使用 TINYINT 而不是 VARCHAR是因为状态变化在 Java 代码里有枚举定义数据库只需要存枚举对应的 code。TINYINT 在高并发更新时占用的锁空间更小索引页能容纳更多行。idx_status_create这个组合索引直接服务列表页的典型查询按状态过滤再按创建时间倒序。如果只有单列索引MySQL 通常只能用到 status 列排序动作会额外触发 filesort。3.2 MyBatis Generator 生成基础代码的合理范围SSM 项目里使用 MyBatis Generator 生成实体、Mapper 接口和基础 XML 是常见做法但要注意控制生成范围。生成器生成的代码适合做单表增删改查不适合承载业务关联查询。我在 generatorConfig.xml 里一般只配置 JavaModelGenerator、SqlMapGenerator 和 JavaClientGenerator不生成 Service。Maven 插件配置如下。plugin groupIdorg.mybatis.generator/groupId artifactIdmybatis-generator-maven-plugin/artifactId version1.4.x/version configuration configurationFile${basedir}/src/main/resources/generatorConfig.xml/configurationFile overwritetrue/overwrite verbosetrue/verbose /configuration /plugin执行生成命令mvn mybatis-generator:generate生成完成后我建议立刻把overwrite改回false。因为生成器再次运行会覆盖 XML 中手写的 SQL如果一个项目里多个成员同时在扩展同一个 Mapper覆盖的后果很麻烦。生成的 Example 类不是不能用而是不要滥用。criteria.andEqualTo拼接起来确实很方便但复杂条件组合多了之后SQL 执行计划很可能走偏索引选择变得不可控。管理后台的简单筛选可以用 Example配送链路里的状态更新、轨迹插入和分页查询建议手写 SQL。3.3 手写 Mapper SQL 的三个高频写法配送系统里最常手写的 SQL 有三类条件更新、批量插入、动态列表查询。条件更新运单状态时用set标签自动处理逗号。update idupdateStatusById parameterTypemap UPDATE delivery_order set if testnewStatus ! null status #{newStatus}, /if if testdriverId ! null driver_id #{driverId}, /if update_time NOW() /set WHERE id #{id} /updateNOW()由数据库生成时间避免多个应用实例服务器时间不一致导致状态更新时间漂移。这个 update 方法只做普通更新不做状态条件校验因此只适合在 Service 层已经校验过状态流转的场景中使用。配送轨迹表需要批量写入否则在途节点多时容易产生大量单条 INSERT。insert idbatchInsertTrace parameterTypelist INSERT INTO delivery_trace (waybill_no, op_type, op_desc, operator, create_time) VALUES foreach collectionlist itemtrace separator, (#{trace.waybillNo}, #{trace.opType}, #{trace.opDesc}, #{trace.operator}, NOW()) /foreach /insertforeach的 separator 用逗号把多条记录拼进一条 INSERT。批量写入时要注意 MySQL 对 SQL 语句大小和参数数量的限制单批建议控制在 200 到 500 条超过后拆成多批。列表查询要处理动态筛选条件分页由应用层传入 offset 和 size。select idselectPageByStatus resultTypecom.example.logistics.entity.DeliveryOrder SELECT id, waybill_no, order_no, status, driver_id, create_time FROM delivery_order where if teststatus ! null AND status #{status} /if if testdriverId ! null AND driver_id #{driverId} /if /where ORDER BY create_time DESC LIMIT #{offset}, #{limit} /select分页参数由 Service 层计算offset (page - 1) * size。如果使用 PageHelper要清楚它基于 ThreadLocal 生效只对紧接着的一条查询起作用在异步线程或批量循环里容易误伤其他 SQL我一般不用。4. 配送状态机与并发接单的实现4.1 状态机如何映射到 Service 代码配送流程可以简化为四个核心状态待分配、已分配、运输中、已签收。每个状态能跳转到哪里必须事先确定。当前状态允许转变到待分配已分配、异常已分配运输中、异常运输中已签收、异常已签收无状态表在 Java 代码里用枚举表达。public enum DeliveryStatus { WAIT_ASSIGN(0, 待分配), ASSIGNED(1, 已分配), TRANSPORTING(2, 运输中), SIGNED(3, 已签收), EXCEPTION(4, 异常); private final int code; private final String desc; DeliveryStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }状态机不一定非要引入框架。Spring Statemachine 在状态分支多、事件复杂的场景下有价值但配送流程只有四五个状态再套一层框架会让新成员看代码时要跳好几层配置。我比较推荐用枚举定义状态然后在一个 Service 里收口所有状态变更入口。签收操作的 Service 方法如下。Transactional(rollbackFor Exception.class) public void signOrder(Long orderId, String operator) { DeliveryOrder order deliveryOrderMapper.selectByPrimaryKey(orderId); if (!DeliveryStatus.TRANSPORTING.getCode().equals(order.getStatus())) { throw new BusinessException(当前状态不支持签收); } deliveryOrderMapper.updateStatusById(orderId, DeliveryStatus.SIGNED.getCode(), null); deliveryTraceService.record(order.getWaybillNo(), SIGN, operator); }在 Service 层先查一次状态再执行更新这种做法能挡掉大部分非法操作但存在时间窗口。两个请求同时读到运输中状态理论上都能通过校验。要彻底避免并发问题需要依赖数据库层面的条件更新。4.2 接单接口的乐观锁与事务边界司机接单是并发场景最集中的操作。同一个运单不能被两个司机同时接走这是典型的行级竞争问题。常见做法是使用乐观锁条件更新。Mapper 接口中定义带状态条件的方法。int casUpdateStatus(Param(orderId) Long orderId, Param(oldStatus) Integer oldStatus, Param(newStatus) Integer newStatus, Param(driverId) Long driverId);对应 XML 写条件更新。update idcasUpdateStatus UPDATE delivery_order SET status #{newStatus}, driver_id #{driverId}, update_time NOW() WHERE id #{orderId} AND status #{oldStatus} /updateService 层调用该方法通过影响行数判断是否抢单成功。Transactional(rollbackFor Exception.class) public void acceptOrder(Long orderId, Long driverId) { int updated deliveryOrderMapper.casUpdateStatus( orderId, DeliveryStatus.WAIT_ASSIGN.getCode(), DeliveryStatus.ASSIGNED.getCode(), driverId ); if (updated 0) { throw new BusinessException(运单已被其他司机接走请刷新列表); } deliveryTraceService.record(orderId, ACCEPT, driverId); }WHERE status #{oldStatus}是并发控制的核心。数据库在更新时会对命中的行加锁两个并发请求同时执行这条 UPDATE只有一个会匹配到旧状态并成功更新另一个影响行数为 0由代码主动抛出业务异常。这里不需要SELECT ... FOR UPDATE因为条件更新本身已经完成了行锁不需要再额外持有一把读锁。事务边界要注意状态更新和轨迹插入必须放在同一个事务里。要么状态变了轨迹也记上要么全部回滚不能出现运单显示已接单但轨迹查不到操作记录的脏状态。方法上的Transactional(rollbackFor Exception.class)把casUpdateStatus和record放在同一个事务中任何异常都会回滚。4.3 定时扫描与自动分单的线程配置配送系统里总有一部分运单长时间没有司机接单需要在后台定时扫描并重新分配。常见做法是使用 Spring 的Scheduled注解。Component public class DeliveryTimeoutJob { Scheduled(fixedDelay 5000) public void processTimeoutWaybill() { ListLong timeoutIds deliveryOrderMapper.selectTimeoutIds(30); for (Long orderId : timeoutIds) { deliveryOrderService.autoReassign(orderId); } } }fixedDelay 5000表示上一次任务执行完成后间隔 5 秒再执行下一次。如果使用fixedRate则按固定频率触发任务执行时间过长时会累计等待导致线程阻塞。Scheduled默认是单线程执行。一个应用里只要有两个定时任务就会互相排队。其中一个任务访问数据库慢另一个任务可能延迟十几秒。需要在 Spring 配置里增加调度线程池。task:scheduler idlogisticsScheduler pool-size4/ task:annotation-driven schedulerlogisticsScheduler/pool-size根据业务量设置配送系统后台定时任务不多4 个线程足够。autoReassign内部要避免在大循环里频繁更新同一条记录可以先批量查出超时运单再按司机在线状态批量分配最后逐条写入分配结果减少数据库往返。5. 上线前把 SSM 应用调稳的验证手段5.1 用 Druid 慢 SQL 监控抓住索引缺失SSM 项目接入 Druid 监控的成本很低。在 web.xml 中注册 Druid 的 WebStatFilter 和 StatViewServlet启动后就可以通过/druid/sql.html查看 SQL 执行次数、耗时和并发情况。在 Druid 数据源配置中加上慢 SQL 过滤参数bean idstatFilter classcom.alibaba.druid.filter.stat.StatFilter property nameslowSqlMillis value1000/ property namelogSlowSql valuetrue/ /beanslowSqlMillis设置 1000 毫秒超过阈值的 SQL 会记录到日志并出现在监控页。上线后先看执行次数高的查询再看平均耗时。如果运单列表页慢用EXPLAIN查看执行计划重点看type列是否为ref或rangekey列是否真正用了idx_status_create。很多慢查询并不是 SQL 写错而是SELECT *返回了过多字段MySQL 不得不做回表或者排序。5.2 用 Spring Test 与 MockMvc 覆盖并发接单SSM 项目的 Service 层测试可以直接加载 Spring 容器来验证事务和状态流转。RunWith(SpringJUnit4ClassRunner.class) ContextConfiguration(locations {classpath:applicationContext.xml}) public class DeliveryOrderServiceTest { Autowired private DeliveryOrderService deliveryOrderService; Test(expected BusinessException.class) public void acceptTwice_shouldThrow() { deliveryOrderService.acceptOrder(1001L, 10L); deliveryOrderService.acceptOrder(1001L, 11L); } }这个测试验证的是第二次接单因为casUpdateStatus影响行数为 0 而抛出异常第一次接单成功后第二次不能覆盖原来的司机。它没有真正模拟多线程但能保证状态分支逻辑的正确性。Controller 层用 MockMvc 验证接口参数绑定和返回结构。mockMvc.perform(post(/order/accept) .param(orderId, 1001) .param(driverId, 10)) .andExpect(status().isOk()) .andExpect(jsonPath($.code).value(0));测试库要尽量用真实 MySQL不要用 H2。H2 对UPDATE影响行数的判断、隐式类型转换和主键生成行为与 MySQL 不完全一致容易把并发问题掩盖掉。SSM 项目里手写 SQL 和生成器 SQL 混用只有在真实数据库上跑过回归上线时才敢放心。本文还有配套的精品资源点击获取