今天分享的主題是工行“去 O”數(shù)據(jù)庫選型與分布式架構(gòu)設(shè)計。

[[330692]]

圖片來自 Pexels

本次分享分為三個章節(jié)：

• 金融行業(yè)的需求核心與策略
• 工行數(shù)據(jù)庫選型的發(fā)展歷程，即方案選型歷程
• 轉(zhuǎn)型中遇到的各種心酸坑

金融行業(yè)的核心需求與策略

傳統(tǒng) IT 架構(gòu)挑戰(zhàn)

大家可能都知道，工行最早是基于 IBM 大型主機搭建的核心系統(tǒng)，以及基于 Oracle 和 IBM WAS 搭建的 OLTP 系統(tǒng)，在分布式體系大熱之前處于同業(yè)領(lǐng)先地位。

當(dāng)然現(xiàn)在也是處于同業(yè)領(lǐng)先的，但是科技成本也相對較高，所謂的一份價錢一分貨就是這個道理。

 

但是隨著分布式技術(shù)的成熟，傳統(tǒng)的 IT 架構(gòu)面臨著四大挑戰(zhàn)：

①從處理能力層面來看，傳統(tǒng)應(yīng)用(也叫巨石型應(yīng)用)系統(tǒng)規(guī)模龐大，采用集中式架構(gòu)設(shè)計，使用單一系統(tǒng)垂直擴展模式，擴展能力相對來說是有限的。

另一方面，大數(shù)據(jù)時代引發(fā)海量數(shù)據(jù)分析處理和存儲處理的問題，對擴展性、可靠性和吞吐量提出了較高要求。

②從運行風(fēng)險層面來看，客戶對金融行業(yè)的系統(tǒng)有著更高的業(yè)務(wù)連續(xù)性保障要求，對不可用問題實際上是零容忍的，比如要求 7*24 小時業(yè)務(wù)不能中斷。

③從快速交付層面來看，傳統(tǒng)巨石型應(yīng)用實際上與快速交付是相悖的，應(yīng)用內(nèi)部模塊、應(yīng)用與應(yīng)用之間耦合度高，使得軟件開發(fā)和產(chǎn)品服務(wù)交付周期長，無法滿足業(yè)務(wù)快速上線的需求，從而逐漸泯然眾人矣，淹沒在茫茫的金融行業(yè)洪流中。

大家可以看到不論是金融科技還是科技金融，一大堆的金融公司已經(jīng)淹沒在前浪里。

④從成本控制來看，大型主機運營費用昂貴，商業(yè)產(chǎn)品 License 費用高，買個機器和服務(wù)隨隨便便就幾千萬上億的支出，真的是太貴了，所以隨著業(yè)務(wù)系統(tǒng)做大做強，產(chǎn)品成本可能會成為壓死駱駝的最后一根稻草。

為此，我們可以首先得出三點需求：

• 應(yīng)該優(yōu)化應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)。
• 應(yīng)該建設(shè)靈活開放、高效協(xié)同、安全穩(wěn)定的 IT 架構(gòu)體系。
• 能夠強化對業(yè)務(wù)快速創(chuàng)新發(fā)展的科技支撐。

雙十一壓力

說到這里，就不得不吐槽阿里的“雙十一”，將購買壓縮到一天，對顧客和金融系統(tǒng)來說造成雙重壓力，相較而言，京東的 618 就比較人性化，每天都可以剁手。

我們可以看下雙十一的峰值變化情況，從 2009 年開始，峰值只有 400 筆/秒，相較主機而言，有很大的差距，當(dāng)然這也與他們當(dāng)時的名氣小有關(guān)。

 

但是 2015 年開始，借著云化和分布式的大旗，以及當(dāng)時 BAT 的領(lǐng)頭羊地位，僅 4 年時間，就從 2015 年的 14 萬筆/秒迅速攀升至 2019 年的 54 萬 4 千筆/秒。

這就給金融行業(yè)的系統(tǒng)建設(shè)帶來了四個問題：

①高并發(fā)問題，我們可以看到，阿里為了提升峰值，做了大量的緩存，鼓勵使用花唄，降低與外系統(tǒng)的交互，但是依然對金融行業(yè)產(chǎn)生額外的壓力。

②高可靠性要求，確保系統(tǒng)穩(wěn)定可靠，客戶可以穩(wěn)定支付成功，避免因不佳的客戶體現(xiàn)導(dǎo)致用戶流失。

