高频热点账户(和库存类似但稍有不同)如何解决高并发余额计数问题？
这个问题和秒杀,库存问题是类似的.
https://yq.aliyun.com/edu/lesson/play/270
LongAdder fei33423 java分段高并发计数器,用于统计计算分析.
【公开课】【阿里在线技术峰会】何登成：AliSQL性能优化与功能突破的演进之路
write.blog.csdn.net/postedit/47340675?ticket=ST-202343-fYu0bMCATjor1YrOjMgM-passport.csdn.net
何登成-库存热点更新. 有补充语音笔记
【阿里在线技术峰会】何登成：AliSQL性能优化与功能突破的演进之路
1. 去并发--排队是解决这个问题的核心.
n个线程. 被分层n组. 通过库,表,行逐级hash,智能扩容缩https://yq.aliyun.com/edu/lesson/play/270 .
如果库层级不排序,那么就业务方通过redis分布式锁处理,做到mq通知. mq会是瓶颈.
何登成-mysql库存最大500并发量.--- 4k --并发提交后4w
2. 批量提交 -登哥使用了这个技术
3. 切分帐户,库存字段. 分别抢购. 会导致获取总量较复杂.
并且要循环扣(每次扣1个),或者可能导致余额不足但不保证有少量余额.
(需要动态的缩减帐户数量.锁帐户然后操作转移钱款 ( 分布式锁,最好一条存储过程搞定,少一次网络交互.). select num from update set num-num where account_id=1;然后 update set id2.num+=id1.num where id=2;
4. 特殊场景,前端业务自行拦截(下沉到数据库服务端会导致无效逻辑判断过多. 功能越复杂,自然cpu计算就多.例如B+树降级为hash索引).总量就是4,那么一旦排队大于4*x (或者手动定死控制)个后就设置标志位拦截所有请求. (这个和客户端线程池有异曲同工之妙)
支付宝需要有个账户记账，现在很多业务已经出现了很多热点账户。比如互联网大商家，\\\
账号有余额，主要用于不能扣成负数。 大并发交易下余额快速变化，导致数据库竞争等待。
原则: 不同的业务要求,不同的设计,同时会影响业务需求.
三大需求,是否都容易满足:
1.减款
2.加款
3.读取总金额
最简单设计: 帐户表+流水表. 每次帐户加减款都需要增加流水,和帐户变动.
业务需求: 高并发帐户.
技术选择 1. 悲观锁(高并发帐户), 乐观锁(普通并发帐户). 3. 顺序化 同步转异步,mq 降低峰值.
存储选择: redis 还是 数据库. redis本身并发能力就是比数据库要好. 但是单机支持的数据量不如数据库大. 只存放account的值的话到还好.
账户转账分两个接口，一个可扣成负数,一个不能扣成负数.
1 如何消除余额竞争呢？
方案一：变成两个账户 模仿 担保交易，设置两个账户 1. 扣款账户 2. 加款账户
1.1. 商家都是频繁加款 ,加款账户只记流水,不计算余额. 避免频繁竞争
1.2. 加款帐户的流水定时汇总到扣款帐户上.
1.3 扣款账户用于退款和提现, 因为频率不高. 即保证余额控制,也没有并发问题. 退款有些业务能扣成负数,有些业务不能.
缺点: 进入的钱不一定能时时能用. (对小商家不适用,比较计较)
优点: 这样就避免了热点账户的余额计算。
方案二： 账户分普通账户，加频账户，减频账户，双频账户
类型为加钱频繁账户，加钱不改变余额，定时任务收集改变。 捡钱操作时时进行。
减频账户，拆分子账户。
扣款只账户会有个问题，前面扣掉了，但是最后不够扣。
最佳方案，回滚，即逆操作，加款。
次佳方案， 使用只能扣成一次负数
双频账户：加款依然如此，减款同上。
延迟提现问题：即2天内收入只允许某种业务扣款（内部消费，代驾现金抵扣），但不允许提现扣款。
采用普通账户，但是要满足提现延迟方案？
小商家加的钱必须时时能用. 又要求延迟提现怎么办?
只能通过订单维度,目前这个订单现在有多少钱冻结中(已退款的钱不应该冻结). 展现哪些订单是冻结的,冻结金额是多少.
一旦钱被消费了, 账户余额可能少于订单的冻结的金额,可提现余额可能为负数.
客户可能来投诉, 因为他自己意识不到钱被消费了(抵扣信息费)和提现金额变少有关联.