支付結算系統如何應對高并發、熱點賬戶等問題

互聯網金融系統的核心是支付結算，而支付結算的基礎又是賬戶系統。金融賬戶系統的特點是并發量大、響應快、交易金額大，熱點賬戶問題突出。一個合格的賬戶系統既要解決上述問題，又必須絕對保證資金安全。作為宜信這家互聯網金融公司的支付結算中心，其賬戶系統也必須具備上述特征。

一、賬戶體系

1.1 賬戶結構

宜信支付結算賬戶體系是客戶、用戶、賬戶三層結構，證件號和證件類型唯一確定一個客戶，客戶號和機構號確定一個用戶，一個用戶下可開多個不同類型的賬戶。如圖：

1.2 賬戶屬性

賬戶系統的基礎是賬戶，所有的操作都圍繞著賬戶進行，賬戶包含以下一些屬性：

• 會計科目：每個賬戶金額的變動要體現一些會計的屬性，以便會計核算。
• 賬戶類別：分為個人賬戶、企業賬戶、平臺類賬戶。
• 賬戶明細：賬戶的明細是反映賬戶余額變動的每筆詳情，采用復式記賬法，包含本對方賬號、賬戶等信息、摘要、借方的發生額及余額等信息。
• 賬戶余額：記錄賬戶的實時余額。

1.3 會計科目

賬戶下掛在最底層的會計科目下，會計科目決定了賬戶的含義及余額變動方向。會計科目的一些屬性如下：

• 科目類別：資產類、負債類、所有者權益、成本類、損益類等。
• 科目級別：會計科目的級別，一級科目、二級科目、三級科目等。下級科目歸屬上級科目。
• 余額方向：標示余額是在借方還是貸方。
• 科目的期末余額：每日日切后會匯總底層科目所有下掛賬戶在上一會計日的余額總和，上級科目匯總下級科目的余額總和。

1.4 科目樹

宜信支付結算賬戶系統采用科目樹的概念，每個機構都會綁定一個科目樹。科目樹的根節點是一級科目，底層的科目下掛賬戶，結構如下：

二、賬戶系統架構

宜信支付結算賬戶系統采用公司自研的分布式微服務框架，對外提供http json接口，內部各服務間采用redis實現的消息隊列通訊。

2.1 賬戶系統功能架構

宜信支付結算賬戶系統分為接入模塊、記賬子系統、開戶子系統、異步記賬模塊、查詢子系統、定時任務子系統、日終子系統、異步日志模塊，下圖是賬務系統功能模塊圖：

• 接入模塊：提供報文解析、驗簽、參數校驗、權限認證等公共服務，是賬戶系統的統一入口。
• 異步日志模塊：異步記錄業務系統請求報文。
• 記賬子系統：賬戶系統的核心模塊，處理業務系統的記賬請求。
• 開戶子系統：處理業務系統的開戶請求。
  • 首次開立賬戶：為個人或企業開立客戶、用戶及提前配置的默認開通的賬戶。
  • 指定開立賬戶：個人或企業在首次開立賬戶后，可按科目號指定開立賬戶。
• 查詢子系統：提供賬戶、記賬的一些查詢功能。
• 異步記賬模塊：提供異步記錄賬戶流水的功能。
• 定時任務子系統：處理失敗重試、熱點賬戶等的定時任務。
• 日終子系統：提供日切以及日終跑批的功能。

2.1.1 記賬處理

記賬處理是賬戶系統的核心功能，該功能對性能的要求比較高，高并發下熱點賬戶問題比較突出，資金的正確性也必須保證，并且根據業務不同，記賬的分錄也是五花八門，宜信支付結算賬戶系統如何應對這些問題，這里重點介紹下：

• 賬戶系統記賬采用記賬服務的概念，每個記賬服務就是一個記賬分錄的模板，業務系統按照這個模板傳入記賬金額、賬戶號或者用戶號等信息。
• 賬戶系統采用redis分布式鎖，防止業務系統重復提交請求。設置記賬訂單防重表，按照請求單號和機構號對記賬請求做冪等性校驗。
• 采用復式記賬法，按照會計規則按照借貸記錄流水，有借必有貸。
• 記賬處理時，更新賬戶余額后同步返回結果給業務系統，異步的處理記賬流水。同時設置補償機制，定時重試記賬流水處理失敗的訂單，重試三次失敗后報警人工介入。
• 記賬規則處理，每個記賬服務可以綁定一些記賬規則，賬戶系統根據記賬服務遍歷其綁定的規則，順序處理。

2.1.2 熱點賬戶問題

熱點賬戶問題是賬戶系統的痛點，也困擾了我們很久，這里著重說下。

-- 充值時的記賬分錄是:

