網際網路金融系統的核心是支付結算，而支付結算的基礎又是賬戶系統。金融賬戶系統的特點是併發量大、響應快、交易金額大，熱點賬戶問題突出。乙個合格的賬戶系統既要解決上述問題，又必須絕對保證資金安全。作為宜信這家網際網路金融公司的支付結算中心，其賬戶系統也必須具備上述特徵。
宜信支付結算賬戶體系是客戶、使用者、賬戶三層結構，證件號和證件型別唯一確定乙個客戶，客戶號和機構號確定乙個使用者，乙個使用者下可開多個不同型別的賬戶。如圖：
賬戶下掛在最底層的會計科目下，會計科目決定了賬戶的含義及餘額變動方向。會計科目的一些屬性如下：
宜信支付結算賬戶系統採用科目樹的概念，每個機構都會繫結乙個科目樹。科目樹的根節點是一級科目，底層的科目下掛賬戶，結構如下：
宜信支付結算賬戶系統採用公司自研的分布式微服務框架，對外提供http json介面，內部各服務間採用redis實現的訊息佇列通訊。
宜信支付結算賬戶系統分為接入模組、記賬子系統、開戶子系統、非同步記賬模組、查詢子系統、定時任務子系統、日終子系統、非同步日誌模組，下圖是賬務系統功能模組圖：
查詢子系統：提供賬戶、記賬的一些查詢功能。
非同步記賬模組：提供非同步記錄賬戶流水的功能。
定時任務子系統：處理失敗重試、熱點賬戶等的定時任務。
日終子系統：提供日切以及日終跑批的功能。
2.1.1 記賬處理
記賬處理是賬戶系統的核心功能，該功能對效能的要求比較高，高併發下熱點賬戶問題比較突出，資金的正確性也必須保證，並且根據業務不同，記賬的分錄也是五花八門，宜信支付結算賬戶系統如何應對這些問題，這裡重點介紹下：
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，解決了死鎖問題。
宜信支付結算賬戶系統資料庫採用mysql，快取採用redis。
賬戶系統各個服務部署在同一機房，其中記賬子系統和非同步記賬模組部署在4個不同的物理機上，其他子系統和模組部署在2個不同物理機上。最前端採用nginx實現負載均衡。
支付結算系統如何應對高併發 熱點賬戶等問題
網際網路金融系統的核心是支付結算，而支付結算的基礎又是賬戶系統。金融賬戶系統的特點是併發量大 響應快 交易金額大，熱點賬戶問題突出。乙個合格的賬戶系統既要解決上述問題，又必須絕對保證資金安全。作為宜信這家網際網路金融公司的支付結算中心，其賬戶系統也必須具備上述特徵。宜信支付結算賬戶體系是客戶 使用者...
如何應對高併發？
參照乙個大佬的文章，我也寫一篇高併發的文章，一下這門高階的現象，以及一些解決措施。乙個關於高併發的問題 那位大佬說 如果真的幹過高併發系統的人，面試官是絕對不會對你提出這個問題的，否則就是他太不明智了。至於為嘛這樣說呢，因為如果設計乙個高併發系統，這句話就是錯誤的了，因為在脫離了業務的系統架構中都是...
實際專案中如何應對高併發等場景
高併發相關常用的一些指標有響應時間 response time 吞吐量 throughput 每秒查詢率qps query per second 併發使用者數等。吞吐量 單位時間內處理的請求數量。qps 每秒響應請求數。在網際網路領域，這個指標和吞吐量區分的沒有這麼明顯。1.採用前後端分離的模式，前...