负责生鲜供应链履约系统核心模块（订单调度、仓储对接、供应商协同）的设计开发与性能优化，支撑日均150万+订单的全链路履约，衔接全国200+仓库、5000+配送站点及3000+供应商系统

• 针对履约流程中“订单分拣-配送调度”环节平均45s/单的延迟瓶颈，主导异步化改造：基于Celery 5.3构建分层任务队列，将串行的“订单详情获取→配送员匹配→状态更新”拆分为独立子任务；结合Redis Cluster缓存高频访问的配送站点覆盖范围与骑手实时负载数据（QPS峰值达1.2万），减少MySQL查询次数60%。最终将该环节延迟降至12s/单，支撑日均订单峰值从100万提升至150万，履约及时率从92%升至98%
• 推动供应商协同接口标准化：基于OpenAPI 3.0定义统一契约规范，采用Pact框架实现消费者驱动的契约测试，解决原接口参数不兼容、响应格式混乱问题；同时封装requests库的异常重试与熔断逻辑（基于tenacity库），将供应商接口调用成功率从95%提升至99.9%，减少人工排查时间80%
• 设计库存准确性保障体系：针对“超卖”与“库存冻结不一致”问题，引入Redis分布式锁（redlock算法）控制库存扣减逻辑，结合数据库乐观锁（version字段）实现双重校验；同时搭建实时库存对账任务（基于Apache Airflow调度），每日凌晨核对仓库WMS与系统库存，差异率从0.3%降至0.01%
• 主导履约系统监控体系搭建：基于Prometheus+Grafana构建指标看板，跟踪“订单处理时长”“配送调度成功率”“供应商接口响应时间”等15个核心指标；集成Alertmanager实现异常告警（如订单积压超10万触发钉钉通知），将故障定位时间从30分钟缩短至5分钟内

负责食材全链路溯源系统后端开发，支撑每批次食材“产地-加工-仓储-终端”全流程溯源码生成与查询，保障数据一致性与时效性，服务B端商家与C端用户的溯源需求

• 解决溯源系统高并发查询性能问题：针对溯源码查询接口QPS从1000骤增到8000的瓶颈，采用Redis多级缓存策略——一级缓存存储热点溯源码数据（过期时间5分钟），二级缓存存储溯源链路元数据（如产地批次、加工车间），将查询响应时间从200ms降至50ms以内，缓存命中率达92%
• 实现跨系统数据实时同步：对接上游ERP系统的食材批次数据，采用Debezium CDC工具捕获数据库binlog变更，通过Kafka消息队列传递至溯源系统，替代原有的定时ETL同步方式；解决数据延迟问题（从1小时缩短至1分钟），同时通过幂等消费逻辑（基于消息ID去重）保障数据一致性，错误率从0.1%降至0
• 优化权限管理粒度：原RBAC模型无法满足“区域商家仅查看本地溯源数据”的需求，扩展为RBAC+ABAC混合模型——基于用户区域属性与数据标签动态计算访问权限；使用Casbin框架实现策略管理，支持可视化配置，权限校验耗时从10ms降至2ms，满足10万+商家的细粒度访问需求
• 构建自动化测试体系：采用pytest框架编写接口测试用例，结合factory_boy生成测试数据，覆盖溯源码生成、查询、数据同步等核心场景；引入Allure生成测试报告，测试覆盖率从65%提升至88%，上线前缺陷率下降70%

参与生鲜电商后台管理系统基础功能开发，支撑商品管理、订单处理、库存盘点等核心流程，保障系统稳定性与用户体验

• 重构商品分类模块：原模块采用Django原生ORM实现，接口响应慢（平均300ms/次）且难以维护。改用Django REST framework重构，优化序列化逻辑（排除冗余字段），并添加Redis缓存分类树结构；最终接口响应时间降至80ms/次，支撑商品运营人员快速操作，操作效率提升50%
• 优化订单超时处理逻辑：原方案采用Celery定时任务每5分钟扫描超时订单，资源消耗大（CPU占用率15%）。改为基于Redis Sorted Set的延迟队列，将订单超时时间作为score存储，定时轮询Top100订单判断是否超时；资源占用率降至3%，日均处理超时订单1.2万单，准确率100%
• 解决数据库慢查询问题：通过EXPLAIN分析订单表查询语句，发现“按用户ID+下单时间排序”的查询未命中索引，新增复合索引（user_id, create_time DESC）；将该查询耗时从1.2秒降至150ms以内，支撑用户“我的订单”页面快速加载，页面打开率提升20%
• 协助搭建CI/CD流程：使用Jenkins搭建自动化部署 pipeline，整合GitLab CI代码检查、pytest测试、Docker镜像构建与K8s部署；将部署时间从45分钟缩短至15分钟，上线频率从每周1次提升至每日3次，支撑快速迭代需求

