宠主免费发布托运需求,缴纳履约保证金的托运商家在线报价,宠主比价后选择商家;平台向成交商家收取订单技术服务费,托运费用由宠主和商家线下自行结算。平台不参与实际的运输过程,规避法律风险并提高运营稳定性!
1. 整体框架与设计思路
核心是做一个“双边竞价撮合”平台。业务主线明确:C端发单 -> B端交保证金 -> B端竞价 -> C端比价决定 -> 平台抽佣。
设计思路上,为了快速跑通业务,系统划分为三大核心模块:宠主端(重表单提交与比价交互)、商家端(重抢单效率与消息通知)、运营后台(重抽佣财务对账)。交易逻辑上采用“平台抽佣 + 尾款线下结算”分离的模式,既保证了平台的盈利点,又大幅降低了平台的资金监管和合规风险。
2. 核心技术栈
前端(小程序端):微信原生开发 + TDesign 组件库(契合轻量化落地,UI一致性好,开发提效)。
后端服务:Node.js / Spring Boot + MySQL(处理订单和关系型数据)。
缓存与中间件:Redis(应对高频的比价大厅刷新和抢单并发控制)。
3. 我的职责与量化结果
核心链路开发:负责“发单-报价-比价-成交”核心交易链路的前端UI实现与后端接口对接。
性能优化:重构了“比价大厅”的长列表数据加载逻辑,通过接口数据聚合和字段精简,将核心页面首屏加载时间从 2.8s 压降至 1s 以内。
业务保障:系统上线后,成功支撑日均 500+ 次的商家并发报价请求,核心接口报错率控制在 0.1% 以下,宠主从发单到收到首个报价的平均等待时间缩短至 10 分钟。
4. 遇到的坑与解决方案
坑1:高并发导致重复报价与状态异常
难点:热门单子一发布,多个商家同时抢单报价,或者单一商家网络卡顿连续点击,导致数据库插入重复报价。
解决:放弃单纯依赖前端防抖,在后端引入 Redis 分布式锁。提交报价时以 需求ID + 商家ID 生成唯一锁,确保核心扣减和写入逻辑的原子性与接口幂等性。
坑2:履约保证金支付状态偶尔“丢失”
难点:强依赖微信支付的异步回调,遇到网络抖动时,商家付了保证金,但系统里状态没更新,导致无法报价,引发客诉。
解决:不能单点依赖回调。增加了“主动查询+对账兜底”机制:前端支付成功后主动轮询后端,后端实时调用微信查单接口同步状态;配合后台定时任务扫表对账,彻底解决状态不一致问题。
坑3:复杂比价列表导致前端内存暴涨掉帧
难点:宠主比价时,列表里包含大量商家头像、宠物实拍图以及长篇幅的“服务详情”,导致小程序滑动卡顿。
解决:对数据接口进行“瘦身”,将复杂的“服务详情”富文本剥离为按需懒加载;同时对接云端 OSS 对图片进行带参数的缩略图处理,极大降低了内存占用,列表滑动帧率稳在 60fps。