热点账户问题和常用解决方案【上】

最新推荐文章于 2024-07-01 00:03:49 发布

weixin_33738555

最新推荐文章于 2024-07-01 00:03:49 发布

阅读量840

点赞数

文章标签：区块链

原文链接：https://segmentfault.com/a/1190000018144862

版权

热点账户问题由来已久，一直是账户系统设计中的一个难点和瓶颈！
小拽将通过上中下三篇文章，分别介绍下热点账户的产生，解决方案和延伸应用！
本篇主要介绍下什么是热点账户？通用财务账户系统如何设计？以及其中的幂等健和链式设计等

一、热点账户问题

1.1 什么是热点账户

热点账户：顾名思义，热点账户就是会被高频操作的账户！相较于普通的账户，热点账户数量不多，但操作频率极高！

热点账户从产生来源可分两大类：

富二代型：从产生之初就是热点账户，非常稳定。例如财务中公司的账户，每一笔资金操作都要经过公司出金账户，自然而然操作就会灰常频繁，此类账户还包括：大V账户，大KA账户等等，此类账户所引起的问题是本文重点要解决的
暴发户型：本身是普通账户，由于热点问题变为热点帐户。例如微博出轨女猪脚账户，诺贝尔奖获得者等等，由于热点事件造成的短时间内访问暴增！此类热点账户防不胜防，超出本文的攻击范围，暂不讨论。

1.2 热点账户问题

热点账户一旦产生便伴随着高并发，流量分布不均匀，高一致性等等问题。在实际场景中是热点账户必然存在，常常成为用户系统的瓶颈！
同时，热点账户问题也是高并发问题的延展，由于热点的不规则性，如何在高并发情况下，削峰填谷，弹性抗压也是很有挑战性的一个方向！

1.3 热点账户通用解决方案的价值

热点账户除了是账户体系的一个通用问题，在高并发，流量分布不均匀，异常峰值等其他问题上，也有一定的通用性。例如微博热点问题，支付宝双11弹性变更，高频抢购问题等等。期望通过学习热点账户的八种解决方案，能够举一反三，应用于不同场景！

二、如何设计一个财务账户

在解决热点账户问题之前，先来看下如何设计一个简单的财务账户，来保障资金记账的安全！

2.1 业务场景分析

从业务上看，财务账户需要准确记录用户的资金变动过程和结果！因此设计一个简单财务账户至少要能包括两个部分：账户余额和账户流水

便于理解，来张传统的账本，看下什么是流水，什么是余额

账户流水：账户流水也就是通俗意义上的帐或者账单！针对某个账户，每一笔资金的变更都需要记录下来，并且保障准确，不可更改！同时如图所示，流水中需要包含单据产生的原因，来源，变更额等等

账户余额：账户余额记录用户某个场景账户的当前资金额度！在复杂的业务场景中往往需要拆分出不同的子账户和账户模型。例如，未结算子账户，可提现子账户，冻结子账户，授信账户等等。

从业务场景上一个账户系统核心需要准确记录余额和流水，同时，必须保障记录的准确，完备，不可变更!

2.2 技术层面拆解

2.2.1 基本表方案

通过业务场景初步分析，基本的账户系统，需要三张基本表

账户基本信息：账户信息表
子账户余额信息：账户余额表
账户流水信息：账户流水表

三张表基本关系
账户信息表 1:N 账户余额表
账户余额表 1:N 账户流水表

## 具体账户和用户的关联可以参考三户模型

2.2.2 表字段设计

从技术层面看，设计具体表细节关键要解决以下几个问题

防重：幂等健设计
防改：链式设计
防错：销账设计

先上结果，简单的，能够满足上述需求的设计可以参考innodb mvcc，核心表字段如下

2.2.3 表字段解读

2.2.3.1 幂等健设计

通过三个属性资金凭证号+版本号+rollback三个字段作为uniq key来保证幂等！

资金凭证号：来自业务方，业务方发起资金操作的唯一财务凭证，必须可追溯上游凭证和对账！
版本号：每次获取DB最新流水n后，版本号n+1插入，保障在并发情况下，每个子账户只有唯一一个版本号：n+1条记录能够插入成功！
rollback：回滚标识，保证每条记录能且只能销账一次！

对于幂等建设计此处有三条小技巧

上游产生：每一个幂等健如果可能的话，尽可能的上游产生，这样可以最大限度的避免自产生幂等健的重复问题。如果确实不能上游产生，例如订单ID，提现单ID，那么也尽可能的分阶段产生，例如提现时，先生成提现单ID，真正提现操作的时候，一定是带着提现单ID和信息来的，防止重复造成资损！
业务关联：幂等健的产生可以用ice生成，但是，最好能够和业务关联，因为通过业务强关联的幂等健可以无限回溯来容灾！比如，a用户的b订单进行c操作，uniq_key = a_b_c的话，也就是在任何情况下，无论多少次回溯，重试也只会有一个唯一的a_b_c，而ice生成则可能造成自回溯的时候插入多条！
写库保证：这条原则是高一致高并发的基本原则！因为读取a，校验a，然后插入，必然会存在读写之间a变了，或者主从延时a已经变了，读了历史a。因此，幂等一定要通过写库保证或者最底层保证