摘要：通常偽同步方案采用三件套日志校驗位廣播消息來完成一次完整的請求流程圖一般如下請求階段同步請求調用，核心要素追加寫入日志，變更校驗位，完成同步調用此處追加寫保證了快速寫入，校驗位來保證數據的最終寫入成功。

話接上回，上篇闡述了什么是熱點賬戶，基本財務賬戶如何設計，冪等健和鏈式設計！本篇將針對熱點賬戶在實踐中引發的問題，梳理和拆解業務流，分析問題點，提出七種常用解決方案。

上線初期數據量較小，運行正常！
一次大促后，賬戶流水的總數目接近億級別，初現性能問題：系統整體的qps也就10+，但熱點賬戶寫入失敗率偏高，并且隨數據量增加失敗率逐步升高；整個賬戶系統全靠上游有redo標識位不斷重試，才能保證最終寫入成功!

哈哈，作為一名擁有三年工作經驗的老碼農，面對問題，要做的第一件事，就是靜，抽根煙靜靜，準備開搞！

拿到問題，抽根煙靜一下之后，分析問題需要三步：梳理數據流，拆解過程，定位問題點。先對財務賬戶更新的數據流進行拆解

鏈式鎖后的基本賬戶操作過程，分為如下五階段

請求階段：賬戶操作請求。

查詢階段：查詢當前賬戶信息。主要獲取當前鏈，資金數據等！

計算階段：對鏈和操作的資金進行計算，判定資金操作合規，同時保證冪等和并發！

寫入階段：事務同步寫入流水和余額

響應階段：告知上游回調

梳理數據流后，接下來分析每個階段可能引發的問題。按照優先級，先分析業務問題區域（讀取階段，計算階段，寫入階段），通常問題會出現在業務階段；之后，再分析框架問題區域（請求階段和回調階段），該區域出現問題的情況偏小，但是一旦出現問題，就是比較有意思^_^！

讀取階段，計算階段，寫入階段三個階段是具體的業務操作，從并發和耗時兩個角度來分析下可能的問題點

耗時分為三塊

查詢耗時：RDS擁有億級別數據量，查詢未中primary，但命中索引，業務數據體并未完全在索引中，因此訪問數據走index match；數據主鍵聚簇，唯一健索引查詢獲取數據，page極難命中cache，也不會命中磁盤電梯算法優化！結合實際情況，查詢耗時在10-100ms級別

寫入耗時：insert 包含了自增，理論上在數據落盤是追加寫，即使uniq_key去創建索引的情況下，耗時在ms級

過程耗時：長連接情況下，init conn時間基本可以忽略，但是讀寫兩次往返數據庫的鏈路時間還是需要考慮，整體預估在1-2ms之間

從整體上看，預估該階段的耗時在10-100+ms，從實際失敗率來看也基本一致！

天級QPS：當時分析天級幾十萬單，天級QPS不到10，不高！

瞬間QPS：每個訂單拆解到資金流后，會同時操作多次熱點賬戶，瞬間qps相對很高，理論qps就可能達到語言上限，由于上游鏈路限流1024，按照10級別操作拆分，理論上滿池QPS在萬級別?？紤]實際單量，瞬間QPS=單量(10)*拆解量(10)，實際的滿額預估QPS可能到100+ ！

按照上面分析，在瞬時QPS達到10+的情況下，熱點賬戶整體延時在10-100+ms，由于DB在寫入uniq_key保證鏈點唯一，所以出現并發寫入失敗也在情理之中；并且隨著數據量的提升，讀取延時增加，寫入失敗率會繼續增加。

請求階段做為入口，一般也分為三個小階段

webserver接收請求

框架加載和路由

基礎校驗

請求階段核心耗時一般存在于框架加載和路由，高并發場景webserver和upstream之間的調用也是一個可能出問題點！當時財務系統，采用歡總封裝的go-thrift，并且其他模塊并未出現請求階段問題，所以并未對這個階段的latency和并發做一個衡量，重點分析了業務模塊！

通過上面分析，目前問題的痛點是并發讀取熱點賬戶數據高延時引發寫入失敗，提升讀性能成為了關鍵

讀性能提升有兩個基本思路：讀的時效快和讀的次數少

針對上面兩個基本思路，結合財務賬戶情況提出了五種提升讀性能的解決方案

【讀快】持久化last record：不從全量數據里面讀，抽離子賬戶的最新信息，持久化到多帶帶的表中或者內存中，降低整體數據量，提升了讀性能。缺點是要保證持久化信息的準確性，引入事務寫。

【讀快】縱向切分-時間分庫分表：按照時間進行縱向切分，降低查詢范圍內的數據量，提升讀性能。缺點是跨時間讀不友好，開發量也不小

【讀快】縱向切分-歸檔：歷史數據歸檔是實現相對簡單，跨時間讀也比較友好，隨著數據量的提升，也是必須要做，之后會詳細介紹歸檔方案和選型。