③高成本壓力，大幅擴容的設(shè)備，以及隨之產(chǎn)生的運維成本，以及昂貴的商業(yè) liscence，給金融行業(yè)帶來一定的成本負擔(dān)。

④同業(yè)競爭要求，大家都在做競品分析，和同行進行比較，所以別人 ok，你掛了，你面子上還掛的住么，所以各機構(gòu)在雙十一前進行大量的模擬測試，類似于高考前的黑暗日子。

金融行業(yè)分布式的核心訴求及策略

為此，金融行業(yè)分布式的核心訴求及策略可以總結(jié)為以下五點：

 

①應(yīng)該具備企業(yè)級的業(yè)務(wù)支撐能力，支持高并發(fā)、可擴展和海量數(shù)據(jù)庫存儲及訪問;原則上應(yīng)支持同城雙活，實現(xiàn)集中式向分布式的轉(zhuǎn)型。工行的兩地三中心容災(zāi)體系在國有大型銀行中屬于第一梯隊。

②應(yīng)能大幅降低使用成本，可以基于通用的廉價的 X86 硬件基礎(chǔ)設(shè)施;降低商業(yè)產(chǎn)品依賴，擁抱開源產(chǎn)品，互聯(lián)網(wǎng)企業(yè)已經(jīng)給我們做了一個很好的參考。

③應(yīng)該提升數(shù)據(jù)庫的運維自動化和智能化能力，支持與自身系統(tǒng)進行適配性定制，工行即實現(xiàn)了行內(nèi)系統(tǒng)適配定制。

④金融行業(yè)還應(yīng)考慮到社會聲譽性要求，客戶對金融行業(yè)的期望很高，特別是對銀行等金融組織，所以要求也更加嚴格，原則上應(yīng)該是 7*24 小時的不間斷服務(wù)。

像當(dāng)年支付寶在 2015 年的支付癱瘓事件僅僅上了下熱搜，但是 2013 年工行因為 IBM 主機 Bug 的問題卻上了新聞聯(lián)播，這就是所謂的愛之深責(zé)之切吧。

⑤要考慮到政治因素風(fēng)險，雖然全球化要求技術(shù)無國界，但是從去年開始的貿(mào)易戰(zhàn)，以及美國的實體管制清單，我們可以看到技術(shù)是有國界的。

近期 HashiCorp 發(fā)布公告，其企業(yè)版產(chǎn)品禁止中國使用已經(jīng)引發(fā)了一種擔(dān)憂。說起 HashCorp ，大家可能不一定熟悉，但是其旗下有大名鼎鼎的產(chǎn)品 Consul，可以簡化分布式環(huán)境中的服務(wù)注冊與發(fā)現(xiàn)流程，大家一定耳熟能詳。

最后中國人民銀行在 2019 年 8 月 23 日發(fā)布了《金融科技(FinTech)發(fā)展規(guī)劃(2019-2021)》中提到“做好分布式數(shù)據(jù)庫金融應(yīng)用的長期規(guī)劃，加大研發(fā)與應(yīng)用投入力度，妥善解決分布式數(shù)據(jù)庫產(chǎn)品在數(shù)據(jù)一致性、實際場景驗證、遷移保障規(guī)范、新型運維體系等方面的問題，這也給金融行業(yè)指明了方向。

選型的發(fā)展歷程(方案選型歷程)

接下來，給大家介紹下如何選型以及工行的選型歷程。

工行分布式轉(zhuǎn)型發(fā)展歷程

大家可以看下工行分布式的發(fā)展歷程：

 

其大致可分為 2 個關(guān)鍵階段，2016 年初-2017 年末為基礎(chǔ)研究及試點階段，之后為轉(zhuǎn)型實施及推廣階段。

大致有如下五個關(guān)鍵時點：

