10万人直播间打赏场景下的账户余额扣减架构设计

Corey2025/12/30大约 9 分钟面试题面试题

来源：10万人直播间打赏场景下的账户余额扣减架构设计

一、场景核心挑战分析

在 10 万人同时在线的直播间打赏场景中，账户余额扣减面临三大核心挑战，也是架构设计需优先解决的问题：

高并发写入压力：打赏行为具有突发性（如主播高光时刻可能引发每秒数千次扣减请求），需支撑TPS 5000+ 的峰值写入，避免服务过载；
数据一致性保障：扣减需满足 “不超扣、不重复扣”，确保用户账户余额与实际消费匹配，避免资损或用户投诉；
高可用与低延迟：打赏是实时互动行为，用户需即时看到扣减结果（如 “余额不足” 提示），服务不可用或延迟超 100ms 会严重影响体验。

二、整体架构设计（分层架构）

采用 “接入层 - 业务层 - 数据层” 三层架构，结合缓存、异步队列、分布式事务等中间件，形成 “削峰 - 控量 - 保一致” 的完整链路，架构图如下（简化版）：

用户端 → CDN → 接入层（Nginx+API Gateway） → 业务层（打赏服务+账户服务） → 数据层（缓存+数据库）

&#x20;                         ↓                    ↓

&#x20;                   限流熔断                异步队列（消息中间件）

三、各层详细设计方案

（一）接入层：流量入口的 “削峰与过滤”

接入层是高并发的第一道防线，核心目标是 “提前拦截无效流量、平抑峰值压力”，采用大厂常用的 “网关 + 限流” 组合：

API Gateway 选型：使用字节内部的 BFE（ByteDance Frontend Engine） 或开源的 Spring Cloud Gateway，统一承接所有打赏请求；
多级限流策略：

全局限流：限制单直播间每秒最大扣减请求数（如 10000 次，避免超出下游承载能力）；
用户级限流：限制单用户每分钟最大打赏次数（如 60 次，防止恶意刷量或误操作）；
维度：基于 “直播间 ID + 用户 ID” 的组合键限流，使用 Redis 分布式锁实现（避免单机限流瓶颈）；

流量过滤：拦截非法请求（如未登录、签名无效、参数缺失），直接返回错误，减少下游无效调用。

（二）业务层：核心逻辑的 “高可用与一致性”

业务层拆分 “打赏服务” 和 “账户服务”，遵循 “单一职责” 原则，同时通过异步化、分布式事务保障核心逻辑：

1. 服务拆分与职责

打赏服务：负责打赏逻辑处理（如校验打赏金额合法性、生成打赏订单、触发后续通知）；
账户服务：专注于账户余额管理（仅提供 “余额查询”“余额扣减”“余额回滚” 三个核心接口），避免业务逻辑耦合导致的复杂度上升。

2. 关键流程设计（以 “用户打赏 100 钻石” 为例）

（1）预校验：减少无效扣减请求

打赏服务收到请求后，先做预校验：

校验打赏金额：需为正数且不超过单笔打赏上限（如 10000 钻石）；
缓存查余额：先查询 Redis 中的用户余额缓存（而非直接查 DB），若缓存余额＜100，直接返回 “余额不足”，避免穿透到数据库。

（2）分布式锁：防止并发超扣

若预校验通过，打赏服务先获取 “用户 ID + 账户类型” 的分布式锁（使用 Redis Redlock 或 Zookeeper），锁超时时间设置为 500ms（避免死锁）：

锁获取成功：进入扣减流程；
锁获取失败：返回 “系统繁忙，请重试”（避免并发请求同时扣减导致超扣）。

（3）余额扣减：“缓存先行 + 异步落库”

账户服务执行扣减的核心逻辑，采用 “缓存实时扣减 + 数据库异步更新” 的模式，平衡 “实时性” 与 “高并发”：

Redis 缓存扣减：

执行 Redis 原子操作 DECRBY balance:user:123 100（原子操作避免并发问题）；
若扣减后余额≥0：缓存扣减成功，进入下一步；
若扣减后余额＜0：立即执行 INCRBY balance:user:123 100 回滚缓存，释放分布式锁，返回 “余额不足”；

生成打赏订单：打赏服务生成唯一订单号（使用 “用户 ID + 时间戳 + 随机数” 生成，确保唯一性），订单状态设为 “待确认”；
异步落库与事务保障：

打赏服务将 “扣减记录 + 订单信息” 封装为消息，发送到 Kafka/RocketMQ 队列（主题：account-deduction-topic）；
账户服务消费该消息，执行数据库扣减（更新用户账户表 user_account 的 balance 字段，同时插入扣减日志表 account_deduction_log）；
分布式事务保障：采用 “最终一致性” 方案（而非强一致性的 2PC，避免性能瓶颈）：
消息队列确保 “至少消费一次”；
账户服务消费消息时，先查扣减日志表：若已存在该订单号的记录，直接跳过（避免重复扣减）；若不存在，执行 DB 扣减并记录日志。

（4）结果返回与解锁

