郑州校园外卖系统开发 便捷点餐配送服务校园生活

      一次为郑州某高校搭建外卖系统的经历，从学生抱怨等餐慢开始。最初不是设计漂亮界面，而是解决“谁去送”“如何定位”“如何保证支付幂等”这类落地问题。我在需求拆解里优先把配送匹配、实时位置流、支付回调列为高优先级——因为这些环节一旦出问题，用户立刻能感知。

      技术选型上我倾向轻量化。后端以FastAPI做微服务主体，容器化部署在Kubernetes，Ingress用nginx，证书通过cert-manager自动续期；数据库选择PostgreSQL+PostGIS处理校内地理围栏和商铺多边形；Redis承担缓存与Geo索引，实现半径查询。实践中发现PostGIS在复杂院系边界判定上更稳，误差控制在几米内。

      骑手匹配不是简单距离最短。我们用Redis GEO做初筛，推送候选给有限数量骑手后进入抢单阶段。为避免并发抢单导致的重复接单，我用消息队列（RabbitMQ）结合Redis分布式锁：先用SETNX做短锁校验，成功者再在数据库用乐观锁（version字段）完成事务提交。这个组合在高并发饭点基本消灭了双分配问题。

      定位与轨迹稳定性调试占了不少时间。校园内GPS抖动明显，遇到教学楼阴影区跳点严重。我实现了基于时间窗的平滑算法：当速度、方向突变超过阈值且瞬时距离大于200米时弃用该点，并用简易卡尔曼滤波降低噪声。结合高德离线SDK做路网映射，配送ETA的偏差从原先的3分钟降到1分钟以内。

      支付与回调则要比想象复杂。微信、支付宝回调会并发到多台后端，曾因处理幂等性不足导致订单重复出餐。我的解决办法是三步：1）回调先写入回调表做幂等检查；2）使用幂等Key（商户订单号+回调ID）；3）异步用消息确认外卖系统主表状态。实践证明，落地幂等表比仅靠Redis锁更可靠，尤其在数据库主从切换时。

      运维与观测同样重要。我在集群里接入Prometheus抓取服务指标，Grafana设置关键仪表盘；日志通过Fluentd统一入ELK，异常由Sentry告警。一次夜间高峰拉起压力测试时，发现某服务内存泄漏——堆栈来自第三方SDK。排查过程用pmap、heap profiler配合容器重启策略，最终把问题限定到特定版本并回退。

      经验教给我的不是固定方案，而是可验证的操作流程：用PostGIS+Redis处理空间、用消息队列保证最终一致、用幂等表保护支付、用平滑算法修正定位。对未来我并不把系统做得复杂化，而是打好可观察性与可回滚的基础。若要继续改进，下一步会把路径规划接入开源路由库并尝试灰度上线更精细的匹配策略。