• 2016 年初工行進行分布式體系研究，建立了基于 Dubbo 框架的分布式生態(tài)服務(wù)。
• 2016 年底借著人民銀行對于個人賬戶的管理要求，實行三類賬戶的場景，開始了基于分布式的 OLTP 數(shù)據(jù)庫研究，并確定了基于開源 MySQL 的 OLTP 數(shù)據(jù)庫解決方案，因為 MySQL 8.0 的不成熟，所以我們采用了 MySQL 5.7。
• 2017 年末，我們完成開源 MySQL 初步能力體系的建設(shè)，涵蓋了基礎(chǔ)研究、配套方法論、應(yīng)用試點等等。
• 2018 年開始大規(guī)模的實施和推廣，我們逐步建立企業(yè)級的數(shù)據(jù)庫服務(wù)能力，包括引入了分布式的中間件，在高可用、運維能力的提升，資源使用率的提升，MySQL 上云及自主服務(wù)的建設(shè)等等，同時開啟了對 OLTP 的分布式數(shù)據(jù)庫進行了研究。
• 2019 年 11 月我們實現(xiàn)了國產(chǎn)分布式數(shù)據(jù)庫產(chǎn)品 GaussDB 試點上線。

方案選型調(diào)研

大家可以看下工行的選型過程，希望可以給大家?guī)硪欢ǖ膮⒖迹?/p>

 

工行的技術(shù)規(guī)劃是相當(dāng)嚴謹?shù)模援?dāng)時我們從五個層次進行了考量：OLTP 分布式數(shù)據(jù)庫、NewSQL 數(shù)據(jù)庫、支持分布式架構(gòu)、自主可控、開源抑或商業(yè)。

當(dāng)時我們的第一個疑問是，到底是選 NoSQL、NewSQL 還是關(guān)系型數(shù)據(jù)庫。

當(dāng)時 MongoDB、Redis、Cassandra、HBASE 等 NoSQL 數(shù)據(jù)庫開始在某些場景下大熱，但是可用場景不滿足我們的 OLTP 業(yè)務(wù)場景需求。

NewSQL 隨著 Google 的 Spanner 和 F1 開始進入大家的視野，但是國內(nèi)可以考據(jù)的只有相關(guān)的 paper;國產(chǎn)的 TiDB 也是小荷初露尖尖角，但是畢竟還是幼兒期。

而 DB-Egines 發(fā)布的《2016 年全球數(shù)據(jù)庫大盤點》，Oracle、MySQL 和 SQL Server 三大數(shù)據(jù)庫產(chǎn)品遙遙領(lǐng)先。

MySQL 當(dāng)時在互聯(lián)網(wǎng)公司的名氣是越來越響，谷歌、淘寶、百度、騰訊、豆瓣、網(wǎng)易、臉書等都使用了 MySQL。

一方面 MySQL 提供了免費版，另一方面 Oracle 收購 Sun 后，可以很明顯的看到 MySQL 越來越規(guī)范，5.5、5.6、5.7 均可以看到很明顯的提升，5.7 號稱性能是 5.6 的 3 倍，5.6 號稱是 5.5 的 2 倍。

為此，我們經(jīng)過謹慎的驗證，選取了 MySQL 作為分布式數(shù)據(jù)庫的第一選型，畢竟業(yè)界有很多豐富的案例。

而且在互聯(lián)網(wǎng)企業(yè)里面得到了很好的實踐，在業(yè)界資源案例和周邊產(chǎn)品都很豐富，能應(yīng)對我行的高并發(fā)、彈性擴展需求。

同時其具有如下特點：

• 開源，基于 GPL(GNU 通用許可證)可以免費使用修改，當(dāng)時很多公司都基于 MySQL 進行了深入定制，但是在與他們的交流過程中，發(fā)現(xiàn)版本歸并真的是一種夢魘。
• 高可用，具有優(yōu)秀的架構(gòu)設(shè)計及相當(dāng)豐富的周邊產(chǎn)品，實現(xiàn)了企業(yè)級的高可用性和高擴展性。
• 免費，有效降低企業(yè)運行成本。
• 趨勢，產(chǎn)品成熟度、排名一直遙遙領(lǐng)先，占行業(yè)應(yīng)用的比重增大，產(chǎn)業(yè)鏈豐富，從業(yè)人員有規(guī)模效應(yīng)。

然后我們選擇了 MySQL 5.7，其相較之前的版本有六個優(yōu)點：

• InnoDB 增強，在線修改 ibp，快速擴展 VARCHAR，UNDO 可回收，可關(guān)閉死鎖檢測。
• 復(fù)制增強，多源復(fù)制，基于 WRITESET 的并行復(fù)制，增強半同步，在線設(shè)置 repl filter。
• 優(yōu)化器增強，幾乎重構(gòu)優(yōu)化器，EXPLAIN 增強，引入 Optimizer Hints。
• 安全性增強，新增密碼過期機制，支持賬號鎖定等。
• 功能增強，默認開啟 PFS，新增 sys schema 等。
• 其他增強，支持多個觸發(fā)器，新增 Query Rewrite，支持設(shè)置 SQL 執(zhí)行最長時間。

