摘要：全局热点账户平台支出账户平台收入账户过渡账户。。那么亲，这和热点账户没关系，即使你查询一个非常普通的账户，碰巧该账户同时在更新，你也查不准。。
问题描述
在某一瞬间，单个账户集中的发生资金变动，若不加控制，其账户余额会因发生脏读、覆盖更新等情况而错误记录。如果简单的以悲观锁、乐观锁的方式限制，虽然不会发生数据错误，但会造成服务不可用（该账户的更新请求全部失败）。而请求重试、再次网络通信的开销并不能忽略不计。
在账户系统的实际业务中，发生“热点账户”情况的一般有两种：
局部热点账户
还款时 一人 -> 多人
放款时 多人 -> 一人
债转时 多人 -> 一人（基于业务系统的特定场景设置，此处认为债权转出人为热点账户）
局部热点账户可通过分布式锁的方式处理，本文不再赘述。
全局热点账户
平台支出账户、平台收入账户、过渡账户。。这些账户总是在发生资金变动
前提
既然是普适的解决方案，那就考虑该账户会大量并发的发生余额增加、余额减少、余额冻结、余额解冻的操作，其中余额冻结和余额解冻可视同为增、减，简化模型，下面以Hot账户为例
思路
1.收到请求 -> 2.落库待处理，返回处理中 -> 3.落库数据批量汇总处理，状态控制 -> 4.返回处理结果(取决于第2步)
第2步可根据实际业务，返回成功(例如业务上余额无限大的账户或者允许为负值的账户)
示意图
说明
H账户初始资金为0，几乎同时收到请求：H账户放款给A账户100，放款给B账户100，C账户还款给H账户50，D账户还款给H账户250
数据按顺序落库后，跑批任务汇总处理，假设每次处理3条
第一个批次经过计算，发现余额不足，于是将(3)余额增加的操作先执行，并更新状态，(1)、(2)不执行也不更新
第二个批次经过计算，余额充足，执行所有操作并更新状态
冻结／解冻
虽然冻结相当于减，解冻相当于增，但是冻结得优先于解冻执行，所以最终得出了如下执行顺序：
增->冻结->解冻->减
实时余额如何得到
首先我要问，什么场景下我们需要得到实时余额？
判断钱够不够扣，够不够冻结？
No no no，我们要求热点账户的资金处理都必须异步，这意味着请求发过来只会得到处理中，成功与否我们会通知你。而且就是你查询的时候钱充足，并不意味着发生变动的时候也充足，这类查询是没有意义的。要么像ZF这类钱永远充足的账户，查询就更没有意义了
财务、审计。。whatever需要统计数据？
这个可以有，我们将账户余额和缓冲记录表内的数据实时计算告诉你。但是不要说我实时计算的余额不准，因为会有未提交的事务balabala。。那么亲，这和热点账户没关系，即使你查询一个非常普通的账户，碰巧该账户同时在更新，你也查不准。。实时计算的余额在那一瞬间是准确的，而且我认为这类需求不会很大
一些特殊账户有优化吗？
只增不减、只减不增的账户，上述的框架是可以包含解决的，也没必要特殊优化
资金永远充足的账户，在流程的第2步，可以落库后返回成功
如果H->A的划账要求两个账户事务一致性，那么就需要对我们流程第2步中的表做修改了，将H->A整个落库，后批量处理
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/68068.html
摘要：通常伪同步方案采用三件套日志校验位广播消息来完成一次完整的请求流程图一般如下请求阶段同步请求调用，核心要素追加写入日志，变更校验位，完成同步调用此处追加写保证了快速写入，校验位来保证数据的最终写入成功。 话接上回，上篇阐述了什么是热点账户，基本财务账户如何设计，幂等健和链式设计！本篇将针对热点账户在实践中引发的问题，梳理和拆解业务流，分析问题点，提出七种常用解决方案。 一、性能问题初现...
摘要：启用严格传输安全协议来进一步减少遭受攻击的可能。这些措施将使拦截流量变得极其困难。这种情况在酒吧宾馆火车和其他公共场所非常普遍。部分使用也将面临被动拦截的风险。 许多Web开发者都知道SSL，但常见的情况是SSL没有完整地部署或者没有部署在它应该部署的地方。这篇关于何时及如何部署SSL的简要指南，将帮助你避免大多数常见错误。 要点 如果你有任何机密信息，或者你要进行用户登陆，哪怕...
阅读 3915·2021-11-24 09:38
阅读 1401·2021-11-19 09:40
阅读 2756·2021-11-18 10:02
阅读 3675·2021-11-09 09:46
阅读 1732·2021-09-22 15:27
阅读 3093·2019-08-29 15:24
阅读 946·2019-08-29 12:40
阅读 1668·2019-08-28 18:24
