负责公司核心订单履约系统的全链路架构设计与迭代，覆盖从用户下单到骑手完成配送的关键环节，保障系统在高并发（日均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%，提升团队交付质量

实时库存风控与动态定价系统重构

• 项目背景：电商大促期间传统库存系统因行锁粒度粗、一致性保障弱，超卖率高达0.8%；同时动态定价依赖离线计算，响应延迟超500ms，导致客诉率攀升、营收转化损失约15%。我的核心职责是主导库存引擎与定价中枢的模块化设计，衔接前端业务需求与底层分布式组件，实现高并发下的库存精准管控与实时定价。
• 关键难题：1. 高并发下库存扣减的性能瓶颈——传统方案QPS仅能支撑3000，无法应对大促峰值；2. 库存与价格的联动一致性问题——库存变化需实时触发价格调整，但跨系统调用延迟易导致数据不一致；3. 动态定价的多源数据聚合延迟——需整合库存、销量、竞品价格等6类数据，离线计算无法满足实时性要求。
• 核心行动与创新：1. 库存引擎采用「分段锁+Redis原子操作」方案，将库存拆分为100个逻辑分段，通过Lua脚本实现分段内的原子扣减，将QPS提升至15万；2. 设计「库存-价格联动事件队列」，基于Kafka传递库存变更事件，定价服务消费事件后实时调整，从根源解决一致性难题；3. 定价中枢引入Flink流处理框架，对多源数据进行1分钟级窗口聚合，预计算常用定价策略，将动态定价响应时间从500ms压缩至80ms。
• 项目成果：重构系统支撑2023年双11期间1200万单交易规模，超卖率降至0.08%以下，动态定价响应时间达标率99.9%；客诉率减少65%，直接带动营收提升12%。本人主导的「库存分段模型」被纳入公司技术中台标准，推广至服饰、3C等5个核心品类，成为大促期间的关键稳定性保障。

内容社区Feed流高并发与个性化推荐性能优化

• 项目背景：社区用户量从500万增长至1200万，Feed流接口首屏加载时间长达2.1秒，个性化推荐准确率仅68%，导致月活留存率下降11%。我的职责是牵头Feed流架构升级，解决性能瓶颈与推荐效果问题，支撑业务从「用户增长」向「留存转化」转型。
• 关键难题：1. 单体架构耦合严重——Feed流服务依赖用户、内容、推荐等8个模块，单次修改可能引发全链路故障；2. 兴趣标签查询慢——用户标签需关联3张关系型数据库表，查询耗时300ms，影响推荐时效性；3. 推荐模型迭代与线上服务冲突——算法团队每周更新模型，需重启服务导致流量波动，影响用户体验。
• 核心行动与创新：1. 拆分微服务架构，将Feed流拆分为「内容拉取」「兴趣过滤」「排序推荐」3个独立服务，用gRPC实现通信，降低模块间耦合；2. 引入Elasticsearch构建用户兴趣画像索引，将标签查询时间从300ms降至50ms，支撑实时兴趣匹配；3. 设计「模型热更新机制」，用TensorFlow Serving部署推荐模型，算法团队通过API更新模型参数，无需重启服务，同时通过本地缓存保存常用版本，应对突发流量峰值。
• 项目成果：Feed流首屏加载时间降至380ms以内，个性化推荐准确率提升至90%；系统QPS从8000提升至5万，支撑日活300万的并发请求；月活留存率回升至45%，推动社区DAU季度环比增长18%。本人主导的微服务拆分方案成为公司内容板块的基础架构，后续孵化出短视频Feed流、话题Feed流等新业务线，支撑公司估值提升30%。

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