小程序开发服务
专业微信小程序定制开发，电商、教育、医疗等行业解决方案。
先判断量级：中小系统不必一上来就堆架构
注册用户多就一定需要高并发架构设计吗？未必。很多老板的直觉反应是，活动怕崩，赶紧把缓存、队列、分库分表全加上。真正做容量评估时，要看峰值QPS、慢SQL、数据库CPU和接口响应时间，而不是只看注册用户数。
某社区团购小程序日常DAU约3000，早高峰促销10分钟进入12000人。按100秒集中提交估算，平均每秒120个请求，峰值按3倍估算约360请求/秒；一个下单链路平均执行5条SQL，数据库峰值约1800 SQL/秒。按2026年主流云厂商的常见规格，一台4核8G云数据库跑简单主键查询可能有3000至6000 QPS，但包含库存、优惠券、订单关联的复杂写请求通常只有200至500 QPS。这台库不崩才怪。
| 业务特征 | 优先动作 |
|---|---|
| 峰值读请求低于800 QPS，SQL基本走索引 | 优化SQL、索引、连接池和业务逻辑 |
| 热点读超过800 QPS，读写比高于5:1 | 引入Redis或本地缓存 |
| 写流量峰谷差超过3倍，任务可短暂延迟 | 引入消息队列削峰 |
| 单表超2000万行，写QPS持续超3000 | 评估分区、读写分离或分库分表 |
高并发架构设计不是等流量来了才补，也不是小系统提前背重包袱。先压测，再按瓶颈选组件，通常比一次性“全家桶”更省钱。
缓存：热点读超过800 QPS时优先考虑
缓存适合读多写少、数据可接受短时间延迟的场景。商品详情、活动配置、用户画像、门店列表这类数据，一次更新后被大量读取，应该挡在Redis或本地缓存里。
判断信号很直接：峰值期间数据库CPU连续5分钟超过70%；同一条商品详情SQL每秒执行超过800次；接口P95响应超过300毫秒，而慢查询主要集中在热点读取。
我们接触过一个酒水促销项目，6000个SKU在活动开始后商品详情读QPS冲到4200。原来每次查库还要关联分类、库存展示，数据库CPU冲到96%。加Redis后热点详情TTL设为30至120秒并加随机过期时间，数据库相关查询下降约95%，接口P95从320毫秒降到45毫秒。
缓存不是只写个set。查询不存在的数据要缓存空值防穿透；热点Key过期要加互斥重建或逻辑不过期；大批Key过期时间要打散，防止雪崩。写路径可以采用“先更新数据库再删除缓存”，重要数据配合消息重试或订阅binlog补偿。
消息队列：写峰值是均值3倍以上再引入
消息队列解决的是瞬间写流量把下游打垮和同步链路太长两个问题。下单后发短信、扣积分、发券、生成统计流水，都不必须挤在请求线程里。
引入信号包括：写请求峰值是均值3至5倍；高峰期接口P95超过500毫秒；一个请求同步调用4个以上服务；任务允许延迟几百毫秒到几十秒。某秒杀活动10秒内2.4万请求，峰值3500请求/秒，而日常订单写仅300请求/秒。系统先在Redis扣库存，通过RocketMQ或Kafka按800至1200请求/秒匀速投递，消费者按租户和商品ID路由，30秒左右消化积压，用户端显示“排队中”。
- 不能异步的强一致扣款、实时余额，不要盲目放队列；
- 消费端必须幂等，用订单号或业务唯一键去重；
- 失败重试要有次数限制，失败消息进入死信队列人工处理；
- 队列积压、消费延迟和消息丢失率要接入监控。
说白了，队列是把“立刻扛住”变成“排队处理”，用户体验和数据一致性要提前定义清楚。
分库分表：单表超2000万行后再评估
分库分表是末位选项，不是性能优化的起点。数据量不到千万级就拆库，多半是把简单问题复杂化。
只有当单表数据量超过2000万行或单表物理文件超过100GB、即使索引合理P95仍超过500毫秒、主库写QPS持续在3000以上、垂直升配已经没有明显性价比时，才值得认真评估。在此之前，冷数据归档、读写分离、按时间分区、增加只读副本，往往能解决大部分问题。
一个SaaS订单表累计1.8亿行，团队最初想按订单号哈希拆16库16表。调研后发现80%查询带tenant_id，后来按租户哈希分8库、每库按时间分表，近3个月热数据保留在独立热表。改造耗时约5周，包含压测、数据校验和双写切换；上线后订单写入P95从760毫秒降到110毫秒。代价也明显，跨租户统计、分页排序、唯一索引和运维监控都要额外处理，开发工作量比单库阶段高出约2倍。
分片键选错，后面几乎每条SQL都在跨片聚合。订单业务优先用user_id或tenant_id，商户后台查询则可能需要冗余一份商户维度数据，不能指望中间件自动解决。
中小系统的落地顺序和实际案例
中小系统的落地顺序应是：压测摸底、SQL和索引治理、热点缓存、异步队列、冷数据归档与读写分离，分库分表应排在末位。活动前按预期峰值的1.5至2倍压测，重点看P95/P99、数据库连接数、慢查询和服务线程池。
服务器抗压不只靠加机器。应用节点无状态化后可水平扩展，但数据库连接池、日志磁盘、第三方接口限流常常先成为瓶颈。如果短信通道只支持200 QPS，应用做到10000 QPS也没有意义。
我们上个月刚交付的项目里，一家区域零售连锁小程序预估大促8000人同时在线。团队没有急着分库，而是用Redis承载商品和库存热点读，用消息队列承接订单创建后的券和通知，MySQL继续单库主从。压测峰值读QPS约4200、订单创建约900 QPS，活动当天数据库CPU约62%，接口P95约180毫秒。
汇智云码科技总部位于山东青岛，核心团队来自腾讯、阿里、字节等互联网公司，已服务120+企业客户、交付41+真实案例。类似的容量评估和高并发改造，可以查看真实案例，或通过技术咨询服务获取分阶段方案。对多数中小系统而言，先把缓存和队列用对，比过早分库分表更稳、更省。