方案技術(shù)棧

 

基于 MySQL 選型，還應(yīng)考慮一系列的分布式架構(gòu)技術(shù)棧，包括分布式服務(wù)、分布式事務(wù)框架、分布式批量框架、分布式緩存、交易數(shù)據(jù)核對及補償、分布式消息、配置中心、開發(fā)及運維管理。

這里提醒下大家，在選型上沒有最好的產(chǎn)品，只有最適合自己的產(chǎn)品：

①分布式事務(wù)，業(yè)界實際上有多種解決方案，2PC(2 階段式事務(wù)提交)、3PC、TCC 和 SAGA 模型等等，我們這 4 種方案我行都有應(yīng)用在使用，互為補充，滿足不同業(yè)務(wù)場景對事務(wù)強一致性或最終一致性的要求。

②業(yè)務(wù)層面，在交易或者應(yīng)用級層面進行數(shù)據(jù)核對及補償，有些場景就是在傳統(tǒng)的 OLTP 的情況下，也會對應(yīng)用上下游進行核對和補償。

③分布式消息，我們選取了 Kafka 作為分布式消息中間件。

④分布式批量框架，在大規(guī)模的數(shù)據(jù)結(jié)點上進行批量操作的一個整體的解決方案。

⑤運維層面，我行建立了統(tǒng)一的運維管理平臺，納入所有數(shù)據(jù)庫節(jié)點，實現(xiàn)一鍵式的數(shù)據(jù)庫安裝、版本升級、基線參數(shù)配置等等。并且實現(xiàn)了多種高可用策略配置，包括自動、人工一鍵式切換。

為什么要有自動化和人工的兩種切換方式?這里我要解釋下，一種新的事務(wù)上線之前，都會面臨一些挑戰(zhàn)和懷疑的，都是一個循序漸進的過程，特別是是在金融行業(yè)，自動真的好么?萬一搞錯了怎么辦?決策因素和模型是否設(shè)計正確?設(shè)計正確了是否編碼正確?

最難的是還要應(yīng)對不同應(yīng)用場景的需求，有的應(yīng)用要求 RPO 優(yōu)先，有的應(yīng)用又要求 RTO 優(yōu)先。

我們之前經(jīng)過充分調(diào)研，預(yù)見到該種情況，所以我們提供了多種高可用策略的靈活配置，以便滿足不同應(yīng)用的個性化要求。

我們的高可用整體上面基于 MySQL 的復(fù)制技術(shù)，通過半同步復(fù)制和多數(shù)派共識機制實現(xiàn)冗余備份，基于 MySQL binlog 日志實現(xiàn)自動數(shù)據(jù)補全，保障數(shù)據(jù)的一致性。

其他考量

除此以外，數(shù)據(jù)庫選型后，還應(yīng)完善相關(guān)體系，規(guī)范設(shè)計、開發(fā)、測試和運維，實現(xiàn)管控的體系化和自動化，才能避免眼高手低，減少生產(chǎn)安全風(fēng)險。

 

①在設(shè)計層面，在驗證功能、新特性和配置基線，數(shù)據(jù)備份恢復(fù)的基礎(chǔ)上，我們參考了愛可生、阿里等公司的規(guī)約，建立了 MySQL 設(shè)計指引，可以說，我們是站在巨人的肩膀上成長的。

加強元數(shù)據(jù)管理，提出元數(shù)據(jù)完備性、明確性、具象性和前瞻性的要求，建立應(yīng)用的元數(shù)據(jù)標準，統(tǒng)一數(shù)據(jù)架構(gòu)設(shè)計，架構(gòu)師設(shè)計表結(jié)構(gòu)時均基于元數(shù)據(jù)進行設(shè)計，提升數(shù)據(jù)架構(gòu)質(zhì)量。

此外，我們還開發(fā)了表結(jié)構(gòu)設(shè)計工具，將其融合在 Excel 中，實現(xiàn)對元數(shù)據(jù)的自動應(yīng)用，支持自動生成腳本，簡化架構(gòu)師的貫標操作，將人員成熟度的要求降至最低，提升設(shè)計效能和質(zhì)量。

