銀行跨數(shù)據(jù)中心數(shù)據(jù)庫雙活架構(gòu)設計

1、 銀行跨數(shù)據(jù)中心數(shù)據(jù)庫雙活架構(gòu)設計 難點一：數(shù)據(jù)庫雙活，如何解決幾十公里延時帶來的性能問題？分享一：幾十公里的延時主要表現(xiàn)在兩方面，一個是存儲雙寫延遲，一個是節(jié)點通信延遲。從存儲延時來說首先要做到本地讀。這個在GPFS文件系統(tǒng)里是可以做到的。其次是增大緩存，減少同步寫的次數(shù)。對于數(shù)據(jù)庫里的大對象，最好使用inline的方式放在常規(guī)表空間里，或者存放在開啟了文件緩存的表空間里。對于數(shù)據(jù)庫日志，一定要設置足夠的日志緩沖池，避免因為緩沖池不夠發(fā)生的同步寫。在通信的延遲上，我們需要做到的是盡量減少通信。所以要想辦法解決熱點數(shù)據(jù)問題。同時能夠本地訪問和緩沖的都要想辦法實現(xiàn)。例如推薦采用客戶端偏好鏈接?；?/p>

2、于current member來組織表和數(shù)據(jù)等等。（孔再華）有個問題，由于CF節(jié)點只有一個，對于寫來說，必然存在兩個站點的DB2 MEMBER都同時需要通過RDMA訪問CF節(jié)點GBP，本地來說，問題不存在，跨站點RDMA訪問的話，這個通信耗時和性能是否需要重點關注？（鄧毓）你說的非常正確，跨站點的member和CF通信需求是雙活環(huán)境調(diào)優(yōu)的關鍵。所以這個就是重點關注的對象，要減少這種交互。數(shù)據(jù)庫提供了mon_get_cf等相關表函數(shù)能夠抓取CF的功能和耗時，進而分析是什么操作最慢，能不能減少或者調(diào)整。（孔再華）分享二：我從Oracle數(shù)據(jù)庫層RAC說一下吧，個人比較喜歡用ASM，用ASM可以解決

3、一部分性能問題，之所以說一部分是因為ASM也只能解決讀的問題；由于距離產(chǎn)生的延遲，那么最好的辦法就是不縮短距離，這個好像是廢話，但是對于Oracle ASM的 redundancy來說其實是可以做到的，比如創(chuàng)建Oracle ASM的磁盤組的時候選擇的是Normal redundancy的方式，那么磁盤組就會至少有2個failure group ，而我們可以把2個failure group里的物理盤手工的劃分到不同的物理位置，一般雙活都有2個機房，那么一個failure group里放一個機房的磁盤，另外一個fialure group里放置另外一個機房的磁盤，這樣雙活也就實現(xiàn)了，但是隨即而來的問

4、題就是物理距離的增加和光信號的衰減和傳輸?shù)男阅芙档?，Oracle ASM考慮到提升一部分功能，在參數(shù)里提供了asm_preferred_read_failure_groups這個參數(shù)，也就是說當做物理讀的時候每一個機房里的節(jié)點（RAC節(jié)點）都可以配置自己優(yōu)先讀的“機房” ，這樣可以保證“讀”不受“距離”的影響，但是“寫” 是必須要在雙節(jié)點都完成的，所以對于ASM來說對于“寫”也沒有特別好的辦法解決距離產(chǎn)生的延遲。 當然這個時候如果RAC的節(jié)點的使用和劃分以及應用層的布置是都慎重考慮的，否則有可能會出現(xiàn)本來業(yè)務應該登陸節(jié)點1 而因為配置問題缺被隨機分到了節(jié)點2，那這個時候反而適得其反。（liuh

5、efromoracle）分享三：數(shù)據(jù)雙活和網(wǎng)絡延遲的性能問題是一個很難平衡的問題。常見的方案是采用專線連接，更快的服務器，優(yōu)化的網(wǎng)絡基礎設施和應用，而且?guī)资锏木嚯x只能算同城，對于數(shù)據(jù)雙活而言并不是很大的問題，當然也可以選擇較近的距離作為數(shù)據(jù)中心位置。（韓成亮）分享四：數(shù)據(jù)寫到主服務器，commit時復制到從服務器。復制完畢commit完成。只有commit有性能問題，是批量操作性質(zhì)，可以把通信開銷降到最低。但是如果有鎖，鎖的傳遞需要時間。復制時如果從服務器失效，操作應該依然成功，要在主服務器記錄從服務器遺漏事務。待從服務器復活，回復遺漏事務。如果寫幾千條記錄到主服務器，這期間沒有復制開銷。