借方：三方支付待清算賬戶（+）

貸方：個人余額賬戶（+）

當大量用戶充值時，三方支付的待清算賬戶就是熱點賬戶，頻繁的增加余額。

-- 提現時的記賬分錄是:

借方：個人余額賬戶（-）

貸方：三方支付資產賬戶（-）

當大量用戶提現時，三方支付的資產賬戶就是熱點賬戶，頻繁的減少余額。

--業務收服務費的記賬分錄是:

借方：個人賬戶（-）

貸方：商戶服務費賬戶（+）

當大量向用戶收取服務費時，商戶服務費賬戶就是熱點賬戶，會頻繁增加余額。

--業務服務費付款的記賬分錄是:

借方：商戶服務費賬戶（-）

貸方：個人賬戶（+）

當大量用服務費余額向用戶付款時，商戶服務費賬戶就是熱點賬戶，會頻繁減少余額。

記賬時，所有涉及的賬戶余額都要做update更新，高并發情況下，當出現上述類型的熱點賬戶時，由于數據庫的行級鎖，對同一賬戶的更新余額操作由并行變成串行，單個請求的響應時間變長，從而拖垮整個記賬服務。

宜信支付結算賬戶系統針對上述問題做了如下處理：

我們把熱點賬戶按照金額變動方向分為加頻賬戶（余額增加頻繁）、減頻賬戶（余額扣減頻繁）、雙頻賬戶（余額增加扣減均頻繁）。

• 加頻賬戶處理

準實時更新余額。先將金額變動插入臨時表中，由定時任務按照一定頻率匯總發生額，并更新賬戶余額，而后刪除臨時記錄。當加頻賬戶減錢余額不足時，主動去匯總發生額。這里需要考慮主動匯總發生額和定時任務處理的并發情況，我們在該定時任務執行時設置redis鎖，防止并發，主動匯總時會去判斷這個redis鎖是否存在，如存在證明定時任務正在執行，無需主動匯總，可能是真的余額不足。主動匯總同樣會設置redis鎖，定時任務同樣會判斷。

• 減頻賬戶處理

將減頻賬戶拆分多個子賬戶，減頻子賬戶設置金額報警，如果某個減頻子賬戶余額不足觸發報警，會對該子賬戶做資金歸集，將其他子賬戶余額歸集到該子賬戶（每個子賬戶設置可歸集金額限制）。如在交易過程中發現該子賬戶余額不足，轉向使用其他子賬戶記賬。由于拆分子賬戶，余額查詢時需要匯總各個子賬戶余額返回；記錄主賬戶流水需要記賬后余額，這里需要異步計算匯總。當減頻賬戶加錢時，需要平均分配入賬到不通的子賬戶。

• 雙頻賬戶處理

將雙頻賬戶拆分多個子賬戶。加錢時，準實時更新余額，先將子賬戶金額變動插入臨時表中，由定時任務按一定頻率匯總發生額，將匯總的發生額更新進對應的子賬戶，并刪除金額變動記錄；減錢按照之前減頻賬戶的邏輯執行。

2.1.3 記賬死鎖問題

高并發情況下，當多個賬戶之前互相轉賬時，可能會出現死鎖問題。

例如：A余額賬戶 —> B余額賬戶（線程1） 和 B余額賬戶—>A余額賬戶（線程2） 兩個轉賬請求并發，賬戶系統對每個轉賬請求都會更新A、B余額，這兩個更新需要在一個事務里，正常流程線程1先更新A，再更新B，線程2先更新B，再更新A，線程1更新完A后會等待B的鎖，不提交事務，線程2更新完B后會等待A的鎖，不提交事務，這樣兩個線程互相等待鎖，造成死鎖。

宜信支付結算賬戶系統針對這種情況提出了解決辦法，對賬戶號進行排序后再更新余額，這樣每個線程都是先更新A再更新B，解決了死鎖問題。

2.2 賬戶系統存儲層架構

宜信支付結算賬戶系統數據庫采用Mysql，緩存采用redis。

• Mysql數據庫采用主從架構，一主二從，主庫向從庫同步數據。針對一些數據量大的表進行分表，比較有代表性的是賬戶流水表，既要按賬戶維度查詢，又要按時間維度匯總，所以針對這個特點，冗余了一張表，一張按照賬戶分表，一張按照日期分表。

• Redis采取集群架構，集群中每個點主備的形式。

2.3 賬戶系統的網絡層架構

賬戶系統各個服務部署在同一機房，其中記賬子系統和異步記賬模塊部署在4個不同的物理機上，其他子系統和模塊部署在2個不同物理機上。最前端采用nginx實現負載均衡。

作者：李銳 程留允