账务实时交易系统设计思考-【第四节】-热点问题
【思考点滴】
作者 : 杨考 微信号 : devin_cn_hd_09_16
本文是【讲解篇】和【技术分享篇】结合起来，由于CSDN文章图片丢失，又补了一次图片。同时进行了章节拆分。
全量版 https://blog.csdn.net/yk200808/article/details/80755459
第一节:业务简介 https://blog.csdn.net/yk200808/article/details/81624677
第二节:业务分析 https://blog.csdn.net/yk200808/article/details/81624779
第三节:功能设计 https://blog.csdn.net/yk200808/article/details/81624826
第四节:热点问题 https://blog.csdn.net/yk200808/article/details/81624861
第五节:准确性 https://blog.csdn.net/yk200808/article/details/81624899
第六节:使用建议 https://blog.csdn.net/yk200808/article/details/81624917
第七节:思考总结 https://blog.csdn.net/yk200808/article/details/81624934
4 热点问题
如下是几大热点问题:每个问题的具体处理方案在后面有详述。
4.1 大并发
简要解析：同步和异步并存，是一个综合方案，可以保证账务处理的实时性，如下方案的优、缺点以及引发的问题，在下图有详述。
4.2 大数据量
4.3 热点账户
4.3.1热点账户的概念:
热点账户就是在交易过程中，出现频次特别高的账户，交易频次指的是某个时间段的交易频次一直保持在比较高的次数。
如果是数据操作错误重试导致某账户瞬时出现高频操作，则不属于热点账户范畴。
4.3.2 热点账户的判别标准
1) 账户每秒有10次以上更新需求
2) 串行化时账户处理延迟高于1秒以上
4.3.3 热点账户的处理方案
| 热点账户类型 |
账户属性 |
实时需求 |
锁需求 |
处理方式 |
性能 |
| 业务大账户 |
内部账户 |
无实时余额查询 无实时提现 |
无需加锁 |
异步 |
满足 |
| 大代理商账户
|
对外账户 |
无实时余额查询 无实时提现 |
没有加锁需求 |
异步 |
满足 |
| 热门商户(推广) |
对外账户 商户账户 |
实时余额查询 实时提现 |
有加锁需求 |
串行化同步 |
亟待提升 |
4.3.4 热点账户总结
1) 在异步化背景(账户实时处理的上游，如果已经存在了异步化的处理)下，此时业务所需要的下游的实时性是不可能完全实时的
2) 对于热点账户而言，问题在于一条数据表项的更新频次已经达到了上线，所以解决热点账户的方案可以从解决数据读取的瓶颈出发。
4.5 实时性-high-实时账务更新
4.5.1 实时账务更新
4.5.2.1 完全实时设计实现
业务直接调用账务系统交易的API接口，实时处理账务交易，所谓的实时交易，也是进行了一定的优化（同步和异步相结合）。
1) 商户账户扣费，使用的是实时扣费
a）账户更新使用redis锁代替数据库锁，同样也是悲观锁，不过请求不阻塞，请求延迟很小
b ) 请求锁失败，业务继续重试请求。
c ) 平台内部账户仍然采用异步余额更新，减少了分账的锁阻塞几率，有效保证了同步更新的成功率，即减少了锁请求失败的概率。
2) 百度外卖推广收入账户，同样采用的是异步更新账户金额的方式。因为这个账户是平台共用，属于热点账户，锁阻塞很严重，但是该账户的任何行为和表现不会影响到商户账户余额更新，所以这里使用异步更新的方式，消除了热点账户的影响。
4.5.2.2 完全实时场景
CPC（按点击扣费）业务，账户提现等
4.5.2 上游调用方对用户或者账户进行分桶，防止同一账户被同时更新而造成的冲突
4.6 实时性-middle-非实时的准实时更新
4.6.1 准实时的实现
各业务的资金分账，入消息队列，调用账务交易平台资金操作接口，账务平台按分账需求和分账状态处理账务消息
4.6.2 准实时性能
通过消息队列处理账务交易信息，QPS基本不是瓶颈
通过对业务和订单散列细分，账务交易系统可以有序、快速处理资金，
支持批量请求，从业务层解除数据依赖和状态依赖
最终测试结果：账户余额更新最差延迟时间控制在15秒内。
4.6.3 准实时业务场景
用户订单，物流订单等账务处理都是非实时需求场景
更多精彩内容
