熱點賬戶問題和常用解決方案 上

熱點賬戶問題由來已久，一直是賬戶系統設計中的乙個難點和瓶頸！

小拽將通過上中下三篇文章，分別介紹下熱點賬戶的產生，解決方案和延伸應用！

本篇主要介紹下什麼是熱點賬戶？通用財務賬戶系統如何設計？以及其中的冪等健和鏈式設計等

熱點賬戶一旦產生便伴隨著高併發，流量分布不均勻，高一致性等等問題。在實際場景中是熱點賬戶必然存在，常常成為使用者系統的瓶頸！

同時，熱點賬戶問題也是高併發問題的延展，由於熱點的不規則性，如何在高併發情況下，削峰填谷，彈性抗壓也是很有挑戰性的乙個方向！

熱點賬戶除了是賬戶體系的乙個通用問題，在高併發，流量分布不均勻，異常峰值等其他問題上，也有一定的通用性。例如微博熱點問題，支付寶雙11彈性變更，高頻搶購問題等等。期望通過學習熱點賬戶的八種解決方案，能夠舉一反三，應用於不同場景！

在解決熱點賬戶問題之前，先來看下如何設計乙個簡單的財務賬戶，來保障資金記賬的安全！

從業務上看，財務賬戶需要準確記錄使用者的資金變動過程和結果！因此設計乙個簡單財務賬戶至少要能包括兩個部分：賬戶餘額和賬戶流水

便於理解，來張傳統的賬本，看下什麼是流水，什麼是餘額

賬戶流水：賬戶流水也就是通俗意義上的帳或者賬單！針對某個賬戶，每一筆資金的變更都需要記錄下來，並且保障準確，不可更改！同時如圖所示，流水中需要包含單據產生的原因，**，變更額等等

賬戶餘額：賬戶餘額記錄使用者某個場景賬戶的當前資金額度！在複雜的業務場景中往往需要拆分出不同的子賬戶和賬戶模型。例如，未結算子賬戶，可提現子賬戶，凍結子賬戶，授信賬戶等等。

從業務場景上乙個賬戶系統核心需要準確記錄餘額和流水，同時，必須保障記錄的準確，完備，不可變更!

2.2.1 基本表方案

通過業務場景初步分析，基本的賬戶系統，需要三張基本表

賬戶基本資訊：賬戶資訊表

子賬戶餘額資訊：賬戶餘額表
賬戶流水資訊：賬戶流水表
三張表基本關係
賬戶資訊表 1:n 賬戶餘額表
賬戶餘額表 1:n 賬戶流水表
## 具體賬戶和使用者的關聯可以參考三戶模型

從技術層面看，設計具體表細節關鍵要解決以下幾個問題

防重：冪等健設計

防改：鏈式設計

防錯：銷賬設計

先上結果，簡單的，能夠滿足上述需求的設計可以參考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。因此，冪等一定要通過寫庫保證或者最底層保證

2.2.3.2 鏈式設計

鏈式設計是保證操作精準不可篡改的非常有效手段！

通過資金的before info，after info，版本號三個要素來保證一條資金記錄一旦插入成功，前後置資訊固化！

鏈式設計的情況下單條修改是不可能的，多條修改需要在保證條目不變的情況下重組資金，但是，整體資金不可變

解決多條修改的一般方案：分布式儲存，選舉來判定最終正確的鏈，來確認是否某條鏈發生了過程修改，這種設計有乙個很時髦的名字：區塊鏈！而每條流水的核心資訊加密後也有了乙個更加時髦的名字：位元幣！

2.2.3.3 銷賬設計

銷賬設計在賬戶系統中是一直存在的，現實財務系統可以紅銷藍抵，線上財務系統加了鏈式之後，基本上就只能採用藍抵

通過增加rollback欄位，並且嚴格限制0|1，保證一條賬務流水只能被抵銷一次！

具體三張表詳細字段，需要脫敏，就不貼了，參考上面，其中索引，字段大小，聯合索引等設計根據自身業務場景相容即可！

熱點賬戶問題和常用解決方案 上

熱點賬戶問題由來已久，一直是賬戶系統設計中的乙個難點和瓶頸！小拽將通過上中下三篇文章，分別介紹下熱點賬戶的產生，解決方案和延伸應用！本篇主要介紹下什麼是熱點賬戶？通用財務賬戶系統如何設計？以及其中的冪等健和鏈式設計等 熱點賬戶 顧名思義，熱點賬戶就是會被高頻操作的賬戶！相較於普通的賬戶，熱點賬戶數量...

熱點賬戶解決方案

在某一瞬間，單個賬戶集中的發生資金變動，若不加控制，其賬戶餘額會因發生髒讀 覆蓋更新等情況而錯誤記錄。如果簡單的以悲觀鎖 樂觀鎖的方式限制，雖然不會發生資料錯誤，但會造成服務不可用 該賬戶的更新請求全部失敗 而請求重試 再次網路通訊的開銷並不能忽略不計。在賬戶系統的實際業務中，發生 熱點賬戶 情況的...

快取熱點問題解決方案

快取熱點問題解決方案 問題描述 同一時間訪問同乙個快取key的請求數量過高，導致某台特定的redis伺服器壓力過大，而其他的redis伺服器沒有分擔到壓力。舉例說明 店鋪活動查詢的時候快取key為店鋪編碼，value為店鋪能夠參加的活動編碼資訊，某個時候店鋪搞活動瞬時redis訪問命令數飆公升，熱點...