②在開發(fā)層面，我們制訂了開發(fā)規(guī)范和 SQL 調(diào)優(yōu)指引，同時基于 sonar 開發(fā)了 MySQL 檢查工具，支持對基于 myBatis 的 mapper 文件進行解析，提前發(fā)現(xiàn) SQL 不規(guī)范的寫法。

同時將 sonarlint 插件納入開發(fā)人員必備插件，實現(xiàn)規(guī)則的云化部署和本地聯(lián)動掃描分析，將規(guī)范融入開發(fā)過程中，提升開發(fā)人員的 SQL 編寫能力。

③在測試層面，我們自研壓力測試服務(wù)平臺，盡量減少性能瓶頸，提前發(fā)現(xiàn) SQL 性能問題。

④在運維層面，感覺應(yīng)該是最重要的一個層面，我們需要考慮自動化部署、監(jiān)控告警、故障分析、自動巡檢以及 SRE 平臺，還有數(shù)據(jù)遷移、備份恢復(fù)、配置管理、版本升級、多租戶等等。

隨著節(jié)點的增加，運維實際上是一個很大的挑戰(zhàn)，幾千幾萬個節(jié)點，安裝、監(jiān)控、報警、故障、人工處理等非常麻煩。

必須要實現(xiàn)自動化的安裝部署，進行批量安裝部署，同時批量串行還不行，時間太長了，要并行，并行太高了，網(wǎng)絡(luò)的流量又會受到很大的影響，所以很多場景都需要細細打磨，還要按照博弈論的思路建立納什均衡。

監(jiān)控告警里有事件等級，如何劃分各種等級，都需要靈活定制支持，建立基線告警，建立應(yīng)急流程。

像華為等公司都有基于設(shè)備的網(wǎng)絡(luò)拓撲圖，問題在哪個節(jié)點，可以快速分析和定位，所以說運維是一個很麻煩的事情，像故障分析，完善日志記錄、采集和分析，建立故障分析規(guī)范。

自動巡檢，自動化的巡檢和評分報告，對實例狀態(tài)進行健康評分。在這個階段我們實現(xiàn)了同城 RPO=0，RTO=分鐘級目標，RPO 為 0 的切換，問題可監(jiān)控，實現(xiàn)了人工或自動的一鍵式切換。

最后我們不得不提到 SRE，很多人會聯(lián)想到運維工程師、系統(tǒng)工程師，其實不然，SRE 本質(zhì)上仍然是軟件工程師。

SRE 最早在十多年前 Google 提出并應(yīng)用，近幾年逐步在國內(nèi)外 TOP 互聯(lián)網(wǎng)公司都開始廣泛應(yīng)用。

其中 Google 締造了 SRE，并奠定了其權(quán)威的地位，而 Netflix 將 SRE 的實踐做到了極致，Netflix 僅有的個位數(shù)的 Core SRE 支持了 190 個國家、數(shù)億用戶、數(shù)萬微服務(wù)實例業(yè)務(wù)規(guī)模的運維。

像數(shù)據(jù)庫瓶頸，頂配數(shù)據(jù)庫空間仍然無法支撐業(yè)務(wù)半年發(fā)展;慢 SQL 數(shù)量爆發(fā)式增長，應(yīng)用穩(wěn)定性岌岌可危;人工運維風(fēng)險極高;人工運維頻率高，研發(fā)幸福感下降這些大家都會遇到的問題也會逐漸地遇到。

他山之石，可以攻玉，我們完全可以把別人的挫折拿過來，避免自己走彎路。

MySQL 上云

在逐步推進的過程中，完善選型體系建設(shè)后，為了確保資源的有效利用，上云實際上是一種必然的選擇。

從工行來看，經(jīng)歷 1-2 年的發(fā)展，MySQL 數(shù)據(jù)庫節(jié)點就已經(jīng)增至幾千套，機房和設(shè)備實際上已成為一個瓶頸，再這么玩兒下去機房容量不足了，所以必須提升資源的使用效率。

 

我行新建應(yīng)用時，一般都會進行 1-3 年的一個超前規(guī)劃，業(yè)界也是同樣的做法，為了穩(wěn)定運行，避免出現(xiàn)資源瓶頸，基本上提交資源申請時，都選擇物理機。

但是大規(guī)模的申請物理機，而當(dāng)前應(yīng)用的交易量又無法達標，所以資源浪費非常嚴重。