6、在commit時復制，產(chǎn)生一個批量傳輸，開銷是很小的。但是如果主機從機都在錄入數(shù)據(jù)，他們之間是否有重復記錄是不易檢測的。一個辦法是commit時檢測，重復數(shù)據(jù)導致commit失敗。如果在恢復遺漏事務時發(fā)生重復記錄啦，唯一的辦法是拋棄重復記錄。所以主從系統(tǒng)需要階段性一致性檢查，如果有不一致數(shù)據(jù)，以時間戳最新的為準。（匿名用戶）難點二：如何解決熱點數(shù)據(jù)在雙活環(huán)境的問題？分享一：熱點數(shù)據(jù)是指當前業(yè)務頻繁訪問的數(shù)據(jù)。如果是單節(jié)點數(shù)據(jù)庫，這些數(shù)據(jù)集中在一起可以提高緩沖池命中率。但是在集群環(huán)境恰恰相反！不同數(shù)據(jù)庫成員節(jié)點訪問同樣的熱點數(shù)據(jù)會產(chǎn)生競爭問題。所以在集群環(huán)境，需要考慮熱點數(shù)據(jù)的分布。大的page

7、size會存放更多的row，會有更大的概率產(chǎn)生競爭。所以在集群環(huán)境，盡量使用小的pagesize， 例如4K。而對于熱點表，我們可用通過在使用分區(qū)表等數(shù)據(jù)庫技術(shù)來從物理上打散當前的熱點數(shù)據(jù)。例如我們在計費系統(tǒng)的雙活環(huán)境里面，針對熱點的日志表，傳統(tǒng)分區(qū)表一般使用時間列來組合數(shù)據(jù)，而我們是用了current member這個變量和序列號組合，做了個隱藏列，實現(xiàn)本地節(jié)點插入數(shù)據(jù)落在自己單獨的分區(qū)里，同時本地分區(qū)也是被輪詢使用，徹底打散熱點數(shù)據(jù)。部分定義如下:SERIALIZED_REQUEST BLOB(1048576) INLINE LENGTH 1000 LOGGED NOT COMPACT ,

