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

[jdz]

[realpg]

这个 没啥瓶颈……
我的垃圾 PHP 程序都能 handle

[ISSSSSSS]

@lewis89 对，其实这问题比秒杀要简单。题里的关键的锁是在用户支付后更新主播的余额。而秒杀是购买的那一刻就有资源竞争。前者主播的余额显示不及时其实问题不大，最终一致就可以了，但是后者如果用户无法下单支付就显得十分严重了。解决此类问题其实就是不断的把请求分片。不管是 nginx 还是 mysql 。

[hanhan13]

@ISSSSSSS 有个问题是，你说的 2 、3 、4 是有事务约束的，只要用户支付成功，那就要保证能给主播充值上。采用分布式事务似乎不能满足 QPS 要求，不知道您有什么思路？我的想法是用队列加一组单独的充值处理应用来异步完成 3 、4 。

[ISSSSSSS]

@hanhan13 2 ->3，3->4 的过程 可以存在事物也可以不存在（假设数据已经分片）。但我更倾向于使用生产者消费者模式去解决。比如用 MQ，再通过补偿机制去核对补充。
总之所有的都是通过最终一致性的思路去设计的。所以并不需要强事务。

[aqqwiyth]

支付宝双 11 并发 11W

[xuanbg]

瓶颈在数据库，前面加个队列削峰就行。

[hanhan13]

@ISSSSSSS 可以简单介绍下一般采用什么样的补偿机制去核对吗？对这块不是很清楚，感谢~

[ISSSSSSS]

@hanhan13 补偿机制的话其实就是个业务。
具体问题具体分析。比如说 2->3 的过程。
如果是通过 mq 的方式去处理，那么会面临一下几个问题。
1 MQ 没发出去。2 MQ 发出去了，但是丢了。3 MQ 服务挂掉。4 处理 MQ 的应用发生错误。
那么最终会反映到数据存上的状态不一致。比如服务 2 有数据 但是服务 3 没数据。或者没处理。
比较简单的补偿，其实就是让服务 2 重复发送 MQ，但是也存在一定的问题。
比较高级的处理方式是，直接监控服务 2 、4 的 binlog （或者是其他数据库的 log ），通过 binlog 去比对，如果发生不正常的情况（比如状态不一致，数据丢失），那么再去处理。补偿的同时也要考虑到重复补偿的问题。
当然即使做到万全准备，还是可能会出现问题。那么这个时候就需要定时程序去核对数据。避免资损。

[lewinlan]

瓶颈就是主播余额上的锁
解决思路，用户的钱先锁上，生成订单，然后丢到队列里去一个个用事务转账。
打赏后延迟几秒几分钟到账咋了？没影响~

[strict]

并发不大的情况下处理流程：
一用户扣钱：
1 扣钱前加锁，行锁级别，判断钱是否够，同时防止一个人脚本并发打赏
2 扣钱动作实时 commit
3 交易 log 消息队列异步处理去创建
二主播余额：
1 消息队列异步增加余额。
2 redis 做主播信息缓存用，定期同步 redis 和 mysql

十万并发情况下，发现数据库锁成了瓶颈，考虑到业务成本的锁逻辑不应该由数据库来控制，看扣钱时的数据库加锁换成 redis 锁。

[nl101531]

一句话，共享的地方是瓶颈，如果对应一条余额记录的话，那这个是瓶颈，可以锁拆分考虑，拆成多账户。

[nl101531]

@xiangyuecn 双十一支付 tps 貌似好几十万了

[mlboy]

@wangdashuai 哈哈这个思路不错

[thinkmore]

@coolmenu 兄弟，你是要笑死我！

[danhahaha]

瓶颈是去哪里找这十万人

[bzj]

你们为啥非要认为打赏一笔就要转账，用户充值和主播提现这两个走支付系统，打赏行为只是个数字的变化而已

[blackboom]

这里有 N 个 10W 在同时进行，并没有那么简单。

[liuxingdeyu]

我突然觉得，这 10w 个要是飘屏的大礼物，对 im 的压力应该不小