星途直播平台高并发弹幕系统重构与性能优化项目

• 星途直播平台顶流主播开播时，原单体架构弹幕系统暴露严重性能瓶颈——峰值延迟达2s+、丢包率5%，核心痛点是消息队列吞吐量不足（RabbitMQ仅1万条/秒）、Redis分片不均引发热点、传统MD5去重算法内存占用高。我的目标是重构系统以支撑单直播间200万+并发弹幕，将延迟压降至500ms内、丢包率低于1%，同时担任整体架构设计与核心模块开发负责人。
• 项目面临三大技术挑战：一是单体架构无法横向扩展，二是现有消息队列难以承载高并发写入，三是弹幕去重与排序的效率问题——传统MD5去重需存储全量弹幕哈希，内存消耗呈指数级增长；而单纯时间戳排序易导致消息乱序。
• 我主导架构拆分为“生产-存储-推送”三个微服务：用Kafka替代RabbitMQ，利用其分区机制实现消息并行消费，吞吐量提升至10万条/秒；针对去重问题，设计“布隆过滤器预过滤+Redis Set精准校验”的双层机制——布隆过滤器拦截99%重复弹幕，Redis仅存储未命中弹幕的哈希，内存占用降低80%；排序环节引入时间轮算法，将弹幕按时间窗口缓存并顺序推送，CPU消耗减少40%。
• 项目上线后，单直播间支持250万并发弹幕，延迟降至280ms，丢包率仅0.08%；服务器数量从8台缩减至5台，年运维成本降低35%；用户弹幕发送成功率从95%提升至99.9%，该方案被纳入公司直播技术中台，我也因此晋升为直播业务后端负责人。

星途电商平台全链路库存一致性系统建设项目

• 星途电商大促期间（如618、双11），库存超卖（峰值0.1%）、多渠道（APP/小程序/抖音小店）库存同步延迟（5秒+）问题突出，导致订单取消率高达15%，严重影响用户体验与营收。我的目标是搭建全链路库存一致性系统，将超卖率降至0.01%以下、库存同步延迟控制在1秒内，同时负责库存服务架构设计及跨系统协同。
• 原系统存在三大核心问题：一是同步依赖同步RPC调用，易引发雪崩；二是缺乏分布式事务支持，多渠道库存更新不同步；三是MySQL库存变更无法实时同步到缓存，导致前端显示与实际库存不一致。
• 我推动库存服务从单体拆分为“中心-同步-校验”三个微服务：基于Seata实现TCC分布式事务（Try阶段预留库存、Confirm确认扣减、Cancel释放库存），解决跨渠道库存一致性问题；用Canal监听MySQL binlog，实时将库存变更同步到Redis与ES，保证缓存与数据库的一致性；设计多渠道库存统一缓存层，通过分布式锁协调不同渠道的库存扣减，避免超卖。
• 系统上线后，超卖率降至0.003%，库存同步延迟降至0.3秒，大促订单取消率降低至8.5%；每年节省因超卖、同步问题导致的人工客服与赔付成本约220万；该方案成为公司电商库存标准架构，我因此获得当年公司“技术突破奖”，并主导了后续供应链库存扩展项目。

• 大二观察到毕业生离校时大量教材被废弃，而新生购书支出占生活费12%，便发起校园书籍教材循环计划。为解决传统二手书交易效率低的问题，我们开发微信小程序实现扫码估价、预约取件功能，并说服快递中心以成本价承接物流。
• 通过建立翻新消毒标准打消卫生顾虑，项目年流通教材1.2万册，累计为同学节省书费38万元。这段经历让我从商业小白成长为能设计闭环模式的实践者，项目不仅获省级创业金奖，更被纳入学校官方服务体系延续至今。