很多金融企業都在考慮資料庫是不是要做分布式的改造。那究竟什麼樣的業務場景才需要做資料庫分布式架構呢？首先我們要明白傳統金融行業應用架構和網際網路的分布式應用架構有什麼不同。其實從資源層面、資料層面、中介軟體層面、應用的開發層面等都有乙個鮮明的對比。
1、資源層面。傳統的應用架構在使用微型機、儲存裝置等一些物理硬體。而目前在網際網路分布式應用下，阿里雲在使用公有雲、私有雲、混合雲等一些混合式的架構。
2、資料層面。傳統的應用在使用集中化的資料庫，比如oracle、sqlserver等資料庫，為什麼叫集中化的資料庫？因為傳統應用為了實現多個節點之間共享和最大限度的保證資料的一致性，習慣把資料檔案存放在一台集中化的儲存裝置裡面。而在網際網路分布式應用下，阿里雲一直倡導去集中化的資料庫的理念，所以目前阿里雲在使用mysql、hbase、redis等一些分布式的架構。
3、中介軟體層面。傳統應用在使用weblogic/was/mq等等，目前為了做一些微服務的改造，阿里雲在使用
swarm/k8s/mesos
等等一些架構來基於微服務做一些排程。 4
、從應用架構、應用框架來說，傳統的應用在使用spring/struts/soa，現在阿里雲在使用一些微服務架構。 5
、傳統企業的開發運維採用可控發布，保守運維，經常乙個新功能的發布動輒幾周甚至幾個月的時間才能上線。而現在阿里雲在使用devops，應用可以隨時上線。
因此在目前分布式的改造之下，阿里雲認為傳統金融行業對資料庫有更高的要求，總結起來就是需要敏捷、分布式、低成本等特點。由於每乙個微服務都對應乙個小的資料庫，需要大量的資料去支援乙個業務，因此需要靈活性的排程，所以對敏捷性是有要求的。同時因為量級比較大，也希望實現分布式結構。並且由於使用的資料庫多了，使用商業資料庫成本太大，因此需要降低成本。
金融行業需要什麼樣的資料庫呢？阿里雲認為金融行業做網際網路的創新，需要的資料庫主要有以下特點：
1、自主可控:基於開放架構，基於開源的優化。
2、高可用:跨機房容災，滿足金融級業務系統全天候對外提供穩定可靠的客戶服務。
3、高效能:網際網路+金融的創新業務所需的流量彈性。
4、支援雲:私有雲和公有雲互通一致的體感，降低使用和運維難度。
5、易運維:大體量自動化、運維體系合規化要求(基線、環境適配、管理體系等)。
6、資料安全: 審計&資料強一致性&多中心容災部署。
7、成本優化:it總體擁有成本必須下降。
基於以上特點，阿里雲提供了豐富的雲上資料庫。例如關係型資料庫有mysql、sql server postgresql、ppas(⾼高度相容oracle)、polardb。nosql資料庫有redis、mongodb、hbase、memcache。混合分析資料庫有hybriddb for mysql、hybriddb for postgresql。搜尋與時序資料庫有opensearch、elasticsearch、hitsdb。另外還提供像dts、dms、hdm等資料庫服務與工具。
對於這麼多資料庫型別和不同資料庫引擎而言，阿里雲還有很多不同的版本。以mysql為例，有基礎版、高可用版、金融版。基礎版是在ecs的基礎上，加雲盤上部署的mysql資料庫，它提供非常高的價效比，**基本上跟你買乙個ecs加乙個雲盤是一樣的，但是阿里雲在此之上已經整合好了資料庫產品。高可用版做了主從資料的複製，可以保證資料庫的資料可用性。當主節點宕機以後，阿里雲可以快速的把業務切換到從節點去，從而保證資料庫的可用性，同時還有很多企業級的功能，包括讀寫分離，讀寫分離是做資料庫橫向擴充套件最便捷的一種方式，應用不用做任何更改，把寫入在主節點執行，把查詢在唯讀節點執行，無形之中增強了主庫的能力。
金融版是跨三機房、三節點的三副本的版本，預設實現了同城三機房的容災。金融版直接部署在三個機房，它可以保證資料在三個機房做複製，並且當乙個機房不管是因為電源的故障還是因為光纖的故障而失效，整個資料庫也不會受到影響，資料庫主節點會自動遷移到另外兩個機房之一，繼續提供服務，同時金融版整合了sql審計、高頻監控等。
阿里雲金融版資料庫能做到資料的高可用、一致性主要從以下方面來考慮：
1、資料複製的演進——雙通道binlog複製
做資料庫的高可用是一定要做資料複製的。mysql原生提供兩種方式的複製，一種是非同步複製，比如是一主一從，中間做非同步複製。但是從節點勢必會引起延遲，當主節點發生故障的時候，這個時候不知道從節點的資料是不是最新的，因此如果切換從節點，很有可能會造成資料的丟失。為了解決這個問題，mysql官方提供了另一種方式，半同步複製。半同步複製也是一主一從，主節點在寫入資料的同時，會產生日誌，然後傳送日誌給從節點。因此當主節點宕機，至少可以保證從節點是有資料的。但是同時也會產生另乙個問題，當主節點在等從節點響應的時候，如果發生網路的故障，最終還是降級成非同步。因此阿里雲在alisql上做了增強，叫做雙通道複製，也就是說同時有一條半同步複製通道和非同步複製通道，通過這兩個通道可以確定性的得知當前主資料庫和從資料庫的資料是否一致。
2、拜占庭將軍問題與分布式一致性演算法
拜占庭將軍問題在分布式領域是乙個比較傳統的問題，為了解決拜占庭將軍問題，十幾年前有乙個paxos演算法，但是paxos演算法過於複雜，在很長一段時間都沒有計算機語言可以實現，後來paxos演算法做了簡化，即raft演算法。通過raft演算法可以解決分布式一致性問題，因此阿里雲把raft演算法放到了mysql核心裡面。底層維護了三個資料庫節點，一主兩備的複製拓撲結構意味著每個節點都是全量的資料，資料庫事務日誌(log)從主庫同步複製到所有的備庫，當集群中超過半數的節點都寫入成功後，事務才能完成提交。雖然是同步複製，但由於是三個點，因此單個節點的故障不會影響到例項整體的可用性。這種設計的好處顯而易見，即在不損失可用性的情況下，通過較高的資料冗餘度來換取更好的可靠性，同時支援跨機房的部署方式，具備機房容災能力。
3、對資料安全的重視
安全是根植於阿里雲核心的原生功能。從安全的角度，阿里雲做了事前、事中、事後三個方面的安全審計，事前阿里雲可以做vpc專有網路、ip白名單、防暴力破解、靈活賬號許可權管理等，事中做了 ssl加密、tde加密、攔截sql注入攻擊，事後可以做 sql審計、轉殖例項等。
在2023年5月，阿里雲發布了一款劃時代的資料庫polardb，polardb具有mysql的特點，與mysql達到了100%的相容。只要業務系統是基於mysql開發的，遷移到polardb上也毫無問題，而且效能上相比mysql提公升了6 - 10倍，最大規格支援64核，512g，支援的儲存容量達到100tb。
polardb解決了tcp/ip協議原始的延遲問題，並且放棄了mysql基於binlog的邏輯複製，而是基於innodb的redolog實現了物理複製去提公升整個資料庫的效能。所以阿里雲也希望大家逐漸嘗試，當mysql遇到效能瓶頸，可以往polardb遷移，而不是分庫分表等做一些複雜的操作。polardb經過
半年多試商用，目前已經正式上線，如果大家對polardb有任何疑問，都可以加阿里雲高階產品專家時慢的釘釘諮詢。
本文由雲棲志願小組黃小凡整理
資料庫實踐
1.資料庫學習筆記 如果把python 和資料庫比作兩個不同的地點，connection 就是路，能連線python和database。cursor就像在路上行駛的小貨車，可以用於執行sql 語句，以及儲存sql 執行的結果 序號api 描述 1sqlite3.connect database ti...
IT行業資料庫分析
mysql sun oracle 企業版本 oracle 收費 社群版本 免費 網際網路公司 pg postgresql oracle db2 ibm informix ibm sql server 微軟 sybase sap 德國的乙個公司 傳統企業 海爾 青島啤酒等 機關事業單位 oracle ...
MySQL 基於資料庫的號碼自增生成實踐
需求 生成指定規則遞增的號碼 年月日 當天的第幾個，如 201901140001，即209年1月14日哪一天的第乙個號碼，關鍵點1 獲取當天的號碼個數 2 加0處理，如當天第乙個，即0 1 1.加0，則為0001，保持四位。採用lpad函式。測試表create table test01 id int...