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

話接上回，上篇闡述了什么是熱點(diǎn)賬戶，基本財(cái)務(wù)賬戶如何設(shè)計(jì)，冪等健和鏈?zhǔn)皆O(shè)計(jì)！本篇將針對(duì)熱點(diǎn)賬戶在實(shí)踐中引發(fā)的問題，梳理和拆解業(yè)務(wù)流，分析問題點(diǎn)，提出七種常用解決方案。

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

哈哈，作為一名擁有三年工作經(jīng)驗(yàn)的老碼農(nóng)，面對(duì)問題，要做的第一件事，就是靜，抽根煙靜靜，準(zhǔn)備開搞！

拿到問題，抽根煙靜一下之后，分析問題需要三步：梳理數(shù)據(jù)流，拆解過程，定位問題點(diǎn)。先對(duì)財(cái)務(wù)賬戶更新的數(shù)據(jù)流進(jìn)行拆解

鏈?zhǔn)芥i后的基本賬戶操作過程，分為如下五階段

請(qǐng)求階段：賬戶操作請(qǐng)求。

查詢階段：查詢當(dāng)前賬戶信息。主要獲取當(dāng)前鏈，資金數(shù)據(jù)等！

計(jì)算階段：對(duì)鏈和操作的資金進(jìn)行計(jì)算，判定資金操作合規(guī)，同時(shí)保證冪等和并發(fā)！

寫入階段：事務(wù)同步寫入流水和余額

響應(yīng)階段：告知上游回調(diào)

梳理數(shù)據(jù)流后，接下來分析每個(gè)階段可能引發(fā)的問題。按照優(yōu)先級(jí)，先分析業(yè)務(wù)問題區(qū)域（讀取階段，計(jì)算階段，寫入階段），通常問題會(huì)出現(xiàn)在業(yè)務(wù)階段；之后，再分析框架問題區(qū)域（請(qǐng)求階段和回調(diào)階段），該區(qū)域出現(xiàn)問題的情況偏小，但是一旦出現(xiàn)問題，就是比較有意思^_^！

讀取階段，計(jì)算階段，寫入階段三個(gè)階段是具體的業(yè)務(wù)操作，從并發(fā)和耗時(shí)兩個(gè)角度來分析下可能的問題點(diǎn)

耗時(shí)分為三塊

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

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

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

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

天級(jí)QPS：當(dāng)時(shí)分析天級(jí)幾十萬單，天級(jí)QPS不到10，不高！

瞬間QPS：每個(gè)訂單拆解到資金流后，會(huì)同時(shí)操作多次熱點(diǎn)賬戶，瞬間qps相對(duì)很高，理論qps就可能達(dá)到語言上限，由于上游鏈路限流1024，按照10級(jí)別操作拆分，理論上滿池QPS在萬級(jí)別。考慮實(shí)際單量，瞬間QPS=單量(10)*拆解量(10)，實(shí)際的滿額預(yù)估QPS可能到100+ ！

按照上面分析，在瞬時(shí)QPS達(dá)到10+的情況下，熱點(diǎn)賬戶整體延時(shí)在10-100+ms，由于DB在寫入uniq_key保證鏈點(diǎn)唯一，所以出現(xiàn)并發(fā)寫入失敗也在情理之中；并且隨著數(shù)據(jù)量的提升，讀取延時(shí)增加，寫入失敗率會(huì)繼續(xù)增加。

請(qǐng)求階段做為入口，一般也分為三個(gè)小階段

webserver接收請(qǐng)求

框架加載和路由

基礎(chǔ)校驗(yàn)

請(qǐng)求階段核心耗時(shí)一般存在于框架加載和路由，高并發(fā)場(chǎng)景webserver和upstream之間的調(diào)用也是一個(gè)可能出問題點(diǎn)！當(dāng)時(shí)財(cái)務(wù)系統(tǒng)，采用歡總封裝的go-thrift，并且其他模塊并未出現(xiàn)請(qǐng)求階段問題，所以并未對(duì)這個(gè)階段的latency和并發(fā)做一個(gè)衡量，重點(diǎn)分析了業(yè)務(wù)模塊！

通過上面分析，目前問題的痛點(diǎn)是并發(fā)讀取熱點(diǎn)賬戶數(shù)據(jù)高延時(shí)引發(fā)寫入失敗，提升讀性能成為了關(guān)鍵

讀性能提升有兩個(gè)基本思路：讀的時(shí)效快和讀的次數(shù)少

針對(duì)上面兩個(gè)基本思路，結(jié)合財(cái)務(wù)賬戶情況提出了五種提升讀性能的解決方案

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