8、CURMEM SMALLINT IMPLICITLY HIDDEN WITH DEFAULT CURRENT NODE ,IDKEY SMALLINT IMPLICITLY HIDDEN GENERATED ALWAYS AS (MOD(ID,10) + MOD(CURMEM,4)*10) )COMPRESS YES ADAPTIVEINDEX IN TBS_LOG_IDX_4K PARTITION BY RANGE(IDKEY)(PART PART0 STARTING(0) IN TBS_LOG_DAT INDEX IN TBS_LOG_IDX_4K LONG IN TBS_CLOB_DAT

9、,對于熱點表的熱點索引，建議使用分區(qū)索引，random索引等方式。也可以加入current member列作為索引的一部分，從而減少成員節(jié)點間的競爭。（孔再華）分享二：主要是通過部署負載均衡設備，當然熱點數(shù)據(jù)的可以通過讀寫分離和緩存來實現(xiàn)，業(yè)務層面或者架構(gòu)層面的調(diào)整其實是最簡潔有效的。（馮帥）難點三：在雙活環(huán)境應該怎么設計數(shù)據(jù)庫對象？分享一：其實作為雙活環(huán)境不可避免的存在很多問題，比如說網(wǎng)絡延遲，熱點數(shù)據(jù)，數(shù)據(jù)耦合等，其實最主要是數(shù)據(jù)的一致性，作為雙中心的環(huán)境，我們需要保證數(shù)據(jù)庫的一致性，這個就要求我們在設計表或者其他對象的時候需要考慮這方面可能出現(xiàn)的問題，加強對于業(yè)務維護時間戳的維護，同時減

10、少雙數(shù)據(jù)中心的單個時間點的高數(shù)據(jù)交互，對業(yè)務邏輯進行拆分打散，避免大事務對復制延遲的影響，這就要求我們在設計表的時候需要進行更加細致的拆分，特別是對于熱點數(shù)據(jù)，盡量使用緩存處理。（韓成亮）難點四：本地數(shù)據(jù)庫雙活的異地容災該怎么做？分享一：數(shù)據(jù)庫雙活環(huán)境做異地容災就是選擇如何復制數(shù)據(jù)。復制數(shù)據(jù)有兩種方式，一種是通過存儲復制，另一種是通過數(shù)據(jù)庫復制技術(shù)。存儲復制只需要復制單數(shù)據(jù)中心的數(shù)據(jù)，在異地搭建同架構(gòu)的集群環(huán)境（可以使輕量級的，資源配置不要求一致）。我行就有系統(tǒng)通過SRDF存儲異步復制技術(shù)將數(shù)據(jù)復制到異地。數(shù)據(jù)庫復制技術(shù)更推薦使用。因為數(shù)據(jù)集復制技術(shù)能夠規(guī)避存儲復制壞塊的風險。同時對網(wǎng)絡帶寬的

11、壓力也小很多（只復制變化的日志）。這個是更加推薦的方式。（孔再華）分享二：異地容災主要看你需要實現(xiàn)什么樣的級別。常見的容災方案有1 基于存儲層的容災復制方案2 基于邏輯卷的容災復制方案3 基于log的邏輯復制方式（ORACLE REDO、MYSQL binlog）4 還有一些第三方的軟件5 自己開發(fā)的一些腳本或者工具其實，總的來說，本地數(shù)據(jù)庫雙活的異地容災，單活異地容災最大的區(qū)別在于，你以哪個為主，同步的頻率，同時，如果你的環(huán)境已經(jīng)是雙活，那么異地容災說白了僅僅是一個冷備。至于如何做，需要切合你的業(yè)務需求。（韓成亮）難點五：有沒有針對雙活環(huán)境的數(shù)據(jù)庫開發(fā)規(guī)范？分享一：在雙活環(huán)境大部分開發(fā)規(guī)范是

12、和單機數(shù)據(jù)庫的開發(fā)規(guī)范一樣的，但是有寫針對這個環(huán)境特點的開發(fā)規(guī)范：事務處理設計：盡量避免熱點數(shù)據(jù)和不必要的數(shù)據(jù)重復訪問。例如計費系統(tǒng)的查重，入表，更新表等操作，可以改變?yōu)樽詈笾徊迦胍粭l最終的記錄。盡量將業(yè)務分表。例如計費里面將不同的業(yè)務計入不同的流水表里面。合理設計索引。不要建立不必要的索引，適當使用聚合索引。批處理：由于CF通信和存儲復制的延時，雙活環(huán)境的單個事務會比單機版慢，所以批處理建議通過提高并發(fā)的方式來加快處理速度。拆分批處理，將單次批拆成多個批一起跑。例如一天的歸檔拆成按照小時的歸檔。作業(yè)拆分，使用跟多并發(fā)的方式處理單個批處理。報表：在雙活環(huán)境里面運行實時報表需要慎重，防止GBP的

13、DE空間被占滿。盡量避免出現(xiàn)全表掃描的報表。合理安排利用索引，減少記錄掃描數(shù)量。（孔再華）分享二：其實還有一些更加嚴格的安全規(guī)范，行為規(guī)范1. 表結(jié)構(gòu)變更必須通知DBA進行審核。2. 禁止有super權(quán)限的應用程序賬號存在。3. 禁止有DDL、DCL權(quán)限的應用程序賬號存在。4. 重要項目的數(shù)據(jù)庫方案選型和設計必須提前通知DBA參與。5. 批量導入、導出數(shù)據(jù)必須通過DBA審核，并在執(zhí)行過程中觀察服務。6. 批量更新數(shù)據(jù)，如UPDATE、DELETE操作，必須DBA進行審核，并在執(zhí)行過程中觀察服務。7. 產(chǎn)品出現(xiàn)非數(shù)據(jù)庫導致的故障時，如被攻擊，必須及時通DBA，便于維護服務穩(wěn)定。8. 業(yè)務部門程序出現(xiàn)BUG等影響數(shù)據(jù)庫服務的問題，必須及時通知DBA，便于維護服務穩(wěn)定。9. 業(yè)務部門推廣活動或上線新功能，必須提前通知DBA進行服務和訪問量評估，并留出必要時間以便DBA完成擴容。10. 出現(xiàn)業(yè)務部門人為誤操作導致