摘要

2023年3月，我参与了某省级政务服务平台“统一预约与在线办理系统”的重构项目，担任系统架构师。该项目要求支撑日均百万级用户访问、峰值并发请求超过8000 TPS，且核心业务接口响应时间不超过200毫秒。本文以该项目为例，论述了高并发系统架构设计的核心技术实践。在架构设计中，我们重点解决了三个关键问题：一是通过读写分离与多级缓存化解数据库读瓶颈；二是采用业务异步化与消息队列削峰填谷应对瞬时写入洪峰；三是借助分库分表与冷热分离实现数据层的水平扩展。项目实施后，核心业务接口TP99响应时间稳定在180毫秒以内，系统峰值处理能力达到12000TPS，连续两次“政务抢号”活动平稳度过，未发生服务熔断或数据库死锁。通过本次实践，我总结高并发架构设计应遵循“静态化优先、异步化兜底、分片化扩展”的核心原则。

正文

一、项目背景与主要工作

2023年3月，某盛大数据局启动“统一预约与在线办理系统”重构项目，我做系统架构设计师负责总体架构设计与核心模块技术选型。原系统上线于2019年，基于传统的Spring MVC+单库单表架构，随着“一网通办”政策的深入推进，业务量在两年内增长了15倍，数据库连接池频繁打满、慢查询导致线程阻塞、大促期间预约服务不可用等问题屡次发生。

重构后的系统需要满足以下核心指标：支持日均100万次预约请求、峰值并发8000TPS；核心业务（预约、查询、缴费）接口95%响应时间<=200ms、99%响应时间<=500ms;系统全年可用性不低于99.95%；支持未来三年业务量增长三倍以上。

我作为系统架构师，主要工作包括：梳理核心业务链路的性能瓶颈；完成数据存储方案、缓存侧脸、异步机制的整体设计；指导团队进行压测与调优，并负责故障预案与回滚策略的制定。

二、高并发架构设计的关键问题与策略

高并发系统的核心矛盾在于：有限的硬件资源与不可预测的海量请求之间的矛盾。从技术角度分析，主要面临三大类问题：读多写少场景下的数据库查询压力、瞬时洪峰导致资源耗尽、数据量持续增长后的存储与查询瓶颈。

针对上述问题，我们制定了如下总体策略：

• 分层分流：静态资源走CDN，动态请求经网关限流后分发至应用层。
• 读写分离：写操作走主库，读操作走从库或缓存。
• 异步削峰：非实时链路（如短信通知、状态回调）通过消息队列异步处理。
• 水平拆分：数据量大的业务表采用分库分表，并实施冷热数据分离。

下文将依次阐述三个核心难点的具体方案与落地实践。

三、高并发架构关键难点的设计与实践

难点一：如何化解数据库读瓶颈？——多级缓存+读写分离

原系统中最突出的问题是：首页推荐时段列表和大厅预约状态查询请求量极大，直接冲击数据库。我们设计了“本地缓存→分布式缓存→数据库”三级缓存架构。

（1）本地缓存（Caffeine）：将配置类数据（如大厅列表、业务类别、时段模板）缓存于各应用节点内存中，设置过期时间为1分钟。本地缓存命中率超过85%，响应时间小于1ms。

（2）分布式缓存（Redis Cluster）：将用户会话、预约令牌、临时草稿等半结构化数据存入Redis，采用“更新数据库后删除缓存”策略保证一致性。对于热点预约时段，我们增加了布隆过滤器预防缓存穿透。

（3）数据库读写分离：我们使用了MySQL主从架构，主库处理写入事务，三个从库分担查询负载。应用层通过动态数据源路由实现读写分离，核心查询（如“查询某大厅剩余号源”）强制走从库。

在落地过程中，我们遇到一个重要难点：从库复制延迟导致用户预约后立即查询状态时偶尔读到旧数据。解决方案是“关键读主，非关键读从”——用户提交预约后5秒内对该预约的查询走主库，其他场景允许短暂不一致。同时优化了从库配置、开启并行复制，将延迟从平均500ms降至100ms以内。