根據(jù)評測，相較 Oracle，MySQL 數(shù)據(jù)庫實例單體性能容量較小，數(shù)據(jù)容量普遍小于 500G，同時超過一定容量的就要進行分庫，但是一臺物理機部署 1 個數(shù)據(jù)庫的方式并未發(fā)生變化，MySQL 的服務(wù)器資源密度較低。

同時運維效率低，在服務(wù)器、存儲、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施環(huán)節(jié)的運維和交付仍然需要大量手工操作。

業(yè)界普遍的做法就是將 MySQL 上云，實現(xiàn)云化部署，借助成熟的云體系實現(xiàn)彈性伸縮和動態(tài)擴容。

工行有個優(yōu)勢，IAAS 和 PAAS 云處于同業(yè)領(lǐng)先地位，有著豐富的經(jīng)驗積累，為此結(jié)合行內(nèi)對于云戰(zhàn)略的規(guī)劃，MySQL 上云是一種必然趨勢。

我們提供了 MySQL 的容器鏡像，提供了一鍵式的環(huán)境供給能力，通過上容器把 IAAS、PAAS 全部打通，支持快速搭建符合行內(nèi)標準的基礎(chǔ)環(huán)境，提升環(huán)境支持能力。

工行基于 K8S、SDN、IAAS 建設(shè)持久性的狀態(tài)容器運行集群，通過 SDN 實現(xiàn)容器網(wǎng)絡(luò)資源的自動化申請，通過底層擴展 K8S 實現(xiàn)容器的固定 IP，業(yè)界一般會采用 K8S Operator 實現(xiàn)容器的有狀態(tài)資源綁定，也包含了固定 IP 綁定。

保守估計，資源的使用效率至少提升了 4 到 5 倍。而且，我們的工作成果也相當(dāng)喜人，截止當(dāng)前工行的 MySQL 云化部署節(jié)點已達 4300 多個。

工行實施效果

我們可以看下工行的轉(zhuǎn)型成效，首先看下數(shù)據(jù)：

 

①我們已實施 200 多個應(yīng)用，高災(zāi)備等級應(yīng)用占比高達 53%。

②6000 多個 MySQL 節(jié)點，高災(zāi)備等級應(yīng)用占比高達 87.31%。

③實施的應(yīng)用涉及很多核心業(yè)務(wù)，包括個人、對公、基金以及很多高災(zāi)備等級應(yīng)用，大多數(shù)為主機下平臺遷移應(yīng)用，少量應(yīng)用是從 Oracle 遷移過來的，因為工行將 PLSQL 存儲過程用到了極致，所以應(yīng)用層也因此需要重構(gòu)。

④我們通過 MySQL 支持的核心交易可以達到日均 7 億的交易量，經(jīng)歷過雙十一和春節(jié)的多重考驗，峰值 TPS 至少可以達到 1.5 萬 TPS，同時支持橫向擴展，理論上通過擴展設(shè)備還可以無限地增加。

而如果通過主機想達成這個目標，那么挑戰(zhàn)就會比較大，這就是建摩天大廈和建排屋的區(qū)別。

⑤通過良好的架構(gòu)設(shè)計，我們可以滿足兩地三中心的架構(gòu)要求，做到同城 RPO=0，RTO<60s。

⑥在自主能力方面，初步建立了企業(yè)級的基于 MySQL 的分布式解決的自主能力：首先是分布式框架+MySQL 的應(yīng)用級分布式解決方案，該方案承載了我行很多主機下平臺應(yīng)用。

其次是基于分布式中間件 DBLE(原型為 MyCat，后經(jīng)愛可生公司優(yōu)化為 DBLE，同時我行進行了深度優(yōu)化和開發(fā))建立數(shù)據(jù)訪問層，支持應(yīng)對一些不是很復(fù)雜的場景，通過良好設(shè)計的分庫分表方案即可滿足需求。

⑦在成本方面，我行在主機上的成本投入明顯下降，近幾年我行的業(yè)務(wù)交易量每年以 20% 的速度增長，但是主機并沒有進行擴容，投入還逐年降低。

商業(yè)產(chǎn)品的數(shù)據(jù)庫的使用不僅實現(xiàn)零增長，還有所下降。從整個經(jīng)費上來說，有非常大的降幅。

典型實施案例：信息輔助服務(wù)

介紹一下我行的典型案例：信息輔助系統(tǒng)。

