一则面试题，如果 10 万人同时打赏某快手主播，对支付系统来说，瓶颈在哪里，该怎么解决呢，组件是 mysql， redis 等，假如打赏的钱加到主播余额而不是去银行那边进行交易

luckyrayyy

2020-06-08 10:57:51 +08:00

快手的面试题？十万人可以分开处理，主播的余额那里是瓶颈吧。我首先能想到的就是并发量太大了，需要做个队列，把加钱的动作串行化，但是效率肯定堪忧。另外突然想起来 JUC 包里 LongAdder 的思想，空间换时间，是不是可以给主播创建多个虚拟账户，先把加钱动作完成，余额数字不追求实时准确了。

xmh51

2020-06-08 11:01:15 +08:00

可以按照聚合请求然后单次更新来解决

peyppicp

2020-06-08 11:08:59 +08:00

如果要求实时的话，瓶颈在数据库，主播的账户是热点账户

不要求实时的话，打赏这种行为可以直接落单，然后 T+1 再进行结算到主播余额

fifa899

2020-06-08 11:11:19 +08:00

瓶颈应该是 MYSQL IO 吧.打赏记录表只有 Insert.那就做个队列..可以先丢进 redis 队列.再做个定时批量插入吧. 余额就是 select sum(打赏金额)咯

wmlhust

2020-06-08 11:12:07 +08:00

分成几个层面：
1. 接入层：瓶颈在于并发，这个可以通过加资源、优化性能解决
2. 业务层：对于支付本身的逻辑，实时处理。各种上下游、周边逻辑，比如弹幕播报，特效等，这种尽量通过消息队列去耦合，异步处理。
3. 存储层：这里是关键，如果设置一个 mysql 余额表，显然撑不住十万的并发写，每一个请求都要对该行加锁。但是又不能完全依靠 redis，可能会导致数据丢失，不一致等。
一个方案是，使用消息队列+mysql 存储流水，使用 redis 存储余额，定时对账。
由于流水是追加写，不涉及到加锁，同时可以通过分库分表等提升性能。
redis 提供余额的高并发读、写，但是对单机 redis，十万 QPS 也扛不住，redis 集群两个方案，主从或 cluster，在这个场景，主从更合适（因为 cluster 对单 key 是固定路由到一个节点，所以没办法提升单 key 的处理能力）。再考虑到十万的并发写，这个只能牺牲一点余额的实时性，大概可以通过 group commit 或 kafka 异步更新缓存。
-----
瞎想的，不对的地方，各位老铁随意指出

chmaple

2020-06-08 11:15:33 +08:00

打赏主播不是同时支付。
支付操作肯定要事务的，但是支付是到账户余额上的，然后从账户的虚拟金额进行抵扣。
所以这个问题就拆成，并发十万的礼物请求，主播的收入计算，以及最高几千 TPS 的充值请求。

十万的礼物请求，其实是分开在每个用户账户下的，那么就是相互不影响的库存抵扣了。
主播的收入计算完全可以做 T+1 延迟结算，没必要做成实时更新同一条目这么大的压力。
充值请求的话要好好做，那就是支付子系统如何设计的问题了。