负责公司核心订单履约系统的全链路架构设计与迭代，覆盖从用户下单到骑手完成配送的关键环节，保障系统在高并发（日均150万单）场景下的稳定性与毫秒级响应，协同产品、算法团队优化履约效率与成本

• 主导订单处理模块的异步化重构：针对原同步处理逻辑导致的峰值延迟问题（订单积压超10万单/小时），采用Celery+Redis Cluster构建分布式任务队列，拆分「接单-分配骑手-确认取件」大任务为原子化子任务，引入任务分片与优先级队列机制，解决消费者处理瓶颈；最终订单全链路处理延迟从500ms降至150ms，峰值吞吐量提升3倍，支撑双11期间200万单/日的高峰流量
• 设计骑手实时轨迹同步系统：为解决弱网环境下轨迹更新丢失与延迟问题，基于WebSocket+MQTT协议搭建双向通信链路，结合Redis Pub/Sub实现状态缓存与离线消息重发；针对轨迹数据一致性痛点，设计幂等性校验（基于订单ID+时间戳哈希）与断点续传机制（记录最后成功同步的位置）；上线后轨迹更新成功率从95%提升至99.9%，骑手端定位延迟降低至200ms以内，客诉率下降40%
• 推动数据库性能优化与成本管控：通过Py-Spy性能 profiling 定位到订单列表接口慢查询（响应时间800ms+）源于多表关联缺少复合索引，添加`(order_status, create_time, rider_id)`联合索引，同时将近7天热点订单缓存至Redis（采用LFU淘汰策略，TTL设置为10分钟）；优化后接口响应时间降至120ms，数据库CPU利用率从75%降至30%，月度数据库成本减少25%
• 协同算法团队落地路径规划服务：将算法团队的Dijkstra优化算法输出（JSON格式路径坐标）转化为后端可调用的路线规划微服务，使用FastAPI搭建服务并定义OpenAPI 3.0契约，针对高并发场景（1万次/秒路径计算）调整Gunicorn配置（worker=16, worker_class=gevent），并通过Locust压测验证服务稳定性；服务上线后响应时间稳定在50ms以内，支撑日均100万单的路径计算需求

负责公司同城跑腿系统的后端开发与微服务转型，覆盖用户下单、任务派单、支付结算全流程，保障业务快速迭代的同时提升系统扩展性与可靠性

• 主导系统微服务拆分项目：将原单体应用拆分为「订单服务」「派单服务」「支付服务」三个核心微服务，使用Django REST framework+Docker构建服务容器，通过gRPC实现服务间通信；解决单体应用部署慢（2小时/次）、故障扩散问题，部署时间缩短至15分钟，故障隔离率提升至90%，支撑业务线从3个扩展至8个
• 优化支付回调链路可靠性：原同步支付回调逻辑易因网络波动导致订单状态不一致，改为异步处理方案——用RabbitMQ做消息队列，添加指数退避重试机制（最大重试5次，间隔10s递增）与死信队列（人工介入处理失败消息）；上线后支付成功率从92%提升至98%，回调处理延迟从1秒降至300ms，支付相关客诉减少60%
• 搭建后端性能监控体系：基于Prometheus+Grafana构建监控平台，采集服务QPS、响应时间、错误率、数据库连接池利用率等指标，设置阈值告警（如错误率超1%触发钉钉通知）；通过监控及时发现订单服务数据库连接池耗尽问题，调整连接池大小（从20增至50）并优化SQL查询，避免线上P0级故障，系统可用性从99.5%提升至99.9%

协助开发公司内部OA系统与客户管理系统（CRM）的后端功能，参与需求分析、编码测试与线上问题排查，掌握Python后端开发全流程与团队协作规范

• 独立开发OA系统请假审批模块：采用Django框架实现RESTful API，对接MySQL数据库，设计「待审批-审批中-已通过-已拒绝」状态机，支持多级审批（直属领导→部门经理→HR）；上线后处理1000+条请假申请，无重大bug，审批流程效率提升50%（从1天缩短至半天）
• 优化文件上传功能性能：原功能直接上传文件至服务器，导致存储成本高（月度100GB+）且上传速度慢；改用阿里云OSS存储，通过Python boto3 SDK实现分片上传（10MB/片），添加文件类型（仅允许PDF/Excel/图片）与大小（≤20MB）校验；优化后存储成本降低40%，上传速度提升50%，支持大文件上传
• 搭建自动化测试体系：用pytest编写单元测试（覆盖核心函数）与集成测试（覆盖API接口），测试覆盖率达到80%；减少回归测试时间（从2天缩短至半天），上线后bug率下降30%，提升团队交付质量

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

• 星途直播平台顶流主播开播时，原单体架构弹幕系统暴露严重性能瓶颈——峰值延迟达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万元。这段经历让我从商业小白成长为能设计闭环模式的实践者，项目不仅获省级创业金奖，更被纳入学校官方服务体系延续至今。