上一篇
非关系型数据库在高并发瞬秒中如何应用，有哪些优势？
瞬秒业务的核心挑战
瞬秒活动通常在极短时间内吸引大量用户并发请求,远超日常流量，给系统带来巨大压力，传统关系型数据库（如 MySQL）在此场景下容易暴露以下问题：
- 高并发读写冲突：大量请求同时更新同一行库存记录，导致行锁竞争，事务处理能力急剧下降，响应延迟升高。
- 磁盘 I/O 瓶颈：关系型数据库依赖磁盘持久化，即使有缓存层，突发写入仍会触及磁盘性能上限。
- 扩展困难：分库分表虽能横向扩展，但实现复杂，且难以保证实时一致性，对瞬秒这种热点集中的场景并不友好。
非关系型数据库（NoSQL） 凭借其内存存储、高并发处理能力和灵活的数据结构，成为瞬秒系统架构中的核心组件。
非关系型数据库在瞬秒中的典型应用
Redis：瞬秒的“瑞士军刀”
Redis 是瞬秒场景中最常用的 NoSQL 数据库，主要得益于以下特性：
- 内存存储：读写速度可达微秒级，轻松应对每秒数万甚至数十万 QPS。
- 丰富的数据结构：String、Hash、List、Set、Sorted Set 等，满足不同业务需求。
- 原子性操作：支持 Lua 脚本，保证多个操作在服务端原子执行，避免并发竞争。
库存预热与扣减
将商品库存提前加载到 Redis 中，利用其原子操作完成扣减，避免直接冲击数据库。
- 初始化库存：SET product:1001:stock 500
- 原子扣减：使用 DECR 命令，当返回值小于 0 时表示库存不足。
- Lua 脚本保证复合操作：若需同时判断库存并记录用户购买资格，可编写 Lua 脚本一次性完成。
local key = KEYS[1] -库存键 local uid = ARGV[1] -用户ID local stock = redis.call('GET', key) if stock and tonumber(stock) > 0 then redis.call('DECR', key) redis.call('SADD', 'success_users', uid) return 1 else return 0 end
限流与防刷
利用 Redis 的 Sorted Set 或 String + 过期时间 实现简单高效的限流器。
- 滑动窗口限流：使用 ZSET 记录用户请求时间戳，按时间窗口控制频率。
- 令牌桶算法：通过 DECR 配合过期时间模拟令牌消耗。
分布式锁
当某些操作（如同步库存到数据库）需要跨服务互斥时，可使用 Redis 的 SET NX EX 实现分布式锁，确保同一时刻只有一个节点执行关键任务。
MongoDB：存储瞬秒订单与记录
虽然 Redis 负责核心交易链路，但瞬秒产生的订单数据仍需要持久化，MongoDB 作为文档型数据库，具有以下优势：
- 高写入吞吐：相比关系型数据库，MongoDB 在批量写入和分片扩展上更具弹性。
- 灵活 Schema：订单结构可能随活动变化，无需预先定义所有字段，便于快速迭代。
- 二级索引完善：支持对用户 ID、商品 ID、时间等字段建立索引，查询效率高。
在实际架构中,Redis 完成库存扣减后，将订单信息通过消息队列异步写入 MongoDB，实现削峰填谷并保证数据最终一致。
消息队列（如 Kafka / Redis Streams）的辅助作用
非关系型数据库通常与消息队列配合,构成完整的瞬秒链路：
- 异步解耦：Redis 扣减成功后将消息发送至队列，下游消费者负责生成订单、扣减账户余额等。
- 流量缓冲：瞬时高并发写入先进入队列，MongoDB 或 MySQL 按自身能力消费，避免过载。
典型瞬秒架构流程
| 步骤 | 组件/操作 | 说明 |
|---|---|---|
| 活动预热 | Redis | 将商品库存、活动规则等数据加载到 Redis，避免数据库查询 |
| 用户请求到达 | Nginx / 网关 | 负载均衡与初步限流，过滤无效请求 |
| 库存预扣减 | Redis（Lua 脚本） | 原子性校验库存并扣减，记录用户购买资格 |
| 消息异步投递 | Kafka / RocketMQ | 扣减成功的请求封装为消息，写入队列 |
| 订单生成 | 消费者服务 | 拉取消息，校验用户信息，写入 MongoDB 或 MySQL |
| 结果通知 | WebSocket / 轮询 | 告知用户瞬秒结果，前端展示 |
非关系型数据库瞬秒的注意事项
- 数据一致性：Redis 扣减库存与最终数据库订单之间存在时间差，需设计对账机制和补偿流程（如定时任务扫描 Redis 记录并与数据库对比）。
- 缓存穿透与雪崩：瞬秒前将所有商品信息加载到 Redis 并设置永不过期，或使用互斥锁防止大量请求同时查询数据库。
- 热点 Key 问题：单一商品的库存 Key 可能成为热点，可采用 分槽库存（将库存拆分为多个 Key，如 stock:1001:1、stock:1001:2）分散压力。
- 持久化策略：Redis 的 RDB 或 AOF 配置需权衡性能与数据安全，必要时可开启秒级持久化，防止重启后库存丢失。
相关问题与解答
Redis 扣减库存后，如果订单入库失败怎么办？如何保证不超卖？
解答：这是典型的最终一致性问题，常用方案包括：
- 回滚机制：订单入库失败时，发送消息触发 Redis 库存回滚（INCR），同时记录失败日志。
- 对账与补偿：定时任务对比 Redis 扣减记录与数据库订单表，对于超时未入库的扣减进行人工或自动补偿。
- 预扣减 + 确认制：Redis 扣减只是“预占”，订单生成后才真正视为售出，可设置一个合理的预占有效期（如 15 分钟），超时未确认则自动释放库存，这样即使下游失败，库存也会自然恢复。
Redis 单节点能支撑那么高的并发吗？Redis 宕机了怎么办？
解答：生产环境中 Redis 通常采用集群 + 哨兵或Cluster 模式部署：
- 性能：单个 Redis 实例可轻松处理 10 万以上 QPS，瞬秒场景下，通过分槽库存（将单商品库存分散到多个 Key 或分片）可进一步提升吞吐。
- 高可用：使用哨兵模式（Sentinel）实现主从自动切换，或使用 Redis Cluster 原生分片与故障转移，主节点宕机后，从节点晋升为主，保证服务不中断。
- 持久化：开启 AOF 并结合 RDB，即使所有节点意外重启，也能从持久化文件中恢复大部分库存数据，配合对账流程弥补少量丢失。