缓存扣减成功后，立即释放分布式锁，向用户返回 “打赏成功”（此时用户已能看到余额变化，满足实时性需求）；
后续 DB 落库结果不影响用户实时体验（若 DB 落库失败，通过 “补偿任务” 修复，见下文 “容灾设计”）。

3. 异步化与解耦

非核心逻辑（如 “发送打赏通知给主播”“更新直播间打赏总榜”）通过消息队列异步处理，避免阻塞扣减主流程；
消息队列选型：使用 Kafka（字节内部常用），单分区吞吐量可达 10 万 + TPS，满足高并发需求。

（三）数据层：存储的 “分层与容灾”

数据层采用 “缓存 + 数据库” 的分层存储，同时通过分库分表、日志表保障数据安全：

Redis 缓存设计：

数据结构：使用 String 类型存储用户余额，Key 为 balance:user:{userId}:{accountType}（如 balance:user:123:diamond）；
缓存更新策略：
写缓存：扣减时直接更新 Redis（原子操作）；
读缓存：查询余额优先读 Redis，缓存缺失时从 DB 加载并回写缓存（设置过期时间 30 分钟，避免缓存膨胀）；
部署模式：采用 Redis Cluster 集群（3 主 3 从），每个主节点负责部分用户的缓存，避免单机瓶颈；

数据库设计：

核心表：
user_account（用户账户表）：存储用户当前余额，分库分表键为 userId（按用户 ID 范围分 1024 个库，每个库分 32 个表，总 32768 张表，支撑亿级用户）；
account_deduction_log（扣减日志表）：存储每笔扣减记录（订单号、用户 ID、扣减金额、时间戳），作为对账和回滚依据，分库分表键与账户表一致；
数据库选型：使用 MySQL（字节内部常用），开启 binlog 用于数据恢复；

数据一致性保障：

定时对账：每小时执行 “Redis 缓存余额 vs 数据库余额” 的对账任务，若发现不一致（如缓存多扣、DB 少扣），以 DB 为准修复缓存；
日志回溯：所有扣减操作均记录日志，支持问题排查（如用户投诉 “余额不对” 时，可通过订单号查询日志）。

四、容灾与降级设计（大厂核心关注点）

1. 服务降级策略

轻度降级：当 Redis 缓存不可用时，暂时直接查 DB（但增加 DB 压力，需配合限流）；
重度降级：当 DB 压力过高（如 CPU 使用率超 80%），暂停非核心直播间的打赏功能（如热度＜1 万的直播间），优先保障高热度直播间；
降级触发：通过监控系统（如 Prometheus+Grafana）实时监控 TPS、响应时间、错误率，达到阈值自动触发降级。

2. 故障恢复机制

Redis 故障：若某 Redis 主节点宕机，从节点自动切换为主节点（Redis Cluster 自带故障转移），同时通过哨兵监控节点状态；
DB 故障：若某分表所在的 MySQL 实例宕机，暂时将该分表的请求路由到备用实例（主从切换），同时触发告警；
消息丢失：若 Kafka 消息丢失，通过 “死信队列”（DLQ）存储失败消息，定时重试（重试 3 次后仍失败，人工介入）。

3. 回滚机制

场景：若打赏后发现订单异常（如用户误操作、系统 bug），需回滚余额；
流程：

校验回滚权限（如仅管理员或系统可发起）；
查询扣减日志，确认该订单已扣减；
执行 “余额回滚”：先更新 DB 余额（INCR balance），再更新 Redis 缓存（INCRBY），最后记录回滚日志。

五、性能压测与优化（落地前必经步骤）

1. 压测指标

目标：支撑 5000 TPS 扣减请求，响应时间＜100ms，错误率＜0.01%；
压测工具：使用 JMeter 或字节内部压测工具，模拟 10 万用户并发打赏（按 “80% 用户每分钟打赏 1 次，20% 用户每分钟打赏 5 次” 的比例设计场景）。

2. 优化点（基于压测结果调整）

若 Redis 成为瓶颈：增加 Redis 集群节点数，或优化 Key 分布（避免热点 Key，如某头部主播的用户集中在同一 Redis 节点）；
若 DB 成为瓶颈：优化 SQL（如给 user_account 的 userId 字段建索引），或增加 DB 只读实例分担查询压力；
若服务成为瓶颈：增加业务层服务实例数（水平扩容），使用容器化部署（K8s）实现自动扩缩容。

六、方案总结（贴合大厂实际的核心亮点）

高并发支撑：通过 “接入层限流 + 缓存先行 + 异步落库”，将 TPS 从 DB 承载上限（千级）提升到 Redis 承载上限（万级）；
数据一致性：通过 “分布式锁 + 原子操作 + 定时对账”，确保 “不超扣、不重复扣”，避免资损；
高可用保障：通过 “服务拆分 + 集群部署 + 容灾降级”，确保单点故障不影响整体服务；
可扩展性：分库分表设计支撑亿级用户，容器化部署支持弹性扩缩容，符合大厂业务增长需求。