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

[jdz]

[kkkkkrua]

这比秒杀系统还要简单把，瓶颈应该在 10W 个并发请求那

[w292614191]

锁、乐观锁、悲观锁、原子锁、分子锁、粒子锁、分布式锁、队列、缓存。
一堆技术词堵住你先。

[hantsy]

主播余额和走银行有什么差别，现在支持不是都是银行网关通道，大 Boss 都要有记录。

[jdz]

@kkkkkrua 并不是啊， 现在是 10 万人给主播加余额啊 数据库会有热点， 由于是支付， 对数据精确性要求很高
@w292614191

[luckyrayyy]

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

[xmh51]

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

[peyppicp]

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

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

[fifa899]

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

[wmlhust]

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

[chmaple]

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

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

[binux]

哪有什么瓶颈，虽然是同时打赏一个主播，但是却没人任何数据需要同步交互。
你创建 10 万个毫无关联的独立订单，订单完成后再去主播那加一就行了。别说是同时加 10 万次余额，你就是花一个月加完都行啊，反正加少了别人也不知道啊。

[opengps]

系统设计成支持水平扩容的，那就没有技术瓶颈，更多的瓶颈来自于监管压力

[xnode]

... 这有个毛线瓶颈 主播的钱又不是实时到账的,打赏的钱先扣了再说

[None123]

打赏不是直接到主播的支付宝的 。。。

[ajaxfunction]

为什么只有我感觉 没有瓶颈？
不就是写入十万条 sql 记录？，而且这位 10 万条还不是同时写入的，也不要求写入顺序， 还不涉及库存什么的
我感觉事务都用不上

[accacc]

@ajaxfunction 事务肯定是要有的 用户钱出 主播钱进 不过不要求实时性这问题到简单

[xcstream]

tcp 链接比较多， 当然分几台服务器问题不大
数据先用 redis incr redis 单线程并发可以 10w 的
然后可以慢慢的用 mysql 跑

[netnr]

就好比 10W 的请求 日志怎么存储

[firefox12]

没有人说 kafka, 你们的交易消息直接落 redis, 不怕掉啊？直接打后面 不考虑后面节点挂掉吗？

[yukiloh]

我觉得不如解决 10w 人看视频不卡的问题...