前言
高并发通常出现在活跃用户量大、流量聚集的业务场景中，例如秒杀活动、定时领取红包等。为了让业务流畅运行并保证良好的交互体验，我们需要根据预估的并发量设计适合当前场景的处理方案。
在电商产品开发的实践中，我们遇到过各种并发下的问题。这里总结了一些经验，希望能作为参考分享给大家。
服务器架构基础
随着业务发展，服务器架构会从单一走向集群，再到分布式服务。一个能支撑高并发的服务离不开合理的架构设计：负载均衡（如 Nginx、阿里云 SLB）、数据库主从集群、NoSQL 缓存主从集群以及静态文件 CDN 加速。
服务器搭建通常需要运维配合，这里主要关注架构层面的选型：
- 均衡负载：Nginx、SLB
- 资源监控：确保系统健康度
- 数据库：主从分离、集群、表与索引优化
- NoSQL：Redis、MongoDB、Memcache 的主从集群
- CDN：加速 HTML、CSS、JS、图片等静态资源
并发测试与评估
高并发业务上线前必须进行压力测试。利用第三方工具或自建测试环境，模拟大量请求以评估架构的承载能力。这不仅是预警参考，更是'知己知彼'的关键。
常用测试工具包括：
- 阿里云性能测试
- Apache JMeter
- Visual Studio 性能负载测试
- Microsoft Web Application Stress Tool
通用高并发方案
适用于日流量大但相对分散，偶尔出现用户聚集的场景，如用户签到、订单查询、用户中心等。
核心思路： 这些业务多为大数据表的查询操作。为了减少直接命中数据库的压力，优先查询缓存，若缓存未命中再查库并将结果回写缓存。对于用户相关数据，建议采用分布式存储（如 Redis Hash），通过用户 ID 进行 hash 分组，避免单点热点。
具体流程示例（用户签到）：
- 计算用户分布 Key，在 Redis Hash 中查找今日签到信息。
- 若命中，直接返回。
- 若未命中，查询数据库是否已签到。若已签到，同步更新 Redis 缓存后返回。
- 若数据库也无记录，执行签到逻辑（事务操作 DB 添加记录及积分），随后将签到信息写入 Redis 并返回。
注意点： 需处理并发下的重复签到问题，防止积分被多次发放。
其他业务（订单、用户中心）： 类似地，仅缓存高频访问的数据（如第一页订单）。通过分布式 Key 管理缓存，确保查询效率。
公用缓存注意事项： 对于非用户专属的公用缓存，需防范并发导致的缓存击穿或雪崩。可通过管理后台更新或加锁机制保护。
消息队列削峰
针对秒杀、抢红包等瞬间高并发写入场景，直接操作数据库会导致宕机风险。此时应引入消息队列。
方案： 将用户参与信息推入队列（如 Redis List），后端通过多线程程序消费队列数据，异步完成发红包等业务逻辑。这样既能支持高并发请求，又能保护数据库不被瞬间流量击垮。
扩展应用： 消息队列还可用于定时任务，如短信发送。使用 Sorted Set 按时间戳排序，定时轮询读取并发送，实现精准调度。
多级缓存策略
一级缓存
当高并发请求超过缓存服务器连接上限时，部分用户会超时。此时可在应用服务器内存中设置一级缓存，仅存储热点数据，并设置秒级过期时间。这能有效减少对 NoSQL 服务器的连接压力。
适用场景： APP 首屏商品数据等公共且更新不频繁的数据接口。
静态化与 CDN
对于更新频率低、允许短暂延迟的数据，可静态化为 JSON、HTML 等文件上传至 CDN。请求时优先走 CDN，未命中再回源。需注意 CDN 节点同步的延迟性，选择可靠的 CDN 服务商。
客户端缓存
APP 或 PC 端可缓存本地数据，请求时携带版本号。服务端比对版本号，一致则直接响应状态码，不一致则返回最新数据。这能显著节省服务器带宽资源。