难点二：如何应对瞬时写入洪峰？——业务异步化与消息队列削峰

政务业务具有明显的“整点抢号”特征：放号瞬间集中了大量预约请求，若所有请求同步写入数据库，连接池会迅速耗尽。我们引入RocketMQ实现业务异步化。

具体设计：用户提交预约请求后，网关生成预约令牌并立即返回“排队中”状态。请求体发送至消息队列，消费端以可控速率（例如每秒2000条）从队列拉取并进行数据库写入、号源扣减。成功或失败的结果通过长连接推送至前端。

关键挑战：如何保证号源扣减不超卖？我们采用了数据库乐观锁（版本号机制）结合Redis原子递减。用户请求入队前，先在Redis中对目标时段号源预扣，若预扣成功则允许入队；消费端真正落库时再次校验。这样既保护了数据库，又利用Redis的高性能完成了前置过滤。

效果：消息队列将峰值从8000 TPS平滑到2000 TPS写入数据库，数据库连接池使用率从95%降至40%。两次全省统一放号活动中，系统稳定运行，无积压消息超过5秒。

难点三：如何支撑海量数据增长？——分库分表与冷热分离

预约记录表半年即达到2亿行，单表查询性能显著下降。我们实施了水平分库分表和冷热数据分离。

分库分表策略：根据预约记录的“年份+月份”哈希分片，共分8个库，每个库32张表。分片键选择“用户ID”的哈希值，保证同一用户的所有预约记录落在同一分片，便于查询。同时，对原有按时间范围查询的业务，我们建立了全局索引表（用户ID—分片映射），查询时先定位分片。

冷热分离：近3个月的预约数据为“热数据”，保留在分片表中；3个月以上的历史数据定期迁移至归档库（TokuDB引擎，高压缩比）。业务层面，默认查询只展示3个月内记录，需要查询历史时跳转至“历史预约查询”专用页面。

迁移方案：我们采用“双写+历史回刷”策略——系统上线后新数据同时写入分片表和归档库，历史数据按时间窗口分批回刷。整个迁移过程在线完成，对业务无感。

辅助措施：限流降级与全链路压测

为保证极端情况下的系统韧性，我们完善了限流降级机制：网关层基于令牌桶算法对全局并发进行限流（上限10000 TPS），超出请求返回“系统繁忙”提示；应用层使用Sentinel对核心资源（如数据库连接、MQ生产者）配置熔断规则，当错误率超过20%时自动熔断30秒。降级预案包括：关闭非核心功能（如预约评价、推荐算法），保障核心预约链路。

每次上线前，我们均进行全链路压测，通过模拟用户行为逐步加压，定位瓶颈节点。压测中发现了数据库热点行更新锁竞争问题（针对同一热门时段的号源扣减），我们通过将号源预扣逻辑拆分到Redis + 最终一致性写入数据库的方式解决了该问题。

实施效果与经验总结

该系统于2023年8月正式上线，截至2025年5月已稳定运行近两年。关键指标达成情况如下：

• 性能指标：核心接口TP99响应时间稳定在180ms（目标≤200ms）；峰值处理能力达到12000 TPS（目标8000 TPS）。
• 可用性：全年可用性99.96%（目标99.95%）。
• 成本：数据库服务器从重构前的16台降至8台（约50%降幅），存储成本通过冷热分离降低约35%。
• 业务成果：成功支撑两次全省统一放号（单日最高预约量38万次），无故障、无超卖。

本次实践中，我深刻体会到高并发架构设计的三个核心原则：一是静态化优先，能走缓存的不走数据库；二是异步化兜底，瞬间洪峰必须用队列削平；三是分片化扩展，单库永远是瓶颈。同时，我也认识到几个不足：例如初期对布隆过滤器参数配置不当导致一定比例的误判，以及消息队列消费端监控指标不够细化。后续我们将增加智能监控与自适应限流策略，进一步提提升系统的自愈能力。

通过本次高并发系统架构的设计与落地，我不仅掌握了具体的技术方案，更重要的是建立了“面向风险设计、面向容量设计”的架构思维，为今后处理更大规模的分布式系统打下了坚实基础。