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

不念不忘少年蓝@ 2022-03-07 04:03 755阅读 0赞

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

## 一、热点账户问题 ##

### 1.1 什么是热点账户 ###

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

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

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

### 1.2 热点账户问题 ###

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

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

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

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

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

### 2.1 业务场景分析 ###

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

便于理解，来张传统的账本，看下什么是流水，什么是余额  
[![finance\_hot\_account\_1][finance_hot_account_1]][finance_hot_account_1_finance_hot_account_1]

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

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

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

### 2.2 技术层面拆解 ###

#### 2.2.1 基本表方案 ####

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

账户基本信息：账户信息表
    子账户余额信息：账户余额表
    账户流水信息：账户流水表
    
    三张表基本关系
    账户信息表 1:N 账户余额表
    账户余额表 1:N 账户流水表
    
    ## 具体账户和用户的关联可以参考三户模型

#### 2.2.2 表字段设计 ####

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

1.  防重：幂等健设计
2.  防改：链式设计
3.  防错：销账设计

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

[![finance\_hot\_account\_2][finance_hot_account_1]][finance_hot_account_2_finance_hot_account_1]

#### 2.2.3 表字段解读 ####

##### 2.2.3.1 幂等健设计 #####

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

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

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

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

##### 2.2.3.2 链式设计 #####

链式设计是保证操作精准不可篡改的非常有效手段！  
通过资金的**before info，after info，版本号**三个要素来保证一条资金记录一旦插入成功，前后置信息固化！

链式设计的情况下单条修改是不可能的，多条修改需要在保证条目不变的情况下重组资金，但是，整体资金不可变

解决多条修改的一般方案：分布式存储，选举来判定最终正确的链，来确认是否某条链发生了过程修改，这种设计有一个很时髦的名字：**区块链**！而每条流水的核心信息加密后也有了一个更加时髦的名字：**比特币**！

##### 2.2.3.3 销账设计 #####

销账设计在账户系统中是一直存在的，现实财务系统可以**红销蓝抵**，线上财务系统加了链式之后，基本上就只能采用**蓝抵**  
通过增加rollback字段，并且严格限制0|1，保证一条账务流水只能被抵销一次！

具体三张表详细字段，需要脱敏，就不贴了，参考上面，其中索引，字段大小，联合索引等设计根据自身业务场景兼容即可！

## 小结：欲知后事如何，且听下回分解 ##

本部分简单介绍了什么是热点账户和账户的基本设计，涵盖幂等健设计，链式设计等等！  
下一篇重点分析下热点账户在链式设计下的问题，产生原因和八种基本解决方案

【转载请注明：[热点账户问题和常用解决方案【上】][Link 1] | [公众号：靠谱崔小拽][Link 2] |】

[finance_hot_account_1]: https://cdn.segmentfault.com/v-5c8b4d77/global/img/squares.svg
[finance_hot_account_1_finance_hot_account_1]: /images/20220307/640ba6f84c8a4fe987ac944d7d8341f2.png
[finance_hot_account_2_finance_hot_account_1]: /images/20220307/657fc0de423b4abda2259d6826c9d30e.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzIwNTA4NjAxMw==&mid=2648971111&idx=1&sn=526a1b5882f874e8cf5fc2ac41812e89&chksm=8f26fb35b8517223d7bc9eb67a6bced58efbdaa45ae3ec0589f0305e04a3378b15e7f56ada5f&token=775794538&lang=zh_CN#rd
[Link 2]: http://cuihuan.net