從應(yīng)用場景分析其需求，需要支持高并發(fā)、低延時，日均交易量為 2 億，交易響應(yīng)延時要求 10ms 以內(nèi)，業(yè)務(wù)數(shù)據(jù)量大概 20T 左右，要求 7×24 小時的聯(lián)機服務(wù)，這就對應(yīng)用的高可用提出了新的要求。

 

為此，通過統(tǒng)一運維管理平臺，吸納所有節(jié)點，實現(xiàn)一鍵式的安裝、版本的升級、參數(shù)的配置。

①設(shè)計層面通過分布式數(shù)據(jù)中間件 DBLE，進行分庫分表，規(guī)劃了 128個 分片，并對分片進行了合并部署，雖然相較于阿里的 1024 分片來說較少，但是我們使用了一致性 hash 算法，在資源使用上收益很大。

②DBLE 中間件在日間進行聯(lián)機服務(wù)，夜間進行批量變更，把主機上的一些數(shù)據(jù)同步下來，減少批量作業(yè)對聯(lián)機作業(yè)的影響。

③目前我們的高可用架構(gòu)采用一主三從(1 主庫、1 本地半同步庫、2 同城半同步庫)架構(gòu)，基于 MySQL 的半同步復(fù)制，實現(xiàn)園區(qū)級的 RPO=0。

通過 DBLE 中間件和管理平臺聯(lián)動完成實現(xiàn)了本地和同城的自動化切換，RPO=0，RTO<60S，完全滿足工行的業(yè)務(wù)要求。

最后補充說明下，為了實現(xiàn)數(shù)據(jù)庫層面的高可用， DBLE 到數(shù)據(jù)庫的訪問同一配置為實 IP。

④這里我補充下我們高可用的發(fā)展史，其實我們對高可用方案進行了持續(xù)的優(yōu)化。

同時學(xué)習(xí)和借鑒互聯(lián)網(wǎng)包括分布式數(shù)據(jù)庫的一些方案，從 1 主 2 備，本地 1 備和同城 1 備，擴展成 1 主 3 備，通過半同步的機制，做到真正的在系統(tǒng)級去保證 RPO=0。

⑤在異地災(zāi)備方面。最開始采用磁盤復(fù)制實現(xiàn)災(zāi)備，一方面成本比較高，另一方面是冷備，無法熱切換，RTO 至少半個小時以上。所以我們后期用了 MySQL 異步復(fù)制。

在存儲方面采用集中存儲，一套集中存儲上面需要同時支撐上百個 MySQL 實例，IO 性能直接成為瓶頸，為了應(yīng)對高并發(fā)場景時的 IO 瓶頸，我們直接引入 SSD 盤，基本上把 MySQL 的 IO 瓶頸給解決了。

轉(zhuǎn)型中遇到的各種心酸坑

最后我們說下我行轉(zhuǎn)型過程中遇到的心酸坑。

其實如果使用過 MySQL 5.7 的企業(yè)，肯定都遇到過相似的問題，比如超過 MySQL 的默認閑置時間導(dǎo)致的連接超時、dependent subquery 導(dǎo)致的語句效率差、字符集亂碼等等。

以及 MySQL 的自身 Bug，比如 Intel PAUSE 指令周期的迭代引發(fā) MySQL 的性能瓶頸。

畢竟免費的午餐并不是那么完美，總是會有或多或少的問題需要規(guī)避。

 

我這里說下讓我痛心疾首的幾個心酸坑吧：

坑一：慢 SQL 數(shù)量爆發(fā)式增長，應(yīng)用隱患逐步暴露，在阿里等互聯(lián)網(wǎng)公司和我行都是一個痛點，值得大家警醒和重視。

我行 OLTP 之前為 Oracle 數(shù)據(jù)庫，借助于 Oracle 良好的優(yōu)化器，大家習(xí)慣于 5 張表左右的連接，但是遷移至 MySQL 后，習(xí)慣沒有及時轉(zhuǎn)換過來，一個慢 SQL 可能就導(dǎo)致服務(wù)不可用，降低用戶幸福指數(shù)。

為此我們規(guī)劃了三個方面的改善措施：

①設(shè)計層面制定了規(guī)范，強調(diào)數(shù)據(jù)設(shè)計的合理性，組織 DBA 進行內(nèi)部復(fù)核，提前規(guī)避設(shè)計問題，比如 3NF、BCNF 的設(shè)計遵循、可控性冗余處理(空間換時間或時間環(huán)空)等等，通過輔助工具的自動化手段，從源頭扼殺風(fēng)險。

