从微信聊单聊到崩溃到决定自己做一套约稿系统这个转变其实挺偶然的。当时一个开设计工作室的朋友跟我抱怨报价靠截图、定金靠转账、改稿记录全在聊天记录里出了纠纷连个依据都难找。我听完第一反应是这不就是一个典型的线上交易闭环问题吗于是我用Java生态从零搭了一套设计师约稿平台把需求发布、竞标选标、定金托管、创作交付、尾款结算、双方评价全部串成一条完整链路。这篇文章就把这套系统的业务拆解、技术选型、数据建模、核心实现和踩坑过程完整记录下来给准备做交易类系统或者想用Java实战一个完整项目的朋友做参考。1. 约稿平台到底在管什么从线下接单到线上流转的业务拆解1.1 三种角色各怀心事约稿平台不是单纯的电商也不是单纯的CMS它本质是一个撮合交易平台。平台上长期活跃着三类角色每一类的诉求都不一样。甲方约稿方要的是信任感和掌控感。他们最怕的是付了定金设计师消失或者改了一百遍稿子最终还不满意。所以平台必须给他们提供设计师作品集浏览、需求发布入口、报价与周期对比、订单状态透明、退款与申诉通道。设计师要的是流量和保障。他们关心的是平台能不能带来精准的需求自己能不能被甲方看到投标之后有没有反馈做完单子钱能不能安全到手。平台运营方要的是撮合效率和风控能力。撮合效率决定GMV风控能力决定平台的寿命——如果纠纷率太高、资金流向不清晰平台迟早被拖垮。这三种角色的诉求叠加在一起指向同一个结论约稿平台的核心能力不是展示页面做得多漂亮而是把这笔非标交易的每一步都变成可记录、可追踪、可裁决的状态。1.2 一条完整约稿流程的九个节点我在设计业务时序的时候把一次完整的约稿拆成了九个关键节点甲方发布设计需求预算、周期、风格说明设计师浏览需求并发起投标报价方案简述甲方对比提案选择一名设计师甲方支付定金订单正式进入创作期设计师创作并提交初稿甲方验收初稿提出修改意见设计师修改并再次提交甲方确认终稿支付尾款最终作品源文件开放下载双方互评这九个节点里最值得注意的一点是约稿不是“下单即支付”的标准电商它中间夹了一个竞标选标期。也就是说订单生命周期被分成了两个阶段——竞标期和履约期竞标期里需求单是主角履约期里订单才是主角。很多第一次做这类系统的人容易把需求和订单混为一谈后面数据模型就会越写越别扭。1.3 平台存在的意义是降低交易摩擦线下约稿为什么容易扯皮因为定金和尾款的支付没有第三方托管改稿次数没有上限初稿和最终源文件的交付边界不清晰。平台要解决的就是把这些模糊地带全部规则化定金由平台托管改稿次数在提案里提前写明初稿以水印预览形式交付最终源文件在尾款支付后才释放下载权限。这几条规则就是整个平台所有功能设计的出发点后面每写一个模块我都会回到这几点来校验设计是否合理。2. Java技术栈定型的几个理由与基础环境准备2.1 为什么是Java而不是Python、PHP或者Go这个项目立项前我和团队里几个人认真对比过不同技术栈。这里不是说别的语言不行而是针对“约稿交易平台”这个具体业务Java的优势刚好踩在痛点上。我做了一次简单对比技术栈优势在这个项目里的短板Java/Spring Boot事务能力强、生态成熟、团队招聘容易、状态机/支付等领域方案丰富开发速度中等需要一定的工程规范Python/Django开发快、原型验证方便交易类系统里并发控制、分布式事务的成熟方案相对分散运维成本偏高PHP/Laravel快速搭建CMS和展示类站点订单状态机复杂后代码维护成本上升很快Go高并发网关、IM场景很强业务领域建模和开发效率不如Java生态顺手团队上手成本高最终选择Java核心就三个理由事务治理稳定、状态机类业务有大量现成框架可以借鉴、后续招人补位容易。交易类系统最怕的是在业务逻辑复杂度上升之后语言生态里找不到靠谱的组件来托底Java在这方面的积累确实是最厚的。版本选择上新项目直接用JDK 17 Spring Boot 3.x。如果你们团队还在维护老项目Spring Boot 2.7 JDK 8也完全够用本篇文章的示例设计思想在两边是通用的。2.2 这套平台用到的技术栈清单最终敲定的技术栈如下Spring Boot 3.2Web框架MyBatis-Plus数据访问层MySQL 8.0主数据库InnoDB引擎Redis 7缓存、分布式锁、热度计数、实时榜单RabbitMQ异步消息、延迟消息、订单超时处理MinIO私有化对象存储用来存作品和交付文件Spring Security JWT认证与权限控制这里多说一句为什么用MyBatis-Plus而不用Spring Data JPA。约稿平台的需求查询条件特别杂按分类、预算区间、风格标签、状态、发布时间筛选还要处理动态排序。JPA的Specification在动态查询复杂到一定程度之后代码可读性会明显下降。MyBatis-Plus的LambdaQueryWrapper配合XML自定义SQL写动态查询更直接DBA审查SQL也方便。2.3 Java环境变量配置的几个细节这个项目开发过程中社群里经常有人问Java环境问题我顺手把JDK安装后的环境配置也说一下新手可以照着做。第一步安装JDK后需要配置JAVA_HOME环境变量指向JDK的安装根目录比如C:\Program Files\Java\jdk-17。第二步把%JAVA_HOME%\bin追加到Path变量里这样才能在命令行直接运行java -version。第三步在命令行验证三条命令java -version javac -version echo %JAVA_HOME% # Windows echo $JAVA_HOME # Linux / macOS看到版本号正常输出说明JDK没问题。很多IDEA编译报错、Maven构建失败排查到最后往往就是JAVA_HOME没配好或者IDEA里Project SDK和Maven Runner的JDK选成了不同版本。IDEA里设置Project SDK后还要在Settings - Build Tools - Maven - Runner里确认JDK也切到同一个版本这个双JDK不一致的问题特别隐蔽值得提前检查。3. 数据库设计订单状态机是约稿平台的定海神针3.1 核心表结构整个平台核心涉及七张表users用户表存甲乙双方及管理员账号包含角色、实名状态、作品集关联信息demands需求表甲方发布的需求单包含标题、描述、预算区间、截止时间、风格标签、状态proposals提案表设计师对需求单的投标包含报价、周期、方案说明、状态orders订单表甲方选标后生成的正式交易单包含定金、尾款、订单状态deliverables交付物表按版本记录每一次交付文件包含文件路径、是否水印版、是否释放原图reviews评价表订单完成后双方互评wallet_bills资金流水表记录每一次定金托管、尾款支付、退款、佣金结算这里我特别强调一下需求表和订单表一定是两张表不要合并。原因在于一个需求在竞标期可能收到十几个提案但最终只有一个提案能胜出形成订单另外的提案需要保持“已拒绝”的历史状态。如果做成一张表这些中间状态根本没法表达。3.2 订单状态机的完整定义约稿订单的状态比普通电商订单复杂得多。我定义了一套状态枚举状态含义前置状态PENDING_DEPOSIT待付定金甲方选标后CREATING创作中定金已支付REVIEWING待甲方验收初稿设计师提交初稿后REVISING修改中甲方验收不通过提出修改意见PENDING_FINAL待付尾款甲方确认终稿COMPLETED已完成尾款支付且源文件释放REFUNDING退款处理中定金支付后符合退款条件CANCELLED已取消竞标期关闭或订单取消用文字描述一次正常流转就是PENDING_DEPOSIT - CREATING - REVIEWING - REVISING - REVIEWING - PENDING_FINAL - COMPLETED。修改稿可以循环多次所以REVISING会回到REVIEWING但是要加一个修改次数上限防止出现无限改稿的极端情况。3.3 防重与并发控制相关的索引设计竞标期最容易出现的并发问题是同一个设计师对同一个需求重复投标。除了在Java代码里做校验数据库层面我加了唯一索引ALTER TABLE proposals ADD UNIQUE INDEX uk_requirement_designer (requirement_id, designer_id, deleted);deleted字段参与唯一索引是为了支持逻辑删除后可以再次投标比如设计师撤回提案后再重新提交这样不会跟历史记录冲突。另外demands表的热点查询集中在“当前开放的竞标需求”所以建了联合索引(status, category_id, created_at)。orders表则针对甲乙方各自查询建了(buyer_id, status, created_at)和(designer_id, status, created_at)两个联合索引避免在订单列表页出现全表扫描。4. 需求发布与竞标的实现细节锁、计数、榜单一体化4.1 需求发布接口的几个校验点需求发布是整个平台的流量入口这个接口看似简单实际上要注意三个点幂等、敏感词过滤、预算合理性校验。幂等处理我使用前端生成的request_id后端在Redis里用SETNX缓存这个ID如果短时间内重复提交同一个request_id直接返回第一次的结果。这样用户在弱网环境下多点几次“发布”按钮也不会产生多条重复需求。预算合理性校验不只是判断“预算大于0”。约稿设计的特点是预算区间要有一个合理的上下限浮动比如投标报价超出甲方预算区间的50%就直接在UI层过滤掉减少无效提案。敏感词过滤我用的是基于AC自动机的敏感词库发布时把标题和描述都过一遍。这块虽然不涉及特别深的技术但在内容型平台里属于合规基石不能省。4.2 竞标防重的双保险唯一索引加Redis锁设计师投标的接口我会先检查需求状态必须是OPEN竞标中再检查设计师是否已投标最后插入提案记录。这三个动作中间存在并发窗口理论上两个请求同时进来可能绕过检查。我的处理是双保险。业务代码里先加Redis分布式锁String lockKey lock:proposal: requirementId : designerId; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 3, TimeUnit.SECONDS); if (!locked) { throw new BizException(操作太频繁请稍后再试); } try { // 检查需求状态、检查是否已投标、插入提案记录 } finally { redisTemplate.delete(lockKey); }即使Redis锁因为异常没生效还有数据库唯一索引托底重复插入会直接抛出DuplicateKeyException捕获后转成友好提示。这两层配合基本堵死了重复投标的路径。实际经验是任何涉及“防重”的写入都必须有数据库唯一索引做最终兜底Redis锁只是第一道闸不能完全依赖它。4.3 热度计数和实时榜单Redis才是主角甲方发布需求后需求列表页和发现页需要展示热度。一开始我直接在demands表加了一个hot_count字段每次有提案就UPDATE demands SET hot_count hot_count 1。上线后发现需求列表页每次刷新都产生大量聚合查询数据库压力不小。后来我把热度计数整体搬到了RedisString hotKey hot:demand: requirementId; Long hotCount stringRedisTemplate.opsForValue().increment(hotKey);每次设计师投标成功对这key执行一次increment。列表页展示时先批量从Redis取热度值Redis没有命中的需求才回源数据库。成交量、竞标榜这类实时榜单则直接放Redis的ZSetstringRedisTemplate.opsForZSet().incrementScore(rank:demand:week, requirementId.toString(), 1);发现页的“本周热门需求”直接reverseRangeWithScores取前50完全不需要数据库跑order by count性能提升非常明显。这里的核心经验是计数类数据不要跟着业务主表走独立放Redis保持主表体积可控同时给榜单和热度和统计留下了灵活空间。5. 订单履约状态推进、支付回调与自动超时处理5.1 轻量状态机落地枚举加事件表不用重型框架网上很多交易系统喜欢引入Spring StateMachine我在这个项目里权衡之后没有用。约稿订单的状态流转虽然比电商多但它仍然是线性为主、循环为辅的结构用一个枚举加事件驱动表就足够引入重型框架反而让代码难读。我用事件ID做key维护一张流转表public enum OrderEvent { DEPOSIT_PAID, SUBMIT_DRAFT, REJECT_DRAFT, ACCEPT_DRAFT, FINAL_PAID, REQUEST_REFUND }状态机核心是一个MapOrderStatus, MapOrderEvent, OrderStatus在Spring配置类里初始化Configuration public class OrderStateMachineConfig { public static final MapOrderStatus, MapOrderEvent, OrderStatus TRANSITIONS new HashMap(); static { register(PENDING_DEPOSIT, DEPOSIT_PAID, CREATING); register(CREATING, SUBMIT_DRAFT, REVIEWING); register(REVIEWING, REJECT_DRAFT, REVISING); register(REVISING, SUBMIT_DRAFT, REVIEWING); register(REVIEWING, ACCEPT_DRAFT, PENDING_FINAL); register(PENDING_FINAL, FINAL_PAID, COMPLETED); register(CREATING, REQUEST_REFUND, REFUNDING); } private static void register(OrderStatus from, OrderEvent event, OrderStatus to) { TRANSITIONS.computeIfAbsent(from, k - new HashMap()).put(event, to); } }推进状态的时候所有入口统一走transition(order, event)方法方法里做三件事校验当前状态是否允许该事件、用UPDATE orders SET status ? WHERE id ? AND status ?做乐观锁、写入订单状态变更日志表。第三条特别重要状态变更日志是将来处理甲方和设计师纠纷时最重要的证据链。5.2 支付回调的幂等设计定金和尾款都走第三方支付。支付回调最大的坑是回调通知不一定只来一次而且顺序可能乱所以支付结果处理必须幂等。我采用的方案是加一张payment_notify表以order_id payment_type transaction_no做唯一索引。回调进来先尝试插入记录插入成功才继续推进订单状态插入冲突说明这条回调已经处理过直接返回成功应答。这样即使同一笔付款回调二十次订单状态也只推进一次资金流水也只记一次。这个方案的思路和竞标防重如出一辙业务逻辑层可以加各种判断但数据库唯一索引永远是幂等的最强底牌。5.3 超时关闭需求RabbitMQ延迟消息比定时任务优雅竞标期经常会遇到一种情况甲方发布了需求也收到不少提案但一直不选标。平台约定竞标期最长7天到期自动关闭需求。类似的需求还有定金支付超时24小时自动取消、修改稿超过5天未处理自动提醒。这种“延时触发”的需求我选了RabbitMQ延迟消息实现而不是定时任务轮询。定时任务每分钟扫一次全表数据量小的时候没问题用户量一大就浪费严重而且扫描延迟不可控。延迟消息的做法是订单创建成功后发一条TTL为24小时的延迟消息消息进入死信队列消费者监听死信队列检查订单状态如果还停留在待支付状态就自动取消。这里要提醒一句RabbitMQ延迟消息需要启用rabbitmq_delayed_message_exchange插件否则就要用TTL加死信队列的实现方式。我实际用的TTL加死信队列方式虽然多写了几行配置但胜在不依赖额外插件部署时少踩一个坑。5.4 修改稿次数的硬限制约稿纠纷里最高频的矛盾是“甲方觉得改得不够设计师觉得甲方无理取闹”。所以平台的规则是提案阶段设计师就明确一次约稿包含几次修改通常2到3次超出后如果甲方还想改需要支付额外改稿费用。这个逻辑在orders表里用revision_count和revision_limit两个字段控制每次甲方验收不通过触发REJECT_DRAFT事件时revision_count加一超过revision_limit就禁止继续走REJECT_DRAFT只能选择ACCEPT_DRAFT或者走平台仲裁。这个硬限制看起来很粗暴但实际效果非常好它把双方对“改稿”的预期在交易开始前锁死了。6. 交付与验收水印、临时链接与权限控制的实现思路6.1 为什么用MinIO做对象存储设计作品动辄几百MB不适合直接存数据库也不可能放到应用服务器本地磁盘。这个项目里选的是私有化部署的MinIO原因有两点一是它兼容S3协议将来如果换到云厂商的对象存储客户端代码几乎不用改二是私有化部署让敏感的作品文件只走内网不会经过第三方对象存储服务甲方和设计师心理上更接受。MinIO的Bucket权限我设置为私有。所有上传的文件应用服务先拿到上传凭证再直传MinIO避免文件经应用服务器中转带来的带宽和延迟问题。6.2 水印图异步生成初稿只能看不能卖初稿交付阶段设计师提交的源文件不可能直接暴露给甲方否则甲方拿到原图不付尾款设计师就白干了。我的处理是文件上传到MinIO后发一条消息到RabbitMQ异步消费者拉取原文件用Java的Graphics2D库生成水印版本和压缩缩略图。初稿阶段交付物表里保存的是水印图路径甲方可以在线预览但点开任何控件看到的都是带设计师ID水印的版本没有下载原图的按钮。只有走完整个订单流程COMPLETED之后交付物记录才被标记为RELEASED原图路径生效。6.3 临时预览链接有效期控制即便给了在线预览也不能让预览链接永久有效。我封装了一个生成预览地址的服务基于MinIO的PresignedUrl能力生成带有效期的临时链接有效期默认15分钟过期后自动失效。这样即使甲方把链接分享出去15分钟后也无法访问。尾款支付完成后我再为原文件生成一个7天有效期的下载链接同时记录下载次数。这里的小细节是生成下载链接前要校验订单状态确实是COMPLETED、校验请求用户是订单甲方双重校验通过才放行。7. 踩坑实录Redis increment、动态代理、并行等待三个典型问题7.1 RedisTemplate的increment()报错ERR value is not an integer or out of range这个报错在项目前期频繁出现现象是某个需求的热度计数执行到一半就抛异常错误信息是ERR value is not an integer or out of range排查过程很有意思。最开始我怀疑是并发问题但单机复现也能触发。后来把存入Redis的值GET出来一看发现类型根本不是数字。问题出在RedisTemplate的默认序列化器上。我初期图省事用了RedisTemplateString, Object对象的默认序列化器是JDK序列化。也就是说redisTemplate.opsForValue().set(key, 0)虽然传入的是Integer但存进Redis之后是JDK序列化后的二进制字节Redis执行INCR命令时看到的不是字符串数字直接报错。解决方案是计数场景统一改用StringRedisTemplatekey和value全部走String类型插入初始值也和自增分开处理直接用increment完成初始化// 错误示范先set再increment redisTemplate.opsForValue().set(hot:demand:100, 0); redisTemplate.opsForValue().increment(hot:demand:100); // 正确做法直接用increment不存在时Redis会从0开始自增 Long newCount stringRedisTemplate.opsForValue().increment(hot:demand:100);这里也建议团队统一一个约定Redis里同一类业务的key数据格式必须一致绝对不能今天存String明天存二进制。这个约定不写在代码里写在项目的Redis规范文档里新同事入职第一件事就是看这个。7.2 动态代理一趟关于JDK代理和CGLIB的实践课约稿平台里我用了不少动态代理最常见的是Spring AOP和MyBatis Mapper。Spring AOP用来做接口权限校验和操作日志MyBatis Mapper接口则完全是靠动态代理生成实现类这也是为什么Mapper接口不需要写实现类的原因。这个项目里最值得记的坑是自定义一个“未实名设计师禁止投标”的切面。我写了注解RequireRealName加在投标接口上再用AOP切面解析。看起来逻辑很简单但实际运行发现注解加在private方法上完全无效还有同一个类内部方法自调用也不会走代理。因为Spring AOP默认的代理机制里this调用会绕过代理对象必须注入代理对象或者拆分到另一个Bean才能生效。另外Spring Boot 2.x以后默认proxyTargetClasstrue使用CGLIB代理而CGLIB不能代理final类、不能代理final方法。我给某个Service类加final导致运行时直接报错排查了半天才意识到是代理机制的问题。所以写交易类代码的时候Service类千万不要加final方法也尽量避免final。7.3 CompletableFuture并行拼装数据自定义线程池是必须的需求列表页要展示的数据非常花基础信息、设计师头像、提案数、热度值、是否已投标这些数据分散在MySQL和Redis里。早期我按顺序串行查询一个接口耗时稳定在600毫秒到800毫秒体感很差。后来改用CompletableFuture并行拼装CompletableFutureLong proposalCountFuture CompletableFuture.supplyAsync( () - proposalService.countByRequirementId(requirementId), executor); CompletableFutureLong hotCountFuture CompletableFuture.supplyAsync( () - getHotCount(requirementId), executor); CompletableFuture.allOf(proposalCountFuture, hotCountFuture).join();这里最大的坑是默认的ForkJoinPool.commonPool()。它是CPU密集型任务设计的线程数通常是CPU核心数减一而我们的IO请求查MySQL、查Redis会把线程阻塞住稍微一压测就发现commonPool被占满其他并行任务全部排队。解决方式是自己定义一个业务专用的线程池Bean public ThreadPoolTaskExecutor bizExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(20); executor.setQueueCapacity(200); executor.setThreadNamePrefix(biz-async-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }CallerRunsPolicy的意思是线程池满了之后新任务由调用线程自己执行而不是丢弃或者抛异常这样在流量突发时能保证任务不丢只是响应稍慢一点。改造之后列表页接口耗时从700毫秒降到了200毫秒左右效果非常直接。8. 性能调优与上线运行的关键建议8.1 热点需求详情的缓存策略需求详情页是访问最频繁的接口之一一个热门需求可能同时被几百个设计师盯着。早期每个请求都查库一个热门需求能拖垮数据库连接池。缓存策略我做了两层。第一层是Redis缓存需求详情JSONkey是cache:demand:detail:{id}过期时间10分钟。第二层是防止缓存击穿当缓存失效且大量请求同时打到数据库时用Redis的互斥锁保证只有一个请求能回源查库其他请求短暂sleep后重试拿缓存。这个互斥锁的代码非常简单String lockKey lock:demand:detail: demandId; if (tryLock(lockKey)) { try { DemandsDTO demand loadFromDb(demandId); redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(demand), 10, TimeUnit.MINUTES); } finally { unlock(lockKey); } }列表页仍然走分页查询但只查基础字段像热度、提案数这些高频变化字段从Redis批量取取不到的回源再兜底。这轮优化之后详情页接口P95耗时从1.2秒降到了400毫秒。8.2 深分页和慢SQL的处理约稿平台列表页的翻页深了以后MySQL的LIMIT性能下降非常快。LIMIT 10000, 20这种写法MySQL要扫描前面10020行再丢弃前10000行越翻越慢。我的处理是限制动态翻页深度超过100页强制走游标查询也就是把“页码”改成“上一页最后一条记录的时间字段”用WHERE created_at ? ORDER BY created_at DESC LIMIT 20代替LIMIT OFFSET。这个改动对用户无感但对数据库是质的改善。慢日志里还抓到一条高频SQL是统计设计师历史完成订单数的聚合查询。起初没建索引跑一次要几百毫秒。后来在orders表加了(designer_id, status)联合索引并把“历史完成订单数”做成一个单独字段在订单状态推进到COMPLETED时用事务更新一次彻底消灭了对订单表的实时聚合。8.3 压测之后的线程池与连接池调优上线前我用JMeter做了一轮基础压测单机8C16G的配置目标TPS是500。初期Tomcat默认配置两百线程HikariCP默认连接池10压测到300TPS时数据库连接池先撑不住了报连接等待超时。调整方案是HikariCP的maximum-pool-size调到50minimum-idle调到10Tomcat的max-threads调到400。这里要强调连接池不是越大越好连接数过大会增加数据库端的上下文切换开销50是结合接口平均RT在50毫秒左右算出来的经验值。压测后稳定在550TPS接口平均RT 45毫秒基本满足上线要求。8.4 上线后的运维和运营体会平台上线三个月后的真实状况是日常并发不高但需求集中发布时会出现瞬间峰值尤其是设计社区活动期间。Redis扛住了大部分流量MySQL的负载反而很轻当初把热度和计数类数据全部迁到Redis的决策被验证是完全正确的。还有一点让我印象很深是状态变更日志表上线后真的帮我们解决了一次纠纷。甲方说设计师没交过初稿设计师坚称交了两边各执一词。后台把状态日志拉出来清清楚楚显示CREATING - REVIEWING的变更时间、操作人、对应的交付物ID。最终平台依据这份日志做了仲裁也让甲方明白“提交初稿”这个动作确实存在只是他一直没点开验收入口。这套基于Java的设计师约稿平台走到现在我最满意的地方不是技术栈多先进而是每一步业务规则都有对应的技术手段去落实状态机解决流程混乱Redis计数解决数据倾斜动态代理解决权限收敛延迟消息解决超时控制水印和临时链接解决交付安全。交易类系统的技术选型其实没有太多花活能不能在业务复杂度和团队可维护性之间找到平衡才是真正考验人的地方。