泛娱乐社交APP「星聊」全链路架构升级与性能优化项目
- 项目背景:「星聊」作为公司核心泛娱乐社交产品,早期采用单体架构+MyBatis传统ORM模式,随着用户量突破800万,逐渐暴露接口平均响应超800ms、峰值并发下消息丢失率达0.3%、热点数据缓存击穿引发服务雪崩等问题,严重影响用户体验与业务增长。我的核心目标是主导完成架构从单体到微服务的重构,同时解决实时通信与高并发场景下的稳定性痛点,支撑产品冲刺千万级MAU。
- 关键难题:1)单体拆分后的服务间通信延迟——原有HTTP调用在高并发下延迟高,无法满足实时聊天场景的毫秒级响应要求;2)消息系统的可靠性——直播聊天室场景下常出现消息乱序、丢失,用户投诉率高;3)热点数据缓存策略失效——明星直播间等场景下,Redis频繁出现缓存击穿,导致DB压力骤增甚至宕机。
- 核心行动:1)基于DDD领域驱动设计完成服务拆分,划分「用户中心」「消息中心」「关系链中心」等6个核心域,采用Spring Cloud Alibaba微服务框架实现服务治理,通过gRPC替代HTTP完成服务间通信,将平均调用延迟从300ms降至50ms内;2)消息系统引入RocketMQ,针对聊天场景定制「消息持久化+幂等消费+顺序队列」方案——为每个聊天室创建顺序队列,结合消息ID去重表解决重复问题,消息送达率从99.2%提升至99.98%;3)缓存层升级为Redis Cluster,设计「热点数据预加载+布隆过滤器防击穿」策略:提前将明星直播间等热点房间的用户列表、最新消息加载至缓存,通过布隆过滤器拦截无效key请求,将缓存命中率从75%提升至92%;4)前端配合采用Vue3+Vite重构,优化首屏资源加载,将TTI(可交互时间)从3.2s降至1.1s。
- 项目成果:架构升级后,接口平均响应时间稳定在200ms内,并发处理能力从1万TPS提升至5万TPS,成功支撑产品MAU突破1200万;消息系统稳定性显著提升,用户关于「消息丢失/延迟」的投诉率下降92%;缓存策略优化后,DBQPS峰值从8千降至1.2千,服务器成本降低30%。我个人主导了微服务拆分方案与消息系统设计,成为团队技术决策的核心成员。