本文根據王順老師在〖deeplus直播：適配金融行業的資料庫運維演進之路〗線上分享演講內容整理而成。（文末有回放及PPT獲取方式，不要錯過）
分享概要
一、資料庫架構建設的基本方法和過程
二、某核心系統由大型電腦系統遷移到分布式架構
三、Redis異地容災架構建設
一、資料庫架構建設的基本方法和過程
1、資料庫架構組成
1）資料庫架構
在日常工作中，如果我們說到資料庫架構，一般來說指的是網路、主機、儲存及之上執行的資料庫例項。資料庫架構工作指的則是如何去評估和組合這些元件，從而為業務提供符合營運要求的資料庫服務。
2）資料庫存取元件
當資料庫架構演進到分布式架構，如何讓應用程式（服務）快速確認數據所在的位置，就成為了一個核心的問題，而這就是資料庫存取元件的工作。
3）資料庫營運平台
對於一個大型組織，營運幾千套、幾萬套資料庫例項是很平常的事情，而這也給營運團隊的日常管理帶來了一定難度的挑戰。各個公司組織紛紛搭建營運平台，用於告警監控、故障處理、變更、版本釋出等，在設計和構建資料庫架構的同時建設資料庫營運平台已經成為了一種標準操作。
2、可營運及需求的組成
1）業務需求
資料庫架構首先要匹配組織的業務流程，滿足組織的業務需求，是所有從業者的共識。
2）營運需求
設計和構建資料庫架構的最終目標就是獲得一個能夠持續、穩定提供服務的資料庫集群，從設計之初就充分了解和滿足營運需求，是資料庫架構設計成功的一個關鍵要素。
3）監管需求
對於強監管行業而言，不滿足監管要求，計畫就無法上線。因此，監管需求可以說事關監管行業的生死，必須在設計之初就充分考慮。
3、架構設計
1）業界生態
「不要重復造輪子」，在資料庫架構設計前，調研業界的技術生態非常重要。同時需要註意，我們所在組織的技術生態也是業界生態非常重要的一部份。
2）架構設計初稿
透過調研業界生態，我們能夠獲取資料庫架構所需的模組，再結合計畫的實際情況，對所需模組進行組合和完善，就能夠獲取資料庫架構的初稿。
4、架構構建
1）資料庫選型和測試
資料庫選型放在架構設計之後的一個重要考量是保證資料庫架構設計的客觀性。如果在資料庫架構設計之前就選定了資料庫，架構設計將不可避免地受到資料庫功能特性的影響。
2）資料庫架構原型
在擁有資料庫架構設計和完成資料庫選型的前提下，我們才能在測試或者開發環境構建資料庫架構原型，這是我們下一步工作的基礎。
5、架構叠代
1）在完成資料庫原型建設之後，可以開始對資料庫原型進行測試和驗證，驗證指標應回到最初的需求、業務目標、營運目標和監管目標。
2）每輪的測試和驗證都會生成架構的最佳化項，結合計畫的需求和目標，對資料庫架構不斷進行叠代，一般在3到5輪叠代之後就可以得到一個相對穩定可靠的資料庫架構。
二、某核心系統由大型電腦系統遷移到分布式架構
1、計畫調研
遷移計畫第一步是對當前系統的情況進行摸底調查。
1）容量和效能指標
系統指標分為很多方面，對於資料庫架構而言，首先需要考慮的是效能和容量指標。
2）業務特性
該計畫具有一個明顯的特點——即時線上業務一次僅處理一個客戶，賬務結算和報表模組一次需要處理很多客戶數據。
3）數據存取和處理
通常意義上所說的計算和儲存分離指的是數據儲存在大型電腦檔中，業務邏輯完全在套用層實作。
4）計畫人員能力
計畫人員的能力主要集中於JAVA的開發，對於Oracle和MySQL較為熟悉，其他關系型資料庫的開發則相對陌生，計畫人員的能力對於資料庫選型有明顯的影響。
2、資料庫架構原型設計
1）按照客戶對數據進行分片，數據路由在套用層處理，每個分片都由一個數據處理模組和一組資料庫例項組成，不同分片之間完全獨立，跨分片的聚合計算在業務層處理。
2）站在資料庫本身的視角，不同分片之間的資料庫例項是完全獨立的，不存在任何的數據互動。站在業務的角度，所有的資料庫例項則組成了一個統一的資料庫集群。
3）該架構的優點是單分片處理邏輯簡單，對即時線上業務非常友好；缺點是跨分片處理邏輯復雜，報表和賬務結算業務難度高。
3、資料庫選型
1）Oracle和MySQL的對比測試
2）經過架構師團隊的討論和權衡， 最終決定使用MySQL衍生資料庫 ，效能與原生MySQL接近，同時半同步不降級，滿足RPO=0
4、營運平台建設
1）配置管理： 為每個資料庫例項添加分片內容和業務內容。
2）端到端交付： 為了滿足資料庫例項可以動態地橫向擴容和縮容，增加了拉入節點、拉出節點和資源池的功能。
3）監控和故障處理： 在原有的資料庫監控平台的基礎上，增加了業務視角和分片視角，當資料庫例項故障時，能夠更加精準定位到受影響的客戶。
4）資料庫變更： 為滿足24小時不停機的業務要求，增加了業務降級、流量管控、捲動處理和變更行事曆功能。
5）版本釋出： 在分布式架構下，為應對成倍上升的復雜度和風險，增加灰度釋出、並列釋出、分片自適應和版本編排功能。
5、資料庫架構叠代
1）為滿足監管要求，需要在已有架構上添加容災架構。
2）使用業界已有的技術，透過binlog將數據即時同步到大數據平台，進行報表分析。
3）使用業界已有的技術，透過binlog將數據即時同步到分片資料庫（整體引入），降低賬務結算程式的復雜度。
三、Redis異地容災架構建設
1、需求整理
1）所有的Redis僅作為緩存使用，無數據同步需求。
2）95%以上的Redis為Cluster架構，5%以內的Redis為哨兵架構，本次設計的架構聚焦於Cluster架構。
3）95%以上的Redis Cluster無容量和效能要求，準確來說就是所有的Redis Cluster都可以標準化，只要後續提供擴容/縮容的功能即可。
4）生產Redis Cluster變化較大，異地容災要求和生產同步上線和下線。
5）最小化DBA和套用開發團隊的人力成本。
2、架構實作
1）建設一個K8S集群，用來承載所有的Redis集群。
2）建設Redis集群同步平台，從已有的CMDB讀取生產Redis集群的資訊，並將建立的異地容災Redis集群資訊更新到CMDB。
3）同步行程根據CMDB生成生產Redis集群集合和異地容災集合。生產集合減去異地容災集合，即需要搭建的異地容災集合，平台將自動建立異地容災集群，並將資訊更新到CMDB。異地容災集合減去生產集合，即需要下線的異地容災集合，平台將自動下線異地容災集群，並將這些集群從CMDB中刪除。
4）每天執行上述步驟，即可保證移動容災集群和生產集群的同步。
5）K8S集群可以自動拉起宕掉的節點，結合Redis集群本身的高可用，即可保證異地容災集群的高可用。
6）K8S集群本身的告警監控即可滿足異地容災的告警和故障處理需求。
7）設計自助平台，套用開發和營運團隊可以進行自助查詢、自助修改參數、自助擴容、自助申請網域名稱等操作，最小化DBA和套用開發營運的人力成本。
>>>>Q&A
Q1：在架構設計層面，怎樣避免數據遷移過程中的數據遺失問題呢？
A1： 首先數據校驗功能一定要與業務要求匹配，如果計畫遷移是停機完成的，一次性數據校驗程式就可以滿足。如果計畫遷移是線上完成的，就需要有即時數據校驗功能。其次對於重要系統，最好有流控模組，比如先遷移5%的流量，在驗證沒有問題後再遷移其他的流量。
Q2：貴團隊采用的數據分片方式是什麽？有哪些需要註意的點？
A2： 我們這個計畫是在套用層面做分片，這種分片方式需要有一個強大的中介軟體來完成，否則的話業務開發就變得非常復雜。這種分片方式在設計分片鍵的時候需要充分考慮即時線上業務的情況，要保證一個事務在同一個分片內完成。
Q3：Redis集群容易節點宕機，有什麽比較好的解決方案？
A3： 首先，從我的運維實踐來說Redis宕機頻率在可接受的範圍內。其次，Redis的Cluster架構，如果一個節點宕機後可以快速恢復的話，本身對業務的影響並不大。最後如果貴公司的Redis節點確實容易宕機的話，建議多建一個副本，這樣即使宕機也不會影響線上業務。
Q4：Redis異地容災，數據不做即時同步麽？
A4： 我們公司的系統，Redis只做緩存，所以沒有任何同步的需求。如果貴公司的Redis承擔緩存之外的功能，如需要記錄業務狀態，就需要做即時同步了，從實踐上來看，這種用法效果不是很理想。
Q5：請問，Cluster一般是什麽規模，即每個套用使用幾主幾從，每個節點maxmemory設定多大？
A5： Cluster一般是三主三從，maxmemory為2GB到8GB。一般單個例項的maxmemory超過8GB就不在擴容，而是采用增加節點的方式擴容。
Q6：資料庫同城容災，是一套數據物理放兩邊，還是兩中心各自獨立邏輯數據集群（邏輯復制）？
A6： 同城數據中心一般保證足夠的帶庫，所以絕大部份情況是使用資料庫本身的同步功能。只有網路效能不滿足，或者是有雙寫的要求，才考慮其他邏輯復制的方案。
直播地址：
（ 關註公眾號【 dbaplus社群 】，搜尋同名文章，即可獲取完整PPT ）
關於我們
dbaplus社群 是圍繞Database、BigData、AIOps的企業級專業社群。資深大咖、技術幹貨，每天精品原創文章推播，每周線上技術分享，每月線下技術沙龍，每季度Gdevops&DAMS行業大會。
關註公眾號【dbaplus社群】，獲取更多原創技術文章和精選工具下載