【讀快】橫向切分-業務分庫分表：按照賬戶類型或者城市分庫分表，可以優化讀寫數據量，同時，跨表讀負擔也會較小。但對于熱點賬戶或者熱點城市，依然聚簇，效果不是很明顯。同時，再次對熱點賬戶進行橫向分庫分表也是極度不推薦，引入的極高的讀寫成本均。

【讀少】階段快照：一定量或者一定時間內的數據，持久化一次。優勢是極大的降低讀寫次數；缺點是需要復雜的邏輯來保證undo操作和數據一致性！

五種解決方案各有千秋，作為一個初期的財務系統推薦采用持久化last record和數據歸檔來保證寫入讀性能和整體讀的數據量。如果系統發展到了中期，推薦按照時間分庫分表。如果發展到了雙11或者春晚某些極端場景，犧牲掉部分準確性，采用階段快照也是可以的。

存在計算階段造成的最大影響也就是引起了兩次數據傳輸，通常是不可避免的，但是如果真的是要進行提升有一種方案通用方案

DB計算：通過存儲計算，轉嫁計算成本給DB，減少一次鏈路請求。但不太推薦，復雜的sql往往有坑，insert computer from select 還會造成大面積的數據隔離，很容易引起死鎖。

請求階段一般有三種形式：同步調用，異步調用和偽同步調用！
前兩種調用非常常見：同步爆池的情況，一般采用限流來降壓，采用漏桶，令牌桶等等策略；異步調用通常采用消息隊列來削峰填谷；這里重點闡述對于支付和財務系統在請求階段經常采用的偽同步的方式

偽同步流量較早出現在innodb，leveldb等存儲引擎為了利用追加寫提升寫入性能，采用類WAL日志來持久化數據。通常偽同步方案采用三件套：WAL日志+校驗位+廣播消息來完成一次完整的請求！流程圖一般如下

請求階段：同步請求調用，核心要素追加寫入wal日志，變更校驗位，完成同步調用！此處追加寫保證了快速寫入，校驗位來保證數據的最終寫入成功。圖中1，2

異步階段：通過讀取wal日志的核心數據，進行復雜事務處理，如果成功進入下一階段；如果失敗，沒問題，通過外部trigger來觸發redo操作！如果多次redo依然失敗，那么通過undo來回滾數據。

回調階段：如果成功，更改校驗位，同時發布成功廣播消息，關注結果和時效性的模塊，可以獲取最終成功的標識！如果undo回滾數據，則發布失敗廣播消息，告知結果失?。?/p>

在偽同步的模式下指標衡量：

QPS：偽同步模式，采用WAL核心要素追加寫，所以寫性能可以極大提升，進而滿額QPS相對直接同步調用也大量提升

時效性：偽同步并非完全同步，所以結果需要監聽回調。對于結果強一致的請求，必須監聽回調，確保一致，時效性降低；對于弱一致可以認為同步回調即成功，時效性提升。

失敗率：操作知識核心要素追加寫入，真正的操作通過異步保證，整體成功率提升！

對于資金處理過程，大量采用偽同步的請求方式來保證快速寫入和最終一致性。

總的來說，歸結了七種優化方式（哈哈，上篇寫的八種優化，當時總結的，現在愣是想不到還有啥了^_^）。其中請求和回調的偽同步方式，是在架構層面優化，這個在多數的財務系統和財務系統的內部數據流中都會用到；而讀寫和計算階段的優化，可以跟進實際業務情況進行選型處理。

面對各種優化方案，需要結合實際情況做出取舍，有的是長期方案，有的是快速方案，但一定需要想清楚了再開搞，過程中有一個對小拽之后影響很大的事故，引以為戒。

翻車過程：當時覺的讀->計算->寫這個過程，兩次讀DB操作，下沉計算過程到DB后，通過DB計算，可以減少一次數據庫請求。于是合并了一個大SQL，也就是所謂的insert ( field computer from select)，覺的寫了個狂賺酷炫吊炸天的SQL，一上線，庫鎖死了！幸好有前置的redo flag，全量redo數據恢復，要不然估計直接祭天了！

對于這個復雜大SQL事故，小拽總結了三個方面

莫炫技：沒啥好說的，解決問題的成就感要遠大于炫技！
簡單設計：簡單的設計通常意味著可依賴；復雜的設計要盡可能的拆解，想清楚，隊友都理解不了的設計，那就別上線了，可能真的需要再思考拆解下
尊重線上：核心服務基本上線流程一定要遵守，測試，監控和回滾方案缺一不可

本篇主要針對熱點賬戶問題提出了七種常用的解決方案，下篇將繼續引申探索下，各種解決方案在不規則高并發場景，例如雙十一，微博熱點事件中如何套用

預知后事如何，下回再聊！

【轉載請注明：熱點賬戶問題和常用解決方案【中】 | 靠譜崔小拽 】