②開發(fā)層面我們基于 Sonar 開發(fā)了自動化檢查工具，支持分析 mapper 文件，既然開發(fā)人員沒空看規(guī)范，那我們工具輔助，增加質(zhì)量門禁，強制將規(guī)范融合至開發(fā)過程中，進一步降低風(fēng)險。

但是對新人可能不友好，以前看到一個新人的朋友圈的哭訴，被質(zhì)量門禁卡的無法提交代碼，一直苦逼的加班整改。

③運維層面我們建立了 SRE 平臺，監(jiān)測慢 SQL 語句，并分批次要求整改，將結(jié)果都擺在臺面上，真的不是我們不給力，而是應(yīng)用開發(fā)不給力啊。

坑二：在 MySQL 5.7 中，表的 TRUNCATE 操作存在 Bug，對應(yīng)編號 68184，會阻塞整個數(shù)據(jù)庫實例上的所有其他交易。

所以對大表進行 TRUNCATE 操作會影響整個 MySQL 數(shù)據(jù)庫的處理性能，即使是訪問不想關(guān)的表也會收到影響。

此時你就會收到一群開發(fā)人員的請求，哎呀，數(shù)據(jù)庫夯住了，求救啊，實際上解決方案也很簡單，因為 Drop 語句不受影響，所以映射為 DROP+CREATE 的操作即可規(guī)避該 Bug，而 MySQL 8.0 也將其進行了同樣的映射。

所以我們將其固化到設(shè)計開發(fā)規(guī)范中，提醒相關(guān)人員進行注意，同時在工具中增加 TRUNCATE 關(guān)鍵字識別檢查，做到提前預(yù)防。

坑三：MySQL 的超時中斷，wait_timeout 參數(shù)，即 MySQL 客戶端的數(shù)據(jù)庫連接閑置最大時間值(秒)，我行設(shè)置為 1 小時。

如果長連接的空閑時間超過該參數(shù)設(shè)置時間，數(shù)據(jù)庫連接就會被 MySQL 主動斷開，而中間件的連接池的連接就處于“假活“狀態(tài)。

一般的建議方法就是增加心跳監(jiān)測，使用 dbcp 設(shè)置 testWhileIdle、validationQuery 等參數(shù)，如果跟我行一樣使用 WAS 的，在 WAS 控制臺上設(shè)置時效超時的參數(shù)即可。

坑四：Replce Into 引發(fā)的自增列主鍵沖突 Bug，對應(yīng)編號 73563，主庫在執(zhí)行 replace 操作時，如果有數(shù)據(jù)沖突，會轉(zhuǎn)換為一筆 delete+一筆 insert。

所以主庫無問題，但是 binglog 記錄的為 update 操作，備庫重做 update 動作，更新主鍵，但由于 update 動作不會更新自增列值，導(dǎo)致更新后記錄值大于自增列值。

當(dāng)此時發(fā)生主備切換時，備庫提升為主庫，插入的自增列主鍵會取自增列的值，從而引發(fā)主鍵沖突。

解決方案也屬于應(yīng)急方案，可以在發(fā)生問題時，通過 ALTER 語句將自增列增加。

另一種解決方案，可以在 replace into 之后開啟一個新的事務(wù)，插入一條無意義的記錄然后刪除掉，可以保證主備一致。

最后一種解決方案，是直接用雪花算法計算遞增序列號。

作者：魏亞東

簡介：中國工商銀行軟件開發(fā)中心三級經(jīng)理，資深架構(gòu)師。杭州研發(fā)部數(shù)據(jù)庫專家牽頭人和開發(fā)中心安全團隊成員，負責(zé)技術(shù)管理、數(shù)據(jù)庫和安全相關(guān)工作。2009 年加入中國工商銀行軟件開發(fā)中心，致力于推動管理創(chuàng)新、效能提升，提供全面技術(shù)管控，推動自動化實施，實現(xiàn)業(yè)務(wù)價值的高質(zhì)量快速交付;同時作為技術(shù)專家，為生產(chǎn)安全提供技術(shù)支持。

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號 DBAplus 社群(ID：dbaplus)，本文根據(jù)魏亞東老師在〖deeplus 直播第 225 期〗線上分享演講內(nèi)容整理而成。