• 负责公司核心支付清结算系统的开发与维护，设计的每日对账与差错处理平台，将财务人员的对账工时从4小时缩短至15分钟，且准确率达到100%，每年挽回资金差错超百万元。
• 实现的多通道动态路由与降级方案，在主支付通道故障时能自动无缝切换至备用通道，支付成功率提升了3个百分点，峰值时段保障了交易资金安全。
• 将系统核心表进行水平分表（从单表千万级拆分），并实现了在线数据迁移，解决了长期困扰业务的数据库性能瓶颈，为后续业务高速增长扫清了障碍。

• 独立负责「用户积分中心」从0到1的建设，通过Redis原子操作+Lua脚本保证了高并发下的积分增减准确性，系统上线后稳定支撑了所有营销活动，日均处理积分交易超千万笔。
• 开发的自动化数据报表系统，替代了手动SQL查询，为运营和产品团队提供了50+张实时数据看板，数据需求响应时间从1天缩短至5分钟，驱动了数据化运营。
• 通过引入Spring Boot和自动化部署工具，将团队新服务的搭建和部署效率提升了数倍，成为后续项目的事实标准。

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

• 项目背景：公司核心直播业务年增速达40%，原基于Spring Boot+Redis的单节点推模式弹幕系统，在峰值QPS突破1.2万时出现严重延迟（平均250ms）、丢弹率升至0.15%，且Redis因大key问题频繁内存溢出。我的核心目标是主导系统全链路重构，支撑峰值5万QPS、延迟≤100ms、丢弹率<0.01%的严苛要求。
• 关键难题：①高并发下弹幕分发的低延迟瓶颈，原有单节点推模式无法横向扩展；②Redis存储弹幕元数据时，大key（单直播间弹幕列表超10万条）导致内存占用过高、查询延迟飙升；③弹幕去重与顺序性保证难以兼顾——原有布隆过滤器方案误判率高，且无法维持跨分片的消息顺序。
• 核心行动：1. 架构层面改用“Kafka削峰+推拉结合”模式：用Kafka做消息缓冲，拆分“写入层”（异步消费Kafka存TiDB）与“分发层”（基于Redis Cluster的多级缓存，热点直播间单独分片）；2. 自研轻量级弹幕索引服务：用“布隆过滤器+分片序列号”解决去重与顺序问题——每个直播间按用户ID分16个分片，分片内用Redis Sorted Set存序列号，既降低大key风险又保证顺序；3. 存储层替换：用TiDB替代MySQL，支持弹幕数据的水平扩展与HTAP混合查询，解决持久化瓶颈。
• 项目成果：重构后系统峰值QPS达6.8万，延迟降至75ms以内，丢弹率<0.005%，Redis内存占用较之前下降40%；成功支撑公司年度直播盛典（单场最高在线1200万），业务侧用户满意度调研显示“弹幕流畅度”评分从3.2分提升至4.5分。我主导输出了《直播类高并发系统设计规范》，成为公司同类项目的技术标准。

用户行为分析平台实时计算核心引擎开发项目

• 项目背景：公司需构建用户行为分析平台，支撑运营实时调整直播/活动策略，但原有基于Storm的实时计算方案存在延迟高（平均800ms）、复杂事件处理（CEP）性能差（规则匹配耗时占比60%）的问题。我的职责是主导实时计算核心引擎开发，实现百万TPS吞吐、延迟≤500ms、支持自定义CEP规则的目标。
• 关键难题：①Storm的Spout/Bolt模型灵活性不足，难以应对动态规则变更；②复杂事件处理（如“用户30秒内连续点赞+评论”）的规则解析效率低，原有正则匹配方案拖慢整体吞吐；③跨设备用户行为关联困难——不同终端生成的ID无法统一，导致行为数据碎片化。
• 核心行动：1. 技术选型切换至Flink：利用其DataStream API的状态管理与Checkpoint机制，优化故障恢复时间至10秒内，同时支持动态加载规则（通过配置中心实时推送至TaskManager）；2. 自研CEP引擎：用DFA（确定性有限自动机）替代正则匹配，将规则编译为状态转移图，规则匹配耗时从15ms/条降至5ms/条；3. 设计全局唯一ID方案：基于雪花算法优化，加入设备指纹维度，解决跨端用户行为关联问题，关联准确率达99.9%。
• 项目成果：引擎上线后支撑日均1.2亿条行为数据的实时处理，延迟稳定在300ms以内；支撑运营侧实现“促销活动实时调优”——某次美妆直播中，通过实时分析用户停留时长与点击路径，快速调整福袋发放策略，使直播转化率提升15%。我主导的“Flink+自研CEP”方案成为公司实时数据处理的基础框架，后续支撑了会员行为分析、广告效果追踪等多个场景。