一直在思考,记录一点一滴
分类: 架构设计与优化
2018-06-22 09:21:50
作者 : 杨考 微信号 : devin_cn_hd_09_16
热点账户就是在交易过程中,出现频次特别高的账户,交易频次指的是某个时间段的交易频次一直保持在比较高的次数。
如果是数据操作错误重试导致某账户瞬时出现高频操作,则不属于热点账户范畴。
1) 账户每秒有10次以上更新需求
2) 串行化时账户处理延迟高于1秒以上
即类似于你有一个银行卡,一直接存钱和提现,因为频次过高,你的余额都来不及实时更新了,
此时解决方法就是再办一张同行的卡,或者其它银行的卡,一起承担存钱和提现的需求
向银行申请,为该主卡办理多个子卡,用子卡进行分流
申请一个专门接收打款的卡
申请一个专门接受提现的卡
先把所有的打款、提现的请求入队列,延时处理账户余额更新
把某个特征相似的操作进行合并处理。即把别人一万次打款请求合并为一个打款请求,此时最终只需要申请一次打款,其它人的卡逐个扣款
提现就不好解决了,可以增加一个提现缓冲卡,但是迫不得已,可以把多次提现请求,合并为一个请求,先从该账户把钱提到提现缓冲卡,再由提现缓冲卡分发给其它目标账户。
天底下没有一个通用的解决方案,热点账户问题,都是根据场景,逐个击破的。
热点账户类型 |
账户属性 |
实时需求 |
锁需求 |
处理方式 |
性能 |
业务大账户 |
内部账户 |
无实时余额查询 无实时提现 |
无需加锁 |
异步MQ延时处理 |
满足 |
大代理商账户
|
对外账户 |
无实时余额查询 无实时提现 |
没有加锁需求 |
异步MQ延时处理 |
满足 |
热门商户(推广) |
对外账户 商户账户 |
实时余额查询 实时提现 |
有加锁需求 |
串行化同步 |
亟待提升 |
1) 在异步化背景(账户实时处理的上游,如果已经存在了异步化的处理)下,此时业务所需要的下游的实时性是不可能完全实时的
2) 对于热点账户而言,问题在于一条数据表项的更新频次已经达到了上线,所以解决热点账户的方案可以从解决数据读取的瓶颈出发。