本文根據於樹文老師在〖deeplus直播第231期〗線上分享演講內容整理而成。（文末有獲取本期PPT&回放的方式，不要錯過）
於樹文
光大銀行資深DBA
目前在中國光大銀行信息科技部資料庫管理團隊主要負責分布式資料庫建設項目，推進行內技術架構轉型等相關工作。
從事資料庫運維管理工作十餘年，在資料庫的性能優化，升級遷移，高可用容災等方面具有豐富經驗。
我今天分享的主題是《高並發場景下，光大銀行分布式資料庫的架構轉型實戰》。
光大銀行也是很有魄力的，拿出了一個重要的業務系統進行一次試點，做了一次這種分布式架構轉型的項目。我有過十餘年DBA相關的經驗，不過之前接觸比較多的主要還是傳統的商用型資料庫，所以能作為這次項目的推進人，也是我個人在這種新的架構下的一次學習的過程。
一、光大雲繳費平臺的基本情況
先給大家介紹一下今天分享的這個平臺情況，對於一些業務的數據概況，可以見下圖：
這個系統上線當初，是和其它的業務系統放在一起的。在2015年和2018年，考慮到業務和成本等多方面的因素，經歷過兩次業務剝離，最終在18年成了一個單獨的平臺。
裡面涉及的繳費種類包含20大類，其中有8000餘個繳費的項目，接近500個繳費渠道，目前覆蓋國內300+城市。平時大家生活中使用比較多的像水費、電費、生活費的繳納，可能都是通過這個平臺來完成的。目前，它已經被打造成為行內TPS最高的業務系統：
上圖的這些數據，可以看出從18年5月開始，交費平臺的各項數據有大幅度的增長，有的甚至是翻倍的增長。這些指標可以作為衡量一個業務系統是否有健康良好發展趨勢的依據，但是轉到後臺，最終都代表著給資料庫的壓力是一個什麼樣的變化。
二、傳統IOE架構的基本優化及面臨的挑戰
目前資料庫傳統的IOE架構是這樣的：
包括雲繳費系統，它用的也是這種傳統的IOE架構，在部署模式上是採用的雙中心RAC 2+2的冷備部署：
數據一致性是通過存儲複製技術來保證的：這個相對來講，光大用的時間也比較長，而且也證明了這種數據一致性保護機制是比較可靠的。
高可用是通過RAC自身特性以及一些第三方軟體來提供的：不得不說，Oracle還是有它的獨到之處的，不然也不會在各個領域都能有比較高的佔有率。
產品及架構設計是比較成熟的，運行穩定性比較高：之前，雲繳費平臺在這上面運行了十幾年，基本上沒有出過什麼問題。所以這種傳統的IOE架構確實是有它自身的優勢。
在這種傳統的IOE架構下，我們通常會做到一些優化，大致如下：
索引、統計信息優化：目的是讓它走最好、最穩定的執行計劃。
表分區改造：通過hash、range，或是兩層分區，打散IO消耗。
拆分存儲埠：data及redo埠隔離，避免埠混用時的壓力影響導致提交慢。
硬體迭代：性能、容量提升。
其實做了這麼多的優化，包括還有很多其它的優化，主要目的都是為了減少IO請求，通過物理設備的性能提升來保障業務能有一個穩定、快速的交易響應時間。
但是，這些可能都是只對讀IO有作用的，也就是通過儘量減少它的物理讀及buffer讀，來提升業務TPS，並降低ART。但是對於寫來說，主要是由業務需求決定的，所以從資料庫層面，至少從這種傳統的架構層面是優化不掉的，因為這個是它業務傳導過來的一個最基本的寫的指標。
所以我們總結了一下，在傳統的架構下，會面臨這樣的一些挑戰：
處理能力受存儲性能、熱點資源制約：高業務壓力下，集中式存儲資源性能受限，熱點資源、空間分配等衝突嚴重。因為這種高並發的業務，在壓力下，集中式存儲，可以說是一個單點吧，它的資源性能是受到一定限制的。像IOE用到了Oracle的RAC，倒也不是不能擴展，主要是它擴展不方便，而且擴展來擴展去就是加機器，CPU、內容都得到擴展了，但實際下面對的還是一個存儲。所以可能最終IO會成為一個熱點，一個壓力的瓶頸。
部署集中導致風險集中，變更維護窗口壓縮：一旦出現軟體產品缺陷、硬體損壞等故障時，所有的交易都會受影響，或者是變更維護操作，如果說需要停機的話，需要整個停下來才能變更（比如說打個補丁，或者是有些不能動態修改的參數之類的），都會影響系統全部交易。
跨資料庫中心多活部署：對於傳統資料庫來說，這種部署模式也非常困難。可能只有通過分布式的引入，才能提升多活部署的可能、提升可用性、加快切換速度，突破特性軟硬體的成本和性能限制。
資料庫產品多樣化：之前去「IOE」這個詞也說了挺久了，畢竟還是有很多形勢上的變化，所以在商業化的產品上，可能會存在一些供應鏈的風險。那麼通過多樣化的選擇，可能會減少這方面的風險，同時也給我們更多部署上的選擇。
三、光大的分布式資料庫技術調研及思考
所以光大銀行對分布式資料庫的技術做了一些相關調研。
1、分布式資料庫核心要點
對於資料庫來講，其實它的核心其實就是SQL解析、事務控制和數據存儲與訪問。像數據複製、備份恢復、可用性切換、數據遷移、操作調度、開發接口、權限管理、對象管理、監控報警等等，這些都是它整個的一個生態。這些工具有沒有、高不高效，就決定了運維的工作能不能更好的開展。
所以，分布式資料庫其實就是將傳統資料庫的各技術組件通過鬆耦合的方式部署，通過網絡之間，會有一個相互的協同工作，達到分散壓力，提升總體處理能力的目的。也就是把我原來的瓶頸打散了。
但是被打散之後，各個組件之間可能網絡通訊成本就增加了，所以在提升總體交易吞吐量的同時，平均的響應時間也就是ART可能就會增加。拿雲繳費這個系統來說，我們測試的時候發現原來二十幾毫秒的交易，到分布式上可能就會多個十幾毫秒，或者再長一點的時間，主要整體是受到一個鏈路的影響。所以分布式並不能減少交易響應時間，但可以通過它的擴展性，帶來交易響應時間的穩定。
那為什麼我們的測試發現在分布式上交易響應時間變長了呢？主要是因為原來的資料庫還沒達到瓶頸。等到原來這種傳統架構的資料庫達到一個性能瓶頸，出現性能拐點，那時候一定會出現一個大幅度的性能抖動或者滑坡。但是在分布式架構下，我們就可以通過它橫向的擴展能力，讓平均響應時間基本維持在恆定的一條線上。
目前，分布式部署技術很多企業都在用，但切入點是不一樣的，而且也形成了多種技術路線，並且這幾種路線，從我們的調研來看，也都在不斷地演進。
2、常見分布式資料庫的技術路線
我們的分布式資料庫技術調研發現，基本上可以分為三類：
1）應用層分布式架構
主要是通過應用架構的設計，將業務數據分散到多個資料庫存儲。
這個其實也算是一種單元化吧，所以這層主要的核心是在於對進來的交易做一次解析，然後在交易通過應用層之後，解析完成了，它知道自己該去哪個資料庫，去訪問哪些數據。
2）NewSQL分布式資料庫
數據以物理分片的方式，把數據打散，分散到若干個存儲節點。它是在存儲層實現分布式的數據掃描和過濾。
3）資料庫訪問代理中間件
最早像tomcat，也算是一個分布式中間件。這種通常都是選擇恰當的分片鍵，通過分片鍵來將數據打散，然後在應用訪問代理的時候，將SQL按照它的分片規則做一次解析，解析完成後，來實現對各個分片進行單獨訪問。也就是說，相當於是做了個SQL的拆分，由它路由到我指定的資料庫上，訪問指定的數據。
這是目前常見的幾種分布式資料庫的技術路線。
3、總結
接下來我們總結和整合一下：
第一個是分布式應用架構層面。目前在分布式資料庫應用架構的路線上，就是做的分庫分表，一般都是產品/廠商自建的。因為這種一般都比其它的與應用的業務特點，結合的是更加緊密的。對於單系統來說，它單獨地進行了一些分析，對業務進行了一些拆分，效果是比較突出的，但這種模式不容易推廣，因為一旦做一個系統，就需要對系統所有的交易、資料庫的設計、表之類的重新梳理一次，比較費時間。不過效果確實很明顯，目前這麼做的系統也不少。
第二個是分布式代理中間件。主要是通過分布式代理中間件，在一定程度上實現了自動化的分庫分表。實際上就是按照分片鍵的規則將數據拆分了，由它來進行分庫分表的操作。所以這個性能還是跟應用設計有很大關係的，如果大表找不到合適的分片鍵的話，用這種資料庫可能就達不到預期的效果。所以這類我們覺得是可以作為分布式應用架構的一種比較好的補充。
第三類就是NewSQL分布式。這類的性能擴展對應用相對透明，但是這些產品出來的時間相對來說都不是很長，還在演進中，開發接口等方面可能就存在一些限制，並沒有前兩種分布式的架構那麼靈活。
四、光大自研的分布式資料庫EverDB
光大結合調研結果，採取了兩個技術路線：一個是NewSQL的引入，一個是想要自研一個分布式資料庫，也就是EverDB。
1、EverDB分布式資料庫分層設計
EverDB有三個主要的組件：
EDB-grid：資料庫訪問代理組件，具有SQL路由、數據分片、故障轉移等功能並對應用實現協議透明。（所以一個SQL進來，通過這層之後，解析完成就會告訴你你的數據在下面的某個MySQL集群上；同時分片完成之後，你也不需要關心數據是存在哪個MySQL庫、哪個實例裡，只要過了這層，就會自動地路由過去）。
EDB-bridge：資料庫複製和校驗組件，負責逃離資料庫異地災備的資料庫同步和同步數據校驗。（從上圖也可以看出，它是通過bridge複製了一個逃離資料庫的，因為畢竟像這種新的技術引用，是伴隨著一定的風險的，尤其是繳費這種系統，也是比較重要。所以當時的考慮是，通過bridge複製出來的資料庫，當核心組件，也就是grid出現問題的時候，我可以通過應用的配置調整，讓它跨過中間的所有節點，直連逃離資料庫，在一定程度上快速恢復業務。這個組件主要就是承擔這個作用）。
EDB-control：分布式資料庫管理平臺，對集群中各個功能節點及數據節點進行監管。有點類似Oracle的Grid control。
然後資料庫實際上用的就是MySQL集群。數據節點採用的就是MySQL資料庫，對部署模式沒有什麼限制，支持多種部署模式。
2、EverDB分布式資料庫主要功能特性
1）數據分片
目前支持Hash、Mod、Range、List等分片規則，分片功能對應用透明，應用訪問數據不需要額外加什麼條件。
分片數量需提前規劃，目前不支持在線調整。（也就是說如果我一開始將數據分了32個片，然後底下部署了比如說8個MySQL集群，這樣的話，實際上每個MySQL集群裡是有4片數據的。這時如果我想要重新做分片的話，這些數據是需要重新導一遍，才能改分片數量的。所以分片數量初期的規劃就比較重要，而且和後續業務的增長趨勢的預估以及我相關節點的擴容計劃是有關係的。因為像前面提到的32個分片，假設我後端的資料庫擴展到32個MySQL集群的時候，那實際上每個集群裡只有1片數據了，這個時候再想擴就擴不了了，只能是重新加分片，那就會涉及到數據遷移）。
2）數據存儲
MySQL數據源支持主從半同步、MGR等多種部署方式，其中主從半同步方式至少每個機房可存在一個強一致節點，從而保證跨機房切換RPO為0。（不然的話，如果只是速度快，將近地/同機房的數據同步完了，跨機房的沒有管，一旦發生宕機、網絡故障時，切換過去就有可能是舊數據了。所以這塊兒可能也算是網絡上增加成本開銷的原因，因為畢竟是要等一個跨機房的同步。相對而言，金融行業對數據一致性的要求是比較高的，所以是不允許出現數據丟失的情況）。
3）橫向擴展
計算節點EDB-grid支持橫向動態擴展，擴展過程對集群無任何影響，是比較透明的。也就是說，grid直接動態增加就可以了，通過前端的F5配置，應用配到F5那層之後，F5會自動相應的轉發到新的節點上來。
數據節點分為物理設備擴展及資料庫實例擴展，兩個達到的目的是不一樣的：
一個是可以稀釋實例分布（因為畢竟也是考慮到成本，有可能物理設備是復用的，會存在一個物理機上跑著一個MySQL集群的主，同時還跑著別的集群的從實例，所以通過這種物理設備的擴展，可以通過切換並移動MySQL的實例，來減少物理設備的容量壓力）。
另一個是可以稀釋數據分片（實例數量的擴展，會涉及到分片數據的在線移動。這個經過我們的測試，發現其實會對局部的交易會產生一定的影響）。
4）遷移備份
通過DataX工具實現異構分批次遷移數據，這個也是在雲繳費平臺從傳統的Oracle到EverDB的過程中所採用的方式，並在這個過程中完成了字符集轉換。像原來Oracle的字符集可能有一些與MySQL不太一致的地方，可以通過這種文本落地的方式，把這個轉換完成。像這種系統數據量比較大，我們在遷移的過程當中也做了一些批次的拆分，有一些不變的例數據，可以提前進行遷移，其實在真正實施的當天，遷移的數據是很少量的一部分。
數據備份為分集群整體備份以及單庫備份，並支持額外的備份網絡。畢竟這種分布式架構本身對網絡的依賴度就非常高，如果要是與業務或者節點之間的通信採用同一個網絡的話，備份是有很大可能會干擾正常的業務的。集群整體備份這塊兒，其實是備的完整的集群拓撲，它還原出來的其實也是一個完整的集群拓撲；單庫備份是一個邏輯備份，可以實現相對來說靈活一點的數據恢復。
5）開發應用
支持分布式事務。
支持事務、悲觀鎖以及全部隔離級別。
支持絕大部分MySQL語法（不是全支持，像我印象中，有一些像left join之類的支持程度是有限的，因為畢竟它的解析是靠grid來完成的，所以它的語法在這層的邏輯實現上是有一定的限制的）。
有限支持函數（min、max、count、sun、avg），視圖（只可進行select操作，不能做update操作），過程（過程內不支持函數調用）。
不支持觸發器、定時任務、臨時表。
所以在開發上面，可能確實和原生的MySQL是有一定的區別的，但是已經可以滿足我們目前大部分的應用邏輯設計的需求了。
3、EverDB分布式資料庫測試重點
在整個改造的過程當中，資料庫測試算是我們的一個重點工作，主要集中在兩方面：
1）測試場景設計
這次數據的遷移改造，我們一共設計了30餘個測試場景，其中主要包括：
各功能節點的故障切換（因為相對傳統的架構來說，雖然不集中了，但是功能節點變多了。同時也擺脫了傳統的小機，因為現在用的都是X86的伺服器了，所以它硬體的故障率可能是有一定上升的，所以我們模擬了每個功能節點的故障）。
節點間網絡故障（因為網絡整個的交易鏈路比原來的長了很多，所以跨機房或者是網卡的網絡故障都有可能發生）。
集群動態擴容（也是比較體現分布式資料庫優勢的）。
不同背景壓力對聯機交易的影響（因為大部分系統還是有批量業務的，就會涉及到一些大的事務的處理，所以我們對於這種背景壓力對於聯機的影響也是比較關注的）。
極端情況下的備份恢復（比如說集群完全不能對外停服，或者是各個不同的節點crash之類的）。
MGR/MS對比（一開始我們挺傾向於使用MGR的這個架構的，畢竟它也是MySQL原生出的集群模式。但是經過測試對比，發現還是主從半同步的效率高一些，而且現在MGR確實技術還不是很成熟和穩定，所以我們最後部署上是選擇了主從半同步）。
2）測試關注的指標
各故障場景的影響範圍（因為畢竟按預期，是想將整體全局的故障轉換成局部的故障）。
交易總體受影響時間時長。
交易失敗筆數。
響應時間變化。
節點間網絡流量（主要還是跨機房這塊兒的，因為同城跨機房可能不光是有分布式資料庫的流量，還會有業務的流量，或者是其它數據同步的流量。所以可能這種流量之間，對於帶寬的要求也是使用分布式過程當中比較需要注意的點）。
4、雲繳費系統實施重點
在雲繳費系統實施的過程當中，也有一些重點，簡單給大家介紹一下：
1）邏輯設計
分片表：是資料庫裡最大的一張表，裡面可能記錄著日誌、流水等。像這種表，是一定要有一個合適的分片鍵的，而且我們要把握好分片的數量。對這種大表的訪問、拆分，平均分配到各個分區，只有實現了這部分的數據打散，才能真正對資料庫的性能和訪問效率有一個提升。所以幾個大表之間可能同時還會存在一些Join的情況，所以我們這次在資料庫的設計上，對這些大表都選擇的相同的分片鍵，這樣一筆交易進來，它可能帶著相同的分片鍵，只會到一個實例裡的一個資料庫裡去。所以它通過這種方式，減少了跨庫甚至是跨機房的這種Join，來避免由於這些操作而增加的交易成本。
全局表：在繳費系統裡，數據量有限，修改較少，讀取較多。此類表會由grid這層把這些表複製到所有分片，可以和各分片進行本地Join。我們的總體目標就是為了讓它規避這種跨庫。
普通表：數據量有限，修改讀取都較少。此類表集中存儲不分片。這時候如果需要取得數就是臨時Join一下，不需要和分片表Join，不會有太大的成本和開銷。
2）開發設計
連接驅動：和MySQL沒有什麼區別，基本上語法遵從MySQL的協議就可以了。
開發過程中儘量避免使用存儲過程。相對來講，這次做的應用改造就是將交易邏輯變得簡單化了，把原來複雜的地方都給優化掉了，同時也選擇了相對合理的字符集，因為這個系統原庫的字符集其實不太合適，所以借著這個機會把這個問題解決掉。
分布式資料庫存在多個接入IP，需合理設計負載均衡和故障重連機制。因為剛才那張架構圖中，它是從應用連接到F5，再從F5分發到每一個中間件節點，中間件節點再到MySQL。中間件節點到MySQL是長連接的，但從F5到中間件這層是不能用長連接的，因為如果要是這個時候用長連接，可能就會失去F5負載均衡的作用，所以在這種情況下，又要用短連接，又要保證在出現分布式事務的時候不能因為連接中斷導致分布式事務失敗（或者如果沒有分布式事務，可能一筆交易中，需要做多個DML操作，可能因為短連接斷開了導致它做了3個DML，最後一個沒有做成）這種情況肯定是不可能出現的。所以這時候我們調整了一下短連接的配置，讓短連接的配置足夠長，然後F5的連接斷開釋放由應用層來控制。比如說做十筆交易之後斷一次。所以這塊兒的負載均衡是靠這個來設計的。
3）批量設計
在批量這塊，原來在Oracle環境裡並沒有做到與資料庫的一個完全隔離，這次在分布式改造中，也是對這塊兒做了一個優化。所以在隔離的情況下，我就不能讓批量運行環境成為一個單點。所以就對批量故障的冗餘、重試、數據檢查及校驗進行了重新設計。因為批量設計中也會涉及到一些分布式的事務，所以這塊兒的數據的檢查和校驗也是設計的一個重點。
優化批量邏輯，減少跨分片Join及複雜SQL。因為複雜SQL對於分布式來說，很多產品對於複雜SQL的支持還是很有限的，可能跑起來的效果也達不到預期。
批量拆分，充分利用分布式資料庫資源。
4）試運行方案設計
剛才提到的bridge的工具，就是我們現在在試運行，以後會正式運行的一個主要的逃生方案。這種新技術產品帶來的架構風險，一定要有逃生方案才能比較有信心在上面跑，在極端情況下，可以將新架構隔離開，讓它回到相對來講比較傳統的架構上去。
目前雲繳費架構已經算是改造完成上線了，但是它並沒有完全接軌Oracle的真實交易，是在應用層做了一個轉發，把發給Oracle的交易同步發給EverDB一份，然後通過這個試運行階段，來驗證產品的兼容性、穩定性。這個也算是個過渡階段吧，因為只有經過真實生產的全量交易的壓力後，我們才敢把其它的交易完整切過去。
所以這塊兒的設計也挺重要的，如果直接就新上的話，可能會出現各種各樣預期外的問題，解決起來可能也會無從下手。我們利用交易轉發的機制，還在驗證這種新架構的運行模式。對這種並行試運行的方案還有逃生方案，都要進行充分的測試，最終目的就是保障數據安全，同時這種逃生環境要能承載一定量的業務運行，畢竟它節點數不會有分布式那麼多，所以如果業務全部切過來的話，它可能運行起來會遇到一些資源徵用之類的問題。
5、雲繳費系統部署架構
這張圖是雲繳費系統部署架構的一個真實的1:1的物理圖：
它前面是APP的數量，一共是24臺，後邊用兩個grid節點，然後有兩臺備份的伺服器，和兩臺逃生的伺服器。中間的區域全是MySQL的集群，全都是主從，採用的是一主三從的模式，目前是雙機房運行。每個機房裡有一主一從，另一個機房裡有兩從，然後通過配置，我保證同機房和跨機房有兩個節點是數據強一致的，另外一個節點就不管了。這樣如果發生故障的話，由grid這層會告訴它哪個節點的數據是最新的，是一致的，這樣就會切到那個節點。
6、雲繳費系統試運行總結
目前雲繳費系統試運行也有半年了，這裡是對它簡單的一個總結：
1）分布式改造收益
處理能力橫向擴展性提升，擺脫傳統IOE的瓶頸。
降低對高度存儲的依賴。因為剛才那張部署圖裡，所有的機器都沒有用存儲，像EMC或者其它牌子的存儲，都沒有在用，實際上就用了本地的NVME的閃盤；這個性能確實比存儲要高很多，所以它其實從一定程度上彌補了網絡上鏈路邊長帶來的損耗。
全局故障降低為局部故障。就是可能某一部分數據不可用，比如8個集群，哪怕一個集群整體都掛了，從也全掛了，但我可能還有7個集群，至少還有八分之七的對外服務是好的。
2）運維方案積累
因為這個對於我們來說也是第一次做這種比較大的改造轉型，所以在監控指標及監控方案、故障場景的應急預案、分布式資料庫的技術標準&規範等，都是通過這次的探索和遷移總結出了一些經驗。
3）產品自身完善
提升集群整體運行工穩定性。這方面還是有提高的空間的，尤其是在架構上，我們也在嘗試把一些像ZooKeeper這種小的組件與其它的組件做整合，減少各功能節點的離散程度，畢竟節點越多，出問題的可能性就越大。
對各分布式組件進行功能增強。因為通過這次開發和上線工作，也發現了資料庫架構中的一些問題。
優化部署架構。
4）技術難點
目前我們碰到的一個技術難點就是交易全鏈路監控分析。因為這個交易鏈路從外部到前端的F5，再到AP，再到F5，再到grid，再到MySQL，包括可能grid之間（也就是中間件節點之間）可能會有些數據同步，MySQL之間也會有些數據同步，所以這個交易鏈路實際上比以前變得是太長太長了，所以現在如果某一筆交易慢了的話，可能在一些有日誌的節點上，或者說日誌做的比較完善的話，可能還是有跡可循的。可是如果網絡抖動了一下，或者是出現一些延時的問題，目前看這種全鏈路雖然不是不能監控，但至少還沒能實現一筆交易完整的一個追溯的過程。
五、EverDB後續發展規劃及裡程回顧
1、後續發展規劃
1）近期
增強運行穩定性，提升分布式事務性能。目前來講，我們對於XA事務的處理可能性能上還有一定的優化空間，同時我們也希望這種資料庫能夠支持國產ARM平臺和國產作業系統，能夠接近於全系的安全可控標準；
2）中期
我們想簡化部署方式，來實現輕量級的部署。而且像中間件的組件還有bridge的組件，我們想應用到單元化架構裡去，就是把它拿出來，不一定就只能在我們這個架構裡用。因為它本身就是鬆耦合的，拿到別的場景下，一樣可以比較好的發揮它的作用。
還有一個就是擴展運行數據採集能力。因為數據這個東西其實在運維的過程當中是非常重要的，Oralce做的最好就是AWR 報告，其它不管是傳統商業產品，還是新生的開源產品，在這方面還是比較欠缺的。所以我們想通過運行數據的採集，加上對數據的分析，來實現幫助資料庫的運行狀況能夠長期保持在一個穩定良好的狀態之下。
3）遠期
如果說的再遠一些，就是希望支持更多種底層數據存儲引擎，不僅僅是MySQL了，可能還會有金融其它的資料庫產品，並通過這種方式來擴展我們的應用場景。
以上就是我們後續想對分布式架構做的一些主要的工作。
2、裡程回顧
這裡展示了我們整個的一個裡程碑，從開始改造到現在經歷的一些比較重要的時間節點：
18年，啟動了技術路線的調研。
19年第一季度完成了方案的選型，同時這個項目也正式地立項。其實這中間經歷了大概有半年的時間，調研的過程我們還是收穫很大的，因為我們看到了同業或者是網際網路都在用什麼樣的產品，用什麼樣的架構，走什麼技術路線，這些作為我們的參照依據，最終才有了EverDB的立項。
19年11月，我們完成了EverDB1.0版本的開發。
後面時間很緊張，用了大概兩個多月，就把雲繳費基於EverDB1.0的測試完成了，並且做了投產試運行的工作。目前是處於全量交易轉發的階段。之前1月的時候，我們只過來了八分之一的量，後面通過不斷觀察資料庫的指標，還有運行的穩定性，慢慢開到了半量、全量。
今年5月，我們啟動了相應的升級項目，想後續對它整體的功能和組件做一些增強及優化。
其實架構轉型，收穫還是很大的，對於分布式的一些優勢、劣勢，包括它能做什麼，不能做什麼，如果沒有完整地做一次的話，了解的就沒有這麼深入和具體。以上就是我今天給大家分享的全部內容。
>>>>
Q & A
Q1：分片集群一致性備份策略是怎麼樣的？跨機房切換後性能下降後怎麼和應用聯動的呢？
A：是這樣，關於備份，是可以在grid層面獲取到每個數據節點的一致性點的，可以通過這個一致性點，對後端的MySQL做一個相應的備份。關於跨機房切換後性能下降的問題，從1:1的架構圖裡，可以看出，我們做了伺服器數量上的冗餘保障，即便只在單邊機房運行，每個伺服器上也只有一個主節點，不會出現切換後一臺伺服器存在多個主節點導致的資源爭用問題。
Q2：MySQL使用的是什麼版本呢？
A：目前使用的還是MySQL 5.7.26，暫時還沒考慮MySQL 8。MySQL 8我們也在學習當中，因為它目前出現的時間也不算太長，相對來說現在比較穩定的還是MySQL 5.7.26或者MySQL 5.7.28這種版本。
Q3：跨機房的延時怎麼解決呢？
A：其實跨機房的延時很難解決，因為你要保證數據一致性的話，跨機房的延時是一定要等的，就像CAP，可能保了一致性，就要犧牲一些別的東西。這個可能不同的領域有不同的權衡吧，也許對有些能夠犧牲一致性的業務來說，對這塊兒就可以把延時問題規避掉。但是涉及到轉帳，這種帳務問題，可能還是沒辦法解決掉延時。其實在發生故障切換的時候，我們必須要保證另一個機房是有一份完整的數據的。
Q4：分片表主要就是業務流水，全局表就是類似人員信息這種主數據？
A：差不多，這個也主要是在開發層做的設計。對於表的分類大致是這種方向，因為其實就是流水錶、日誌表最大，這種表在原來的Oralce的部署裡面就已經做了一層甚至兩層的分區了，只不過它提供的存儲還是在一個裡邊。在這塊兒，如果將分片表按照分片鍵做了拆分，實際上就已經部署到不同的物理分區上了。
Q5：選擇合適的MySQL字符集，選了什麼，utf8mb4嗎？
A：是的，用的就是utf8mb4。
Q6：分布式，是否涉及到多個庫完成一個事務？若有，如何保證事務完整執行？
A：分布式肯定是要涉及多個庫的，這個實際上是已經跨了物理的分區和我的MySQL實例的，這個目前在雲繳費的批量交易裡是存在的，其實大部分聯機都規避了這個問題，所以在批量交易裡有這麼個事務，就是用的XA的事務協議，來保證事務的完整性。
Q7：資料庫節點變多，是如何做到備份統一調度的？
A：這個其實跟剛才Q1是一樣的。實際上我們備份的時間還是選擇在業務相對低峰的時間段進行的，可能凌晨幾點這樣，因為確實在獲取一致性點的時候，對業務是有點影響的，所以當節點變多的時候，影響可能會有點放大，不過也不會太大，而且又是凌晨兩三點的那種基本上交易比較少的時間。所以還是通過數據一致性點來做的統一的調度。
Q8：分布式資料庫，多大尺寸時，得再拆庫？或者，達到其它什麼指標時，得考慮再拆庫？
A：這個主要還是看物理分區的容量。因為這個用的不是存儲，而是nvme的閃盤，也是為了保證效率，所以這個盤的擴展數量肯定是有限的。還有就是CPU和內存，當這幾方面，還有單點承受的一些QPS、TPS指標，當它承受到一定量，可能會有些風險的時候，可能就會提前做一些數據節點或分片水平擴展的操作。
Q9：備份是如何發起的，有統一的資料庫備份平臺嗎？
A：備份發起使用control的那個管理組件，它實際上是一個外部的管理臺，用它來調度響應的備份策略的。
Q10：對SQL有限制麼，中間件會有內存溢出的風險麼，mycat落地中間數據，有內存溢出風險
A：目前還沒出現，關於溢出這個問題，目前在測試環境應該是壓到了差不多10000左右的TPS，目前看著是沒有什麼問題。
關於對SQL的限制，是指語法嗎？語法上是確實有些限制的，比如對於過程的調用、臨時表表或是left join之類的操作，具體的限制要通過開發手冊作為指引，但目前基本已經支持了絕大多數的開發語法。
Q11：可以實現在線擴縮容嗎？具體原理是怎樣的？
A：有兩種，一種是要擴物理的機器，一種是要加MySQL實例。擴機器的時候，就是挪動主從的位置，其實也就是一個切換，對局部影響有，但比較小，從測試結果來看，比加實例挪數據的影響小得多。
Q12：讀寫分離是基於中間件還是業務層處理？
A：是通過中間件來做的，具備讀寫分離功能但目前未啟用，主要是因為試點業務沒有這個需求，所以不是目前主要的測試目標。
Q13：DDL變更怎樣保證所有節點一致，如果某個節點執行失敗，怎麼處理？
A：其實現在對於DDL的原子性還是沒有一個很好的保障的，但是對於DDL操作是有相應的檢測命令的，所以在DDL場景下，可能還是需要通過操作的標準規範來避免這個問題。比如說，DDL命令下去之後，要返回一下我所有DDL修改的結果，因為它畢竟涉及到多個實例，目前還沒有很強的一個DDL保障。
獲取本期PPT
請添加右側二維碼微信