以下文章來源于DBAplus社群 ，作者魏亞東
DBAplus社群
圍繞Database、Bigdata、AiOps的企業級專業社群。頂級大咖、技術干貨，每天精品原創文章推送，每周線上技術分享，每月線下技術沙龍，受眾20W+。
魏亞東
工商銀行軟件開發中心經理
- 中國工商銀行軟件開發中心三級經理，資深架構師。杭州研發部數據庫專家牽頭人和開發中心安全團隊成員，負責技術管理、數據庫和安全相關工作。
- 2009年加入中國工商銀行軟件開發中心，致力于推動管理創新、效能提升，提供全面技術管控，推動自動化實施，實現業務價值的高質量快速交付；同時作為技術專家，為生產安全提供技術支持。
大家好，今天分享的主題是金融行業分布式數據庫需求及選型。
本次分享分為3個章節：
- 一、金融行業的需求核心與策略；
- 二、工行數據庫選型的發展歷程，即方案選型歷程；
- 三、轉型中遇到的各種心酸坑。
一、金融行業的核心需求與策略
1、傳統IT架構挑戰
大家可能都知道，工行最早是基于IBM大型主機搭建的核心系統，以及基于Oracle和IBM WAS搭建的OLTP系統，在分布式體系大熱之前處于同業領先地位，當然現在也是處于同業領先的，但是科技成本也相對較高，所謂的一份價錢一分貨就是這個道理。
但是隨著分布式技術的成熟，傳統的IT架構面臨著4大挑戰：
1）從處理能力層面來看，傳統應用（也叫巨石型應用）系統規模龐大，采用集中式架構設計，使用單一系統垂直擴展模式，擴展能力相對來說是有限的；另一方面，大數據時代引發海量數據分析處理和存儲處理的問題，對擴展性、可靠性和吞吐量提出了較高要求。
1）從運行風險層面來看，客戶對金融行業的系統有著更高的業務連續性保障要求，對不可用問題實際上是零容忍的，比如要求7*24小時業務不能中斷。
3）從快速交付層面來看，傳統巨石型應用實際上與快速交付是相悖的，應用內部模塊、應用與應用之間耦合度高，使得軟件開發和產品服務交付周期長，無法滿足業務快速上線的需求，從而逐漸泯然眾人矣，淹沒在茫茫的金融行業洪流中。大家可以看到不論是金融科技還是科技金融，一大堆的金融公司已經淹沒在前浪里。
4）從成本控制來看，大型主機運營費用昂貴，商業產品License費用高，買個機器和服務隨隨便便就幾千萬上億的支出，真的是太貴了，所以隨著業務系統做大做強，產品成本可能會成為壓死駱駝的最后一根稻草。
為此，我們可以首先得出三點需求：
- 一是應該優化應用架構、數據架構和技術架構；
- 二是應該建設靈活開放、高效協同、安全穩定的IT架構體系；
- 三是能夠強化對業務快速創新發展的科技支撐。
2、雙十一壓力
說到這里，就不得不吐槽阿里的“雙十一”，將購買壓縮到一天，對顧客和金融系統來說造成雙重壓力，相較而言，京東的618就比較人性化，每天都可以剁手，大家千萬不要以為我是給他們打廣告，要打廣告也是給工行融e購，請多多支持，謝謝。
我們可以看下雙十一的峰值變化情況，從09年開始，峰值只有400筆/秒，相較主機而言，有很大的差距，當然這也與他們當時的名氣小有關；但是15年開始，借著云化和分布式的大旗，以及當時BAT的領頭羊地位，僅4年時間，就從15年的14萬筆/秒迅速攀升至19年的54萬4千筆/秒。這就給金融行業的系統建設帶來了4個問題：
1）高并發問題，我們可以看到，阿里為了提升峰值，做了大量的緩存，鼓勵使用花唄，降低與外系統的交互，但是依然對金融行業產生額外的壓力。
2）高可靠性要求，確保系統穩定可靠，客戶可以穩定支付成功，避免因不佳的客戶體現導致用戶流失。
3）高成本壓力，大幅擴容的設備，以及隨之產生的運維成本，以及昂貴的商業liscence，給金融行業帶來一定的成本負擔。
4）同業競爭要求，大家都在做競品分析，和同行進行比較，所以別人ok，你掛了，你面子上還掛的住么，所以各機構在雙十一前進行大量的模擬測試，類似于高考前的黑暗日子。
3、金融行業分布式的核心訴求及策略
為此，金融行業分布式的核心訴求及策略可以總結為以下5點：
1）應該具備企業級的業務支撐能力，支持高并發、可擴展和海量數據庫存儲及訪問；原則上應支持同城雙活，實現集中式向分布式的轉型。工行的兩地三中心容災體系在國有大型銀行中屬于第一梯隊。
2）應能大幅降低使用成本，可以基于通用的廉價的X86硬件基礎設施；降低商業產品依賴，擁抱開源產品，互聯網企業已經給我們做了一個很好的參考。
3）應該提升數據庫的運維自動化和智能化能力，支持與自身系統進行適配性定制，工行即實現了行內系統適配定制。
4）金融行業還應考慮到社會聲譽性要求，客戶對金融行業的期望很高，特別是對銀行等金融組織，所以要求也更加嚴格，原則上應該是7*24小時的不間斷服務。像當年支付寶在15年的支付癱瘓事件僅僅上了下熱搜，但是13年工行因為IBM主機bug的問題卻上了新聞聯播，這就是所謂的愛之深責之切吧。
5）要考慮到政治因素風險，雖然全球化要求技術無國界，但是從去年開始的貿易戰，以及美國的實體管制清單，我們可以看到技術是有國界的。近期HashiCorp發布公告，其企業版產品禁止中國使用已經引發了一種擔憂。說起HashCorp ，大家可能不一定熟悉，但是其旗下有大名鼎鼎的產品Consul，可以簡化分布式環境中的服務注冊與發現流程，大家一定耳熟能詳。
最后中國人民銀行在2019年8月23日發布了《金融科技（FinTech）發展規劃（2019-2021）》中提到“做好分布式數據庫金融應用的長期規劃，加大研發與應用投入力度，妥善解決分布式數據庫產品在數據一致性、實際場景驗證、遷移保障規范、新型運維體系等方面的問題，這也給金融行業指明了方向。
二、選型的發展歷程（方案選型歷程）
接下來，給大家介紹下如何選型以及工行的選型歷程。
1、工行分布式轉型發展歷程
大家可以看下工行分布式的發展歷程：
其大致可分為2個關鍵階段，16年初-17年末為基礎研究及試點階段，之后為轉型實施及推廣階段，大致有5個關鍵時點：
- 16年初工行進行分布式體系研究，建立了基于dubbo框架的分布式生態服務；
- 16年底借著人民銀行對于個人賬戶的管理要求，實行三類賬戶的場景，開始了基于分布式的OLTP數據庫研究，并確定了基于開源MySQL的OLTP數據庫解決方案，因為MySQL 8.0的不成熟，所以我們采用了MySQL 5.7；
- 17年末，我們完成開源MySQL初步能力體系的建設，涵蓋了基礎研究、配套方法論、應用試點等等；
- 18年開始大規模的實施和推廣，我們逐步建立企業級的數據庫服務能力，包括引入了分布式的中間件，在高可用、運維能力的提升，資源使用率的提升，MySQL上云及自主服務的建設等等，同時開啟了對OLTP的分布式數據庫進行了研究；
- 19年11月我們實現了國產分布式數據庫產品GaussDB試點上線。
2、方案選型調研
大家可以看下工行的選型過程，希望可以給大家帶來一定的參考：
工行的技術規劃是相當嚴謹的，所以當時我們從五個層次進行了考量：OLTP分布式數據庫、NewSQL數據庫、支持分布式架構、自主可控、開源抑或商業。
當時我們的第一個疑問是，到底是選NoSQL、NewSQL還是關系型數據庫。
當時MongoDB、redis、Cassandra、HBASE等NoSQL數據庫開始在某些場景下大熱，但是可用場景不滿足我們的OLTP業務場景需求；NewSQL隨著google的Spanner和F1開始進入大家的視野，但是國內可以考據的只有相關的paper；國產的TiDB也是小荷初露尖尖角，但是畢竟還是幼兒期。
而DB-Egines發布的《2016年全球數據庫大盤點》，Oracle、MySQL 和SQL Server三大數據庫產品遙遙領先。MySQL當時在互聯網公司的名氣是越來越響，谷歌、淘寶、百度、騰訊、豆瓣、網易、臉書等都使用了MySQL。一方面MySQL提供了免費版，另一方面Oracle收購Sun后，可以很明顯的看到MySQL越來越規范，5.5、5.6、5.7均可以看到很明顯的提升，5.7號稱性能是5.6的3倍，5.6號稱是5.5的2倍。
為此，我們經過謹慎的驗證，選取了MySQL作為分布式數據庫的第一選型，畢竟業界有很多豐富的案例，而且在互聯網企業里面得到了很好的實踐，在業界資源案例和周邊產品都很豐富，能應對我行的高并發、彈性擴展需求，同時其具有如下特點：
- 開源，基于GPL（GNU通用許可證）可以免費使用修改，當時很多公司都基于MySQL進行了深入定制，但是在與他們的交流過程中，發現版本歸并真的是一種夢魘；
- 高可用，具有優秀的架構設計及相當豐富的周邊產品，實現了企業級的高可用性和高擴展性；
- 免費，有效降低企業運行成本；
- 趨勢，產品成熟度、排名一直遙遙領先，占行業應用的比重增大，產業鏈豐富，從業人員有規模效應。
然后我們選擇了MySQL 5.7，其相較之前的版本有6個優點：
- InnoDB增強，在線修改ibp，快速擴展VARCHAR，UNDO可回收，可關閉死鎖檢測；
- 復制增強，多源復制，基于WRITESET的并行復制，增強半同步，在線設置repl filter；
- 優化器增強，幾乎重構優化器，EXPLAIN增強，引入Optimizer Hints；
- 安全性增強，新增密碼過期機制，支持賬號鎖定等；
- 功能增強，默認開啟PFS，新增sys schema等；
- 其他增強，支持多個觸發器，新增Query Rewrite，支持設置SQL執行最長時間。
3、方案技術棧
基于MySQL選型，還應考慮一系列的分布式架構技術棧，包括分布式服務、分布式事務框架、分布式批量框架、分布式緩存、交易數據核對及補償、分布式消息、配置中心、開發及運維管理。這里提醒下大家，在選型上沒有最好的產品，只有最適合自己的產品。
1）分布式事務，業界實際上有多種解決方案，2PC（2階段式事務提交）、3PC、TCC和SAGA模型等等，我們這4種方案我行都有應用在使用，互為補充，滿足不同業務場景對事務強一致性或最終一致性的要求。
2）業務層面，在交易或者應用級層面進行數據核對及補償，有些場景就是在傳統的 OLTP 的情況下，也會對應用上下游進行核對和補償。
3）分布式消息，我們選取了Kafka作為分布式消息中間件。
4）分布式批量框架，在大規模的數據結點上進行批量操作的一個整體的解決方案。
5）運維層面，我行建立了統一的運維管理平臺，納入所有數據庫節點，實現一鍵式的數據庫安裝、版本升級、基線參數配置等等。并且實現了多種高可用策略配置，包括自動、人工一鍵式切換。
為什么要有自動化和人工的兩種切換方式?這里我要解釋下，一種新的事務上線之前，都會面臨一些挑戰和懷疑的，都是一個循序漸進的過程，特別是是在金融行業，自動真的好么？萬一搞錯了怎么辦？決策因素和模型是否設計正確？設計正確了是否編碼正確？最難的是還要應對不同應用場景的需求，有的應用要求RPO優先，有的應用又要求RTO優先。
我們之前經過充分調研，預見到該種情況，所以我們提供了多種高可用策略的靈活配置，以便滿足不同應用的個性化要求。我們的高可用整體上面基于MySQL的復制技術，通過半同步復制和多數派共識機制實現冗余備份，基于MySQL binlog日志實現自動數據補全，保障數據的一致性。
4、其他考量
除此以外，數據庫選型后，還應完善相關體系，規范設計、開發、測試和運維，實現管控的體系化和自動化，才能避免眼高手低，減少生產安全風險。
1）在設計層面，在驗證功能、新特性和配置基線，數據備份恢復的基礎上，我們參考了愛可生、阿里等公司的規約，建立了MySQL設計指引，可以說，我們是站在巨人的肩膀上成長的；加強元數據管理，提出元數據完備性、明確性、具象性和前瞻性的要求，建立應用的元數據標準，統一數據架構設計，架構師設計表結構時均基于元數據進行設計，提升數據架構質量；此外，我們還開發了表結構設計工具，將其融合在Excel中，實現對元數據的自動應用，支持自動生成腳本，簡化架構師的貫標操作，將人員成熟度的要求降至最低，提升設計效能和質量。
2）在開發層面，我們制訂了開發規范和SQL調優指引，同時基于sonar開發了MySQL檢查工具，支持對基于myBatis的mApper文件進行解析，提前發現SQL不規范的寫法，同時將sonarlint插件納入開發人員必備插件，實現規則的云化部署和本地聯動掃描分析，將規范融入開發過程中，提升開發人員的SQL編寫能力。
3）在測試層面，我們自研壓力測試服務平臺，盡量減少性能瓶頸，提前發現SQL性能問題。
4）在運維層面，感覺應該是最重要的一個層面，我們需要考慮自動化部署、監控告警、故障分析、自動巡檢以及SRE平臺，還有數據遷移、備份恢復、配置管理、版本升級、多租戶等等。
隨著節點的增加，運維實際上是一個很大的挑戰，幾千幾萬個節點，安裝、監控、報警、故障、人工處理等非常麻煩。必須要實現自動化的安裝部署，進行批量安裝部署，同時批量串行還不行，時間太長了，要并行，并行太高了，網絡的流量又會受到很大的影響，所以很多場景都需要細細打磨，還要按照博弈論的思路建立納什均衡。
監控告警里有事件等級，如何劃分各種等級，都需要靈活定制支持，建立基線告警，建立應急流程。像華為等公司都有基于設備的網絡拓撲圖，問題在哪個節點，可以快速分析和定位，所以說運維是一個很麻煩的事情，像故障分析，完善日志記錄、采集和分析，建立故障分析規范。自動巡檢，自動化的巡檢和評分報告，對實例狀態進行健康評分。在這個階段我們實現了同城RPO=0，RTO=分鐘級目標，RPO為0的切換，問題可監控，實現了人工或自動的一鍵式切換。
最后我們不得不提到SRE，很多人會聯想到運維工程師、系統工程師，其實不然，SRE本質上仍然是軟件工程師。SRE最早在十多年前Google提出并應用，近幾年逐步在國內外TOP互聯網公司都開始廣泛應用。其中Google締造了SRE，并奠定了其權威的地位，而Netflix將SRE的實踐做到了極致，Netflix僅有的個位數的Core SRE支持了190個國家、數億用戶、數萬微服務實例業務規模的運維。
像數據庫瓶頸，頂配數據庫空間仍然無法支撐業務半年發展；慢SQL數量爆發式增長，應用穩定性岌岌可危；人工運維風險極高；人工運維頻率高，研發幸福感下降這些大家都會遇到的問題也會逐漸地遇到，他山之石，可以攻玉，我們完全可以把別人的挫折拿過來，避免自己走彎路。
4、MySQL上云
在逐步推進的過程中，完善選型體系建設后，為了確保資源的有效利用，上云實際上是一種必然的選擇。從工行來看，經歷1-2年的發展，MySQL數據庫節點就已經增至幾千套，機房和設備實際上已成為一個瓶頸，再這么玩兒下去機房容量不足了，所以必須提升資源的使用效率。
我行新建應用時，一般都會進行1-3年的一個超前規劃，業界也是同樣的做法，為了穩定運行，避免出現資源瓶頸，基本上提交資源申請時，都選擇物理機。但是大規模的申請物理機，而當前應用的交易量又無法達標，所以資源浪費非常嚴重。
根據評測，相較Oracle，MySQL數據庫實例單體性能容量較小，數據容量普遍小于500G，同時超過一定容量的就要進行分庫，但是一臺物理機部署1個數據庫的方式并未發生變化，MySQL的服務器資源密度較低；同時運維效率低，在服務器、存儲、網絡等基礎設施環節的運維和交付仍然需要大量手工操作。
業界普遍的做法就是將MySQL上云，實現云化部署，借助成熟的云體系實現彈性伸縮和動態擴容。工行有個優勢，IAAS和PAAS云處于同業領先地位，有著豐富的經驗積累，為此結合行內對于云戰略的規劃，MySQL上云是一種必然趨勢。
我們提供了MySQL的容器鏡像，提供了一鍵式的環境供給能力，通過上容器把IAAS、PAAS全部打通，支持快速搭建符合行內標準的基礎環境，提升環境支持能力。
工行基于K8S、SDN、IAAS建設持久性的狀態容器運行集群，通過SDN實現容器網絡資源的自動化申請，通過底層擴展K8S實現容器的固定IP，業界一般會采用K8S Operator實現容器的有狀態資源綁定，也包含了固定IP綁定。
保守估計，資源的使用效率至少提升了4到5倍。而且，我們的工作成果也相當喜人，截止當前工行的MySQL云化部署節點已達4300多個。
5、工行實施效果
我們可以看下工行的轉型成效，首先看下數據：
1）我們已實施200多個應用，高災備等級應用占比高達53%。
2）6000多個MySQL節點, 高災備等級應用占比高達87.31%。
3）實施的應用涉及很多核心業務，包括個人、對公、基金以及很多高災備等級應用，大多數為主機下平臺遷移應用，少量應用是從Oracle遷移過來的，因為工行將PLSQL存儲過程用到了極致，所以應用層也因此需要重構。
4）我們通過MySQL支持的核心交易可以達到日均7億的交易量，經歷過雙十一和春節的多重考驗，峰值TPS至少可以達到1.5萬TPS，同時支持橫向擴展，理論上通過擴展設備還可以無限地增加。而如果通過主機想達成這個目標，那么挑戰就會比較大，這就是建摩天大廈和建排屋的區別。
5）通過良好的架構設計，我們可以滿足兩地三中心的架構要求，做到同城RPO=0，RTO<60s。
6）在自主能力方面，初步建立了企業級的基于MySQL的分布式解決的自主能力：首先是分布式框架+MySQL的應用級分布式解決方案，該方案承載了我行很多主機下平臺應用。
其次是基于分布式中間件DBLE（原型為MyCat，后經愛可生公司優化為DBLE，同時我行進行了深度優化和開發）建立數據訪問層，支持應對一些不是很復雜的場景，通過良好設計的分庫分表方案即可滿足需求。
7）在成本方面，我行在主機上的成本投入明顯下降，近幾年我行的業務交易量每年以20%的速度增長，但是主機并沒有進行擴容，投入還逐年降低。商業產品的數據庫的使用不僅實現零增長，還有所下降。從整個經費上來說，有非常大的降幅。
6、典型實施案例：信息輔助服務
介紹一下我行的典型案例：信息輔助系統：
從應用場景分析其需求，需要支持高并發、低延時，日均交易量為2億，交易響應延時要求10ms以內，業務數據量大概20T左右，要求7×24小時的聯機服務，這就對應用的高可用提出了新的要求。
為此，通過統一運維管理平臺，吸納所有節點，實現一鍵式的安裝、版本的升級、參數的配置。
1）設計層面通過分布式數據中間件DBLE，進行分庫分表，規劃了128個分片，并對分片進行了合并部署，雖然相較于阿里的1024分片來說較少，但是我們使用了一致性hash算法，在資源使用上收益很大。
2）DBLE中間件在日間進行聯機服務，夜間進行批量變更，把主機上的一些數據同步下來，減少批量作業對聯機作業的影響。
3）目前我們的高可用架構采用一主三從（1主庫、1本地半同步庫、2同城半同步庫）架構，基于MySQL的半同步復制，實現園區級的RPO=0，通過DBLE中間件和管理平臺聯動完成實現了本地和同城的自動化切換，RPO=0，RTO<60S，完全滿足工行的業務要求。最后補充說明下，為了實現數據庫層面的高可用， DBLE到數據庫的訪問同一配置為實IP。
4）這里我補充下我們高可用的發展史，其實我們對高可用方案進行了持續的優化，同時學習和借鑒互聯網包括分布式數據庫的一些方案，從1主2備，本地1備和同城1備，擴展成1主3備，通過半同步的機制，做到真正的在系統級去保證RPO=0。
5）在異地災備方面。最開始采用磁盤復制實現災備，一方面成本比較高，另一方面是冷備，無法熱切換，RTO至少半個小時以上。所以我們后期用了MySQL異步復制。
在存儲方面采用集中存儲，一套集中存儲上面需要同時支撐上百個MySQL實例，IO性能直接成為瓶頸，為了應對高并發場景時的IO瓶頸，我們直接引入SSD盤，基本上把MySQL的IO瓶頸給解決了。
三、轉型中遇到的各種心酸坑
最后我們說下我行轉型過程中遇到的心酸坑。
其實如果使用過MySQL 5.7的企業，肯定都遇到過相似的問題，比如超過MySQL的默認閑置時間導致的連接超時、dependent subquery導致的語句效率差、字符集亂碼等等，以及MySQL的自身bug，比如Intel PAUSE指令周期的迭代引發MySQL的性能瓶頸。畢竟免費的午餐并不是那么完美，總是會有或多或少的問題需要規避。
我這里說下讓我痛心疾首的幾個心酸坑吧：
坑一：慢SQL數量爆發式增長，應用隱患逐步暴露，在阿里等互聯網公司和我行都是一個痛點，值得大家警醒和重視。我行OLTP之前為Oracle數據庫，借助于Oracle良好的優化器，大家習慣于5張表左右的連接，但是遷移至MySQL后，習慣沒有及時轉換過來，一個慢SQL可能就導致服務不可用，降低用戶幸福指數。為此我們規劃了3個方面的改善措施：
1）設計層面制定了規范，強調數據設計的合理性，組織DBA進行內部復核，提前規避設計問題，比如3NF、BCNF的設計遵循、可控性冗余處理（空間換時間或時間環空）等等，通過輔助工具的自動化手段，從源頭扼殺風險。
2）開發層面我們基于Sonar開發了自動化檢查工具，支持分析mapper文件，既然開發人員沒空看規范，那我們工具輔助，增加質量門禁，強制將規范融合至開發過程中，進一步降低風險。但是對新人可能不友好，以前看到一個新人的朋友圈的哭訴，被質量門禁卡的無法提交代碼，一直苦逼的加班整改。
3)運維層面我們建立了SRE平臺，監測慢SQL語句，并分批次要求整改，將結果都擺在臺面上，真的不是我們不給力，而是應用開發不給力啊。
坑二：在MySQL 5.7中，表的TRUNCATE操作存在bug，對應編號68184，會阻塞整個數據庫實例上的所有其他交易，所以對大表進行TRUNCATE操作會影響整個MySQL數據庫的處理性能，即使是訪問不想關的表也會收到影響。
此時你就會收到一群開發人員的請求，哎呀，數據庫夯住了，求救啊，實際上解決方案也很簡單，因為Drop語句不受影響，所以映射為DROP+CREATE的操作即可規避該bug，而MySQL 8.0也將其進行了同樣的映射。所以我們將其固化到設計開發規范中，提醒相關人員進行注意，同時在工具中增加TRUNCATE關鍵字識別檢查，做到提前預防。
坑三：MySQL的超時中斷，wait_timeout參數，即MySQL客戶端的數據庫連接閑置最大時間值（秒），我行設置為1小時，如果長連接的空閑時間超過該參數設置時間，數據庫連接就會被MySQL主動斷開，而中間件的連接池的連接就處于“假活“狀態，一般的建議方法就是增加心跳監測，使用dbcp設置testWhileIdle、validationQuery等參數，如果跟我行一樣使用WAS的，在WAS控制臺上設置時效超時的參數即可。
坑四：Replce Into引發的自增列主鍵沖突bug，對應編號73563，主庫在執行replace操作時，如果有數據沖突，會轉換為一筆delete+一筆insert，所以主庫無問題，但是binglog記錄的為update操作，備庫重做update動作，更新主鍵，但由于update動作不會更新自增列值，導致更新后記錄值大于自增列值。
當此時發生主備切換時，備庫提升為主庫，插入的自增列主鍵會取自增列的值，從而引發主鍵沖突。解決方案也屬于應急方案，可以在發生問題時，通過ALTER語句將自增列增加；另一種解決方案，可以在replace into之后開啟一個新的事務，插入一條無意義的記錄然后刪除掉，可以保證主備一致；最后一種解決方案，是直接用雪花算法計算遞增序列號。
以上就是我的分享，謝謝。
