久久精品人人爽,华人av在线,亚洲性视频网站,欧美专区一二三

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

155次閱讀
沒有評論

共計 3094 個字符,預計需要花費 8 分鐘才能閱讀完成。

自動寫代碼機器人,免費開通

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

一、賬戶體系
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 實現負載均衡。

作者:李銳 程留允

向 AI 問一下細節

丸趣 TV 網 – 提供最優質的資源集合!

正文完
 
丸趣
版權聲明:本站原創文章,由 丸趣 2023-12-18發表,共計3094字。
轉載說明:除特殊說明外本站除技術相關以外文章皆由網絡搜集發布,轉載請注明出處。
評論(沒有評論)
主站蜘蛛池模板: 裕民县| 鸡东县| 科技| 高雄市| 台湾省| 罗田县| 清涧县| 霍州市| 昂仁县| 乌什县| 蕲春县| 嘉定区| 西畴县| 罗定市| 双城市| 广元市| 卢湾区| 来宾市| 石河子市| 沂源县| 瓮安县| 保定市| 浦江县| 巴塘县| 夏河县| 焦作市| 新密市| 平舆县| 连云港市| 罗田县| 商河县| 岗巴县| 阳山县| 宜章县| 民权县| 木兰县| 玉林市| 平定县| 通江县| 巴林左旗| 洛川县|