【讀快】縱向切分-時(shí)間分庫分表：按照時(shí)間進(jìn)行縱向切分，降低查詢范圍內(nèi)的數(shù)據(jù)量，提升讀性能。缺點(diǎn)是跨時(shí)間讀不友好，開發(fā)量也不小

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

【讀快】橫向切分-業(yè)務(wù)分庫分表：按照賬戶類型或者城市分庫分表，可以優(yōu)化讀寫數(shù)據(jù)量，同時(shí)，跨表讀負(fù)擔(dān)也會(huì)較小。但對(duì)于熱點(diǎn)賬戶或者熱點(diǎn)城市，依然聚簇，效果不是很明顯。同時(shí)，再次對(duì)熱點(diǎn)賬戶進(jìn)行橫向分庫分表也是極度不推薦，引入的極高的讀寫成本均。

【讀少】階段快照：一定量或者一定時(shí)間內(nèi)的數(shù)據(jù)，持久化一次。優(yōu)勢(shì)是極大的降低讀寫次數(shù)；缺點(diǎn)是需要復(fù)雜的邏輯來保證undo操作和數(shù)據(jù)一致性！

五種解決方案各有千秋，作為一個(gè)初期的財(cái)務(wù)系統(tǒng)推薦采用持久化last record和數(shù)據(jù)歸檔來保證寫入讀性能和整體讀的數(shù)據(jù)量。如果系統(tǒng)發(fā)展到了中期，推薦按照時(shí)間分庫分表。如果發(fā)展到了雙11或者春晚某些極端場(chǎng)景，犧牲掉部分準(zhǔn)確性，采用階段快照也是可以的。

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

DB計(jì)算：通過存儲(chǔ)計(jì)算，轉(zhuǎn)嫁計(jì)算成本給DB，減少一次鏈路請(qǐng)求。但不太推薦，復(fù)雜的sql往往有坑，insert computer from select 還會(huì)造成大面積的數(shù)據(jù)隔離，很容易引起死鎖。

請(qǐng)求階段一般有三種形式：同步調(diào)用，異步調(diào)用和偽同步調(diào)用！
前兩種調(diào)用非常常見：同步爆池的情況，一般采用限流來降壓，采用漏桶，令牌桶等等策略；異步調(diào)用通常采用消息隊(duì)列來削峰填谷；這里重點(diǎn)闡述對(duì)于支付和財(cái)務(wù)系統(tǒng)在請(qǐng)求階段經(jīng)常采用的偽同步的方式

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

請(qǐng)求階段：同步請(qǐng)求調(diào)用，核心要素追加寫入wal日志，變更校驗(yàn)位，完成同步調(diào)用！此處追加寫保證了快速寫入，校驗(yàn)位來保證數(shù)據(jù)的最終寫入成功。圖中1，2

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

回調(diào)階段：如果成功，更改校驗(yàn)位，同時(shí)發(fā)布成功廣播消息，關(guān)注結(jié)果和時(shí)效性的模塊，可以獲取最終成功的標(biāo)識(shí)！如果undo回滾數(shù)據(jù)，則發(fā)布失敗廣播消息，告知結(jié)果失敗！

在偽同步的模式下指標(biāo)衡量：

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

時(shí)效性：偽同步并非完全同步，所以結(jié)果需要監(jiān)聽回調(diào)。對(duì)于結(jié)果強(qiáng)一致的請(qǐng)求，必須監(jiān)聽回調(diào)，確保一致，時(shí)效性降低；對(duì)于弱一致可以認(rèn)為同步回調(diào)即成功，時(shí)效性提升。

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

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

總的來說，歸結(jié)了七種優(yōu)化方式（哈哈，上篇寫的八種優(yōu)化，當(dāng)時(shí)總結(jié)的，現(xiàn)在愣是想不到還有啥了^_^）。其中請(qǐng)求和回調(diào)的偽同步方式，是在架構(gòu)層面優(yōu)化，這個(gè)在多數(shù)的財(cái)務(wù)系統(tǒng)和財(cái)務(wù)系統(tǒng)的內(nèi)部數(shù)據(jù)流中都會(huì)用到；而讀寫和計(jì)算階段的優(yōu)化，可以跟進(jìn)實(shí)際業(yè)務(wù)情況進(jìn)行選型處理。

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

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

對(duì)于這個(gè)復(fù)雜大SQL事故，小拽總結(jié)了三個(gè)方面

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

本篇主要針對(duì)熱點(diǎn)賬戶問題提出了七種常用的解決方案，下篇將繼續(xù)引申探索下，各種解決方案在不規(guī)則高并發(fā)場(chǎng)景，例如雙十一，微博熱點(diǎn)事件中如何套用

預(yù)知后事如何，下回再聊！

【轉(zhuǎn)載請(qǐng)注明：熱點(diǎn)賬戶問題和常用解決方案【中】 | 靠譜崔小拽 】