為內(nèi)容面很大，我的整體思路是從一些概念的邊界入手來進(jìn)行相關(guān)策略的推導(dǎo)，過程中會側(cè)重展開一些落地的案例和設(shè)計思想，我將通過如下4個部分的內(nèi)容來進(jìn)行闡述。

一、關(guān)于架構(gòu)思路和一些概念邊界

1.為什么需要數(shù)據(jù)庫分布式架構(gòu)？

首先需要有一個整體的認(rèn)識，為此有一個靈魂拷問：為什么需要數(shù)據(jù)庫分布式架構(gòu)？答案確實(shí)是千人千面，為此我整理了一個比較粗略的圖來說明我的觀點(diǎn)。

早期的數(shù)據(jù)庫架構(gòu)模式主要是單機(jī)模式。單機(jī)模式雖然也能滿足我們早期一些業(yè)務(wù)需求，但是隨著數(shù)據(jù)規(guī)模的擴(kuò)大以及業(yè)務(wù)的快速增長，對單機(jī)數(shù)據(jù)庫體系有了更高要求，從而延伸出以下幾個發(fā)展方向：

1）通過更高級配置、擴(kuò)大容量等方式將原本的單機(jī)數(shù)據(jù)庫變得更大更強(qiáng)，在這種情況下，數(shù)據(jù)庫會變成一個“超人”，如上圖所示的“超人”。

2）將業(yè)務(wù)分為多個部分完成，這種模式發(fā)展到后期可能會產(chǎn)生多個分支，如果容量越來越大，需求的復(fù)雜度會越來越高，可能涉及到集群模式管理，如上圖所示的“三個工人”和”兩個超人”。

3）集群模式可能會延伸出另一種模式，當(dāng)原本的單機(jī)模式難以擴(kuò)展時，我們可以將原本的高配單機(jī)增加至兩個或者多個，然后通過業(yè)務(wù)拆分來完成，這種情況可能會導(dǎo)致一種尷尬局面，容量足夠的情況下部分配置存在上限，例如達(dá)到一定程度后數(shù)據(jù)庫會變得“臃腫”。為解決這一問題，人工難以承載的業(yè)務(wù)可以基于代理層來實(shí)現(xiàn)，如上圖所示的“六個工人+代理人”。

4）上述第三種模式再進(jìn)行延伸，可能出現(xiàn)另一種模式，將數(shù)據(jù)存儲與數(shù)據(jù)管理分離，即將數(shù)據(jù)存儲與數(shù)據(jù)計算分離，這一過程需要相關(guān)的調(diào)度管理進(jìn)行銜接和協(xié)作，如上圖右側(cè)所示。

以上內(nèi)容通過一個小案例講述了為什么需要數(shù)據(jù)庫分布式架構(gòu)，可能初聽“數(shù)據(jù)庫分布式架構(gòu)”有些拗口，下面將對分布式數(shù)據(jù)庫與數(shù)據(jù)庫分布式架構(gòu)這兩個概念進(jìn)行區(qū)分。

2.概念邊界

這些年來分布式數(shù)據(jù)庫、云原生數(shù)據(jù)庫的概念都很火熱，同時分布式架構(gòu)、微服務(wù)架構(gòu)等在行業(yè)內(nèi)也有大量的落地場景和最佳實(shí)踐。我們通常所說的分布式數(shù)據(jù)庫和數(shù)據(jù)庫分布式架構(gòu)還是有一定的區(qū)別的，但是又存在一定的關(guān)聯(lián)，就好比如下的包含關(guān)系一樣，是一種層級遞進(jìn)的關(guān)系。

對上面的圖我提煉出幾個要點(diǎn)：

• 分布式數(shù)據(jù)庫是分布式架構(gòu)的重要一環(huán)，但不是完全強(qiáng)依賴，也就意味著業(yè)務(wù)層的架構(gòu)設(shè)計好壞能夠直接影響整體的架構(gòu)質(zhì)量。
• 數(shù)據(jù)庫分布式架構(gòu)的發(fā)展空間相比于分布式數(shù)據(jù)庫更大，它更貼近于業(yè)務(wù)，分布式只是數(shù)據(jù)庫分布式架構(gòu)的一種演進(jìn)策略。
• 云原生數(shù)據(jù)庫是分布式數(shù)據(jù)庫的一種演進(jìn)形式，相對來說更為垂直。

如上圖左側(cè)圖形所示，做分布式涉及到的整體成本相對較高，并且在硬件、軟件、開發(fā)測試等方面存在差異。

目前分布式數(shù)據(jù)庫的版圖大體分為三類：基于分片模式的數(shù)據(jù)庫集群，基于NewSQL的分布式數(shù)據(jù)庫和云原生數(shù)據(jù)庫三大類，在不同的分類中都有相應(yīng)的典型代表和頭部玩家，他們都有各自擅長的業(yè)務(wù)場景和領(lǐng)域，目前來看基于分片模式的數(shù)據(jù)庫集群的發(fā)展相對成熟，而基于NewSQL和云原生數(shù)據(jù)庫的發(fā)展這些年增長很快，目前已然是一種新的數(shù)據(jù)庫架構(gòu)演進(jìn)趨勢。說到架構(gòu)，必然需要考慮架構(gòu)的考量維度。

3.通用架構(gòu)能力

通常會按照如下的三個維度來進(jìn)行整體的架構(gòu)考量：彈性擴(kuò)展，高可用和高性能，這三個維度能夠大體衡量架構(gòu)設(shè)計的目標(biāo)是否滿足預(yù)期。

1）彈性擴(kuò)展。原本的單機(jī)可能不夠用，我們可以通過彈性擴(kuò)展方式將原來的水平擴(kuò)展演進(jìn)為彈性擴(kuò)展。

2）高可用。通過架構(gòu)能力可以實(shí)現(xiàn)中間件節(jié)點(diǎn)高可用、數(shù)據(jù)節(jié)點(diǎn)高可用等整體的高可用。

3）高性能。架構(gòu)能力可以在讀寫性能方面做到更高能力支撐。

至此，我們從一些概念和架構(gòu)考量維度上有了一個整體的認(rèn)識，那么前面說到架構(gòu)是需要持續(xù)演進(jìn)的，那么到底有什么架構(gòu)策略，是否可以大一統(tǒng)呢？我打算從單機(jī)和數(shù)據(jù)兩個維度來推導(dǎo)架構(gòu)的策略。

二、從單機(jī)和數(shù)據(jù)維度推導(dǎo)架構(gòu)策略

架構(gòu)的演進(jìn)通常是依據(jù)需求和業(yè)務(wù)的發(fā)展動態(tài)適配的，如果單機(jī)配置能夠滿足容量，性能等資源需求，在開發(fā)設(shè)計周期和系統(tǒng)復(fù)雜度層面都是一種比較理想的平衡狀態(tài)，也是比較建議的，但是很多業(yè)務(wù)發(fā)展趨勢不是線性的，而是指數(shù)級的變化和增長，這種情況下就需要在先期的架構(gòu)設(shè)計中進(jìn)行預(yù)防性架構(gòu)設(shè)計，也就是我們在設(shè)計初期就不能從潛意識中偷懶，等到業(yè)務(wù)發(fā)展的速度和后端的改造能力不匹配的時候，問題就會接踵而至，而很多在前期沒有考慮到的問題在基于分布式設(shè)計時，無論是開發(fā)周期和系統(tǒng)復(fù)雜度都會難以接受。

1.單機(jī)維度推導(dǎo)架構(gòu)演進(jìn)策略

單機(jī)模式下的分布式架構(gòu)可以拆分為三個維度：系統(tǒng)配置、數(shù)據(jù)庫配置和數(shù)據(jù)庫相關(guān)服務(wù)管理。

1）系統(tǒng)配置

系統(tǒng)配置包括CPU、內(nèi)存等，相對來說是一個固化的模式，對其進(jìn)行擴(kuò)展的難度較低，其成本也已經(jīng)隨著硬件的發(fā)展大幅度降低，簡單來說，如果在成本可控范圍內(nèi)，花錢升級硬件就能解決。

2）數(shù)據(jù)庫配置

數(shù)據(jù)庫配置包括單庫容量、單表容量、連接數(shù)和吞吐量等，其中單庫容量擴(kuò)展存在一定瓶頸。綜合來看，對數(shù)據(jù)庫配置做擴(kuò)展會有些難度，但是這個時候有些復(fù)雜度，不是單純升級硬件就能夠解決的，比如我曾經(jīng)管理過一張表，容量有1T，對于單機(jī)來說是需要相當(dāng)謹(jǐn)慎的，這里的難度等級約為中等。

3）服務(wù)管理

服務(wù)管理包括負(fù)載管理、高可用管理、事務(wù)管理、運(yùn)維管理等。在事務(wù)管理的復(fù)雜度方面，單機(jī)模式比分布式好一些。在管理模式上，單機(jī)模式使用了All In One模式，算是集中式管理，而分布式管理需要大量的自動化運(yùn)維支撐。分布式管理在負(fù)載管理和高可用管理方面相比于單機(jī)管理有較大提升。在混合負(fù)載方面，原本的單機(jī)模式是整個服務(wù)的整體覆蓋，但在分布式架構(gòu)體系內(nèi)要考慮整體負(fù)載能力的提升，不能因?yàn)閱我还?jié)點(diǎn)的短板導(dǎo)致整個集群被拖垮，整體的難度相對較高。

2.數(shù)據(jù)維度推導(dǎo)架構(gòu)演進(jìn)策略

首先將數(shù)據(jù)分為以下三個維度：

1）流水型數(shù)據(jù)

流水型數(shù)據(jù)是無狀態(tài)的，多筆業(yè)務(wù)之間沒有關(guān)聯(lián)，每次業(yè)務(wù)過來的時候都會產(chǎn)生新的單據(jù)，比如交易流水，支付流水，只要能插入新單據(jù)就能完成業(yè)務(wù)，特點(diǎn)是后面的數(shù)據(jù)不依賴前面的數(shù)據(jù)，所有的數(shù)據(jù)按時間流水進(jìn)入數(shù)據(jù)庫。

2）配置型數(shù)據(jù)

配置型數(shù)據(jù)即我們所說的配置中心字典，數(shù)據(jù)字典配置等。此類型數(shù)據(jù)數(shù)據(jù)量較小，而且結(jié)構(gòu)簡單，一般為靜態(tài)數(shù)據(jù)，變化頻率很低。 

3）狀態(tài)性數(shù)據(jù)

狀態(tài)型數(shù)據(jù)是有狀態(tài)的，多筆業(yè)務(wù)之間依賴于有狀態(tài)的數(shù)據(jù)，而且要保證數(shù)據(jù)的準(zhǔn)確性，例如賬戶余額，做充值時必須要拿到原來的余額才能支付成功，因此狀態(tài)型數(shù)據(jù)整體的維護(hù)最復(fù)雜，是我們現(xiàn)在做分布式事務(wù)管理的核心部分。

基于以上數(shù)據(jù)類型分類我們可以延伸出三類表：字典表、日志表和狀態(tài)表。

在架構(gòu)設(shè)計上和演進(jìn)方面，配置型和流水型數(shù)據(jù)的擴(kuò)展方案相對比較豐富，通常不需要事務(wù)管理，所以擴(kuò)展和性能方面表現(xiàn)都很出色，方案落地性更強(qiáng)，難度最大的是狀態(tài)型數(shù)據(jù)，因?yàn)樗嬖跀?shù)據(jù)的關(guān)聯(lián)和依賴，所以需要事務(wù)管理，在擴(kuò)展性和性能方面的解決方案不夠完美，需要做一定的取舍，如事務(wù)降維，或把數(shù)據(jù)強(qiáng)一致性的需求降為最終一致性等。

下面將對這三類表進(jìn)行對比架構(gòu)演進(jìn)策略的解讀。

① 數(shù)據(jù)量

字典表的數(shù)據(jù)量最小，日志表數(shù)據(jù)量極大，狀態(tài)表的數(shù)據(jù)量大小與業(yè)務(wù)規(guī)模相關(guān)。

② 數(shù)據(jù)依賴

字典表基本不存在事務(wù)依賴，即使有，也只存在于極少數(shù)的配置中；日志表沒有事務(wù)依賴，所以改造日志表的切入點(diǎn)比較好找；狀態(tài)表整體有事務(wù)依賴。

③ 業(yè)務(wù)特點(diǎn)

字典表整體上為讀多寫少的模式；日志表的著重點(diǎn)為大批量密集型讀寫，整體為讀少寫多的模式；狀態(tài)表整體為讀多寫多的模式。

④ 架構(gòu)策略

• 架構(gòu)1.0策略

我們通常基于讀寫分離的模式對字典表做擴(kuò)展改進(jìn)。對于日志表，我們需要考慮提前做拆庫、拆表，我們將這種模式稱為周期表。對于狀態(tài)表，我們可以通過讀寫分離的模式對讀這部分的流量做緩解，但并不能從根本上解決問題。

• 架構(gòu)2.0策略

對于字典表可以采用全局的分庫分表方式。對日志表主要使用業(yè)務(wù)路由和數(shù)據(jù)庫中間件。狀態(tài)表相較于前兩者更為復(fù)雜，其中一種方式是分庫分表，另一種方式是基于分庫分表模式做事務(wù)降維或整體的過程中直接做事務(wù)降維。事務(wù)降維包括兩種方式，一種是在整個的過程中根據(jù)業(yè)務(wù)的特點(diǎn)不啟用事務(wù)，另一種是在設(shè)計中將事務(wù)的維度或顆粒度降到最低，基于最小化的分片維度執(zhí)行操作。

⑤ 系統(tǒng)優(yōu)化策略

字典表的優(yōu)化比較清晰，我們可以通過緩存模式進(jìn)行優(yōu)化，該方法可解決大部分問題。日志表在寫入過程中，實(shí)時延遲不會很高，我們可以基于隊列采用異步方式提升整個系統(tǒng)的吞吐量。狀態(tài)表主要對讀這部分的狀態(tài)因數(shù)據(jù)做緩存。在系統(tǒng)優(yōu)化策略維度，字典表和日志表比較容易進(jìn)行優(yōu)化，狀態(tài)表的加工改造策略是重難點(diǎn)，而且整個過程中也無法徹底解決問題，對設(shè)計的整體要求也較高。

⑥ 建設(shè)目標(biāo)

字典表適用于建設(shè)配置中心，日志表適用于建設(shè)賬單存儲平臺，狀態(tài)表適用于建設(shè)數(shù)據(jù)中臺。

三、架構(gòu)演進(jìn)與案例分析 

這部分我將架構(gòu)的演進(jìn)歷程分為1.0、2.0、3.0三個階段，便于下文講述，該劃分方式并無嚴(yán)格的優(yōu)劣之分。

架構(gòu)1.0階段的主要策略為垂直拆分、拆庫拆表以及讀寫分離。

架構(gòu)2.0階段的主要策略為基于數(shù)據(jù)庫中間件和業(yè)務(wù)路由的分布式方案。

架構(gòu)3.0階段的主要策略為基于云關(guān)系型數(shù)據(jù)庫和分布式關(guān)系型數(shù)據(jù)庫的方式。

在整個架構(gòu)以及架構(gòu)策略的演進(jìn)過程中，整體模式與前文中提到的模式相似。單機(jī)模式通過業(yè)務(wù)拆分或者2.0階段的業(yè)務(wù)路由和數(shù)據(jù)庫中間件策略滿足業(yè)務(wù)需求。在3.0階段，通過存算分離以及調(diào)度層統(tǒng)籌滿足業(yè)務(wù)需求。以下對每個階段進(jìn)行詳細(xì)解讀。

1.架構(gòu)1.0階段和案例

在這一階段，我們采用了拆庫拆表的方式將商業(yè)數(shù)據(jù)庫遷移到MySQL中。原本我們可能處于單機(jī)模式，在整個單機(jī)模式下，我們通過拆庫拆表方式將業(yè)務(wù)拆分到兩個相對獨(dú)立的服務(wù)器上，再實(shí)現(xiàn)日志數(shù)據(jù)的異步寫入。對于狀態(tài)型數(shù)據(jù)，我們可以做讀寫分離的改進(jìn)。

在1.0階段，我們通過拆分隔離將業(yè)務(wù)進(jìn)行拆分，包括兩種拆分方式：

1）將大的狀態(tài)型業(yè)務(wù)拆分為兩部分，一部分為全局型業(yè)務(wù)，另一部分為特定某個去向的業(yè)務(wù)。例如游戲公司有20款游戲，我們將這些游戲的公共屬性數(shù)據(jù)拆分出來在平臺層重組，再針對不同游戲的獨(dú)特屬性數(shù)據(jù)進(jìn)行擴(kuò)展。

2）在單機(jī)模式下將日志型數(shù)據(jù)和狀態(tài)型數(shù)據(jù)進(jìn)行拆分。日志型數(shù)據(jù)拆分難度較低，通過數(shù)據(jù)庫中間件即可實(shí)現(xiàn)。拆分日志型數(shù)據(jù)的過程中，面對大量讀的要求可以通過一主多從的方式進(jìn)行讀寫分離的改進(jìn)。

在這一階段，對數(shù)據(jù)量極大的表進(jìn)行變更很困難，簡單來說，單機(jī)數(shù)據(jù)庫中對于流水型數(shù)據(jù)存在明顯的瓶頸，比如一張表每天產(chǎn)生20G的日志，那么單機(jī)容量的規(guī)格假設(shè)是300G，就僅僅能夠保存2周左右的數(shù)據(jù)，而數(shù)據(jù)清理通常需要業(yè)務(wù)側(cè)寫相應(yīng)的邏輯進(jìn)行定時處理，在數(shù)據(jù)庫負(fù)載和查詢性能方面都有一定的隱患。為改善這一問題，我們提出了周期表的概念，根據(jù)時間將表分為日、周、月、年和幾年五個維度，日志數(shù)據(jù)都可以按照這五個維度進(jìn)行拆分。將日志數(shù)據(jù)根據(jù)周期表進(jìn)行拆分的好處是便于對數(shù)據(jù)進(jìn)行清理，整個清理過程中維護(hù)代價也較低。我們?yōu)榱寺鋵?shí)數(shù)據(jù)清理工作也做了一些狀況類化，例如DBA實(shí)現(xiàn)表的自動擴(kuò)展與自動清理。對表進(jìn)行清理并非對現(xiàn)有表直接清理，而是設(shè)置一個期限，例如一個月，超過期限后將表放入回收站中，再對表內(nèi)容進(jìn)行操作，操作過后將表放置到另外的庫中，超過一定期限后逐步清理。這整個過程中，如果有一些數(shù)據(jù)需要恢復(fù)，我們可以快速重置?，F(xiàn)在我們已經(jīng)接入了四五百個周期表，形成了自循環(huán)的管理模式，而對于公司整體業(yè)務(wù)來說，幾乎很難看看到一些數(shù)據(jù)量恐怖的表，因?yàn)檫@些都通過這種設(shè)計模式基本杜絕了。

2.架構(gòu)2.0演進(jìn)和案例

1）消息業(yè)務(wù)路由改造

架構(gòu)2.0階段首先做業(yè)務(wù)路由的改造。早期我們做消息業(yè)務(wù)的改造，例如打開APP后的消息推送，整體的吞吐量較大。在早期的業(yè)務(wù)中，對于消息存儲的數(shù)據(jù)統(tǒng)計要求較高，我們希望能夠盡快將消息推送抵達(dá)用戶并獲得反饋，使得整個業(yè)務(wù)運(yùn)營形成閉環(huán)。

如上圖右側(cè)所示，是數(shù)據(jù)庫側(cè)的I/O使用情況，在進(jìn)行I/O優(yōu)化的過程中，一個主節(jié)點(diǎn)難以承載負(fù)荷，所以我們將查詢需求擴(kuò)展到了從節(jié)點(diǎn)做了讀寫分離，后期發(fā)現(xiàn)仍不能滿足要求，統(tǒng)計查詢還是非?？D，I/O使用率還是被打滿。我們進(jìn)行了列式存儲擴(kuò)展，將統(tǒng)計查詢遷移過去后提高了查詢效率，算是解決了查詢瓶頸問題，原服務(wù)的I/O使用率一下子降低了60%以上，再后來通過業(yè)務(wù)路由將一個節(jié)點(diǎn)動態(tài)擴(kuò)展為三個節(jié)點(diǎn)，如上圖左側(cè)所示，性能又有了明顯改善，提升了20%左右，整個過程是一個循序漸進(jìn)的優(yōu)化過程。 

2）數(shù)據(jù)庫中間件

第二類是基于數(shù)據(jù)庫中間件的模式，數(shù)據(jù)庫中間件方式需要考慮數(shù)據(jù)的重分布、數(shù)據(jù)的可用性和同城異地容災(zāi)等。

基于這種架構(gòu)模式，我們也做了一些特色化的服務(wù)，主要有4點(diǎn)：

• 中間件負(fù)載均衡

數(shù)據(jù)庫集群架構(gòu)模式通過Consul服務(wù)把原來的三層結(jié)構(gòu)改成了兩層，實(shí)現(xiàn)了中間件層的負(fù)載均衡。

• 配置化建表

對于線上數(shù)據(jù)庫集群創(chuàng)建表的需求，我們通過配置實(shí)現(xiàn)數(shù)據(jù)表的定制化創(chuàng)建。比如我們需要我們創(chuàng)建一張表時，只需要在配置表里寫一條配置信息，之后我們會通過服務(wù)掃描配置變化，如果發(fā)生變化，就會在線上創(chuàng)建相關(guān)的表，保證業(yè)務(wù)的連續(xù)性，這個過程看似簡單，實(shí)際上對于集群的結(jié)構(gòu)設(shè)計要求是很高的。

• 數(shù)據(jù)流轉(zhuǎn)

對于集群的數(shù)據(jù)流轉(zhuǎn)，是數(shù)據(jù)分分合合的難點(diǎn)，我們通過流轉(zhuǎn)程序來實(shí)現(xiàn)，如DataX來進(jìn)行數(shù)據(jù)聚合，為此我們構(gòu)建了一個中間層來統(tǒng)一流轉(zhuǎn)，后續(xù)的思路是直接將賬單存儲改造為NewSQL數(shù)據(jù)庫，直接提供實(shí)時數(shù)據(jù)交付。

• 只讀查詢

一些線上數(shù)據(jù)的復(fù)雜查詢也可以通過只讀中間件去做，把它掛載到一個只讀的中間件節(jié)點(diǎn)上可以平滑實(shí)現(xiàn)在線的數(shù)據(jù)查詢，后續(xù)打算通過雙集群模式（中間件+NewSQL集群）來提供平滑的讀寫需求。如果這4點(diǎn)的力道不足，那么中間件架構(gòu)還存在如下的兩個典型優(yōu)勢可以補(bǔ)充，分別是數(shù)據(jù)重分布和分布式集群組的存儲模式。

① 數(shù)據(jù)重分布

第一個優(yōu)勢數(shù)據(jù)重分布，因?yàn)橹虚g件架構(gòu)優(yōu)缺點(diǎn)并存，我們在實(shí)踐過程中經(jīng)歷了很多考驗(yàn)，對于中間件架構(gòu)來說，個人覺得它的一大特色就是拓?fù)浣Y(jié)構(gòu)的可擴(kuò)展性。比如硬件服務(wù)器在多年后需要過保替換，逐個服務(wù)器替換還是會產(chǎn)生系統(tǒng)抖動，如果有幾十個節(jié)點(diǎn)，這種替換其實(shí)會存在一定的風(fēng)險，基于中間件架構(gòu)可以快速實(shí)現(xiàn)拓?fù)浣Y(jié)構(gòu)擴(kuò)展，如上圖所示，可以補(bǔ)充一套從庫節(jié)點(diǎn)，然后將中間件收縮，再將3層拓?fù)淝袚Q為兩層，對于幾十上百個節(jié)點(diǎn)的快速切換，這是一種很優(yōu)雅的模式，整個切換過程在3.5秒左右，當(dāng)業(yè)務(wù)服務(wù)具備重連機(jī)制，集群內(nèi)部其實(shí)已經(jīng)發(fā)生了質(zhì)的變化。

② 優(yōu)勢分布式集群組/通用存儲方案設(shè)計

第二個優(yōu)勢分布式集群組/通用存儲方案設(shè)計，比如我們所說的數(shù)據(jù)庫分布式架構(gòu)整體需要去滿足業(yè)務(wù)需求，發(fā)現(xiàn)有很多數(shù)據(jù)表結(jié)構(gòu)都是相似的，在這種情況下，我們就可以實(shí)現(xiàn)動態(tài)、靈活的存儲管理模式。

主要分為兩個維度：第一，通用存儲意味著我們原來的一套集群不夠，我們可以再補(bǔ)一套集群實(shí)現(xiàn)，這樣就是集群組的模式。在這個層面上，我們就把集群下沉一層，在上層進(jìn)行配置化的管理，在上層有一個全局配置；第二，我們通過全局配置可以快速靈活地生成一些定制化的表結(jié)構(gòu)，比如有的業(yè)務(wù)對于數(shù)據(jù)的存儲需求是varchar(32)，而有的是varchar(256)或者bigint，這些都可以在集群組中動態(tài)配置，從而適配不同的模板，通過這種靈活的配置管理的方式實(shí)現(xiàn)整個集群組數(shù)據(jù)的存儲管理。

3.架構(gòu)3.0演進(jìn)和技術(shù)分析

我們經(jīng)常聽到云關(guān)系型數(shù)據(jù)庫和分布式關(guān)系型數(shù)據(jù)庫等概念。

個人經(jīng)過整理發(fā)現(xiàn)數(shù)據(jù)庫的整個演進(jìn)過程中有許多故事。Google很早就開始在內(nèi)部孵化Spanner，2011年左右發(fā)布論文，論文發(fā)布后形成了兩個分支，一個分支對原本的模式不滿，另一分支從原本的模式中受到啟發(fā)對其進(jìn)行了改進(jìn)。以上兩種分支延伸出兩大派別，一種是基于Aurora模式，并基于此思想產(chǎn)生了Aurora數(shù)據(jù)庫，例如騰訊的CynosDB和阿里云的PolarDB等。另一種是受Spanner論文思想影響下產(chǎn)生基于另一體系的TiDB等數(shù)據(jù)庫。

從整體上看，兩大派別較大的差異在于Aurora等數(shù)據(jù)庫與MySQL沒有太大差異，整體采用了存算分離的架構(gòu)，而另一派別的數(shù)據(jù)庫是以NewSQL全新的設(shè)計體系，兼容MySQL協(xié)議的形式出現(xiàn)，兩者屬于不同的體系，在數(shù)據(jù)庫分布式架構(gòu)策略方面也有不同的實(shí)現(xiàn)，從早期的讀寫分離模式到周期表、中間件，后續(xù)還會有新型中間件等。

1）數(shù)據(jù)庫分布式架構(gòu)策略對比

其實(shí)云原生數(shù)據(jù)庫從某種概念上來說是彎道超車，云原生數(shù)據(jù)庫中以Aurora為典型代表的數(shù)據(jù)庫，其底層設(shè)計本質(zhì)為讀寫分離模式，但核心技術(shù)是分布式共享存儲，它是從讀寫分離的模式經(jīng)歷了大跨越的更新。

① 云原生數(shù)據(jù)庫-Aurora

我們簡單來看一下具有代表性的Aurora數(shù)據(jù)庫，是AWS在MySQL的基礎(chǔ)上進(jìn)行了魔改，因?yàn)锳WS對Spanner的事務(wù)處理能力不滿意，提出日志即數(shù)據(jù)庫，并重新設(shè)計讀寫分離集群，延伸出Aurora數(shù)據(jù)庫，其整體為6副本，底層基于S3，整體采用讀寫分離模式。

② CynosDB，PolarDB

CynosDB和Aurora有一些差異，但其整體還是存儲計算分離的結(jié)構(gòu)，基于Raft,將redo下推至存儲管理。PolarDB基于RDMA，沒有將redo下推至存儲，其本質(zhì)還是基于存儲計算分離的模式。

③ TiDB體系結(jié)構(gòu)

我們TiDB的調(diào)研時間較早，在早期也是在測試環(huán)境中沉淀了許久，然后逐步從日志型數(shù)據(jù)庫改造開始，逐步引入更多的業(yè)務(wù)范圍。

4.數(shù)據(jù)庫分布式架構(gòu)演進(jìn)小結(jié)

通過總結(jié)我們在分布式架構(gòu)方面的實(shí)踐，我把整個分布式架構(gòu)分兩個維度，一個維度是從水平擴(kuò)展的能力考量，另一個維度是從吞吐量這個方面考慮。如果原來的單機(jī)處于起點(diǎn)，垂直拆分可能有較大提升。

我們在2018年時已經(jīng)大量使用讀寫分離模式，當(dāng)然讀寫分離模式對于很多敏感的業(yè)務(wù)不是那么嚴(yán)謹(jǐn)，但在很多數(shù)據(jù)不是那么敏感或者延遲不那么敏感的情況下，是一個相對簡單的架構(gòu)改進(jìn)。

在演進(jìn)過程中我們少走了一些彎路。我們對很多賬單表的數(shù)據(jù)提前做了布局和拆分，把它改造成周期表模式，周期表模式改造好后，我們目前為止很少見到數(shù)據(jù)量非常大的表，基于此，我們自然的引入了中間件的分庫分表方案。對于中間件集群的方案，我們后續(xù)有兩種模式，一種是做業(yè)務(wù)拆分，另一種是套入原來的通用存儲方案，通過配置化的方式實(shí)現(xiàn)集群組的管理。

這個階段后會有一個分界點(diǎn)，也是關(guān)于數(shù)據(jù)庫最后一個非常核心的點(diǎn)——事務(wù)管理。事務(wù)管理方面，一種方式是復(fù)雜的管理模式，另一種是最小顆粒度的事務(wù)管理。之后的新型的中間件還有NewSQL體系，我們都進(jìn)行了嘗試，并在2021年落地了技術(shù)棧。

在此，我補(bǔ)充一些數(shù)據(jù)來對不同的架構(gòu)策略做一些對比。

從整個分布式體系來看，各方面有利有弊，我們要去理性看待一項技術(shù)，不一定NewSQL體系就是最好的。為保證觀點(diǎn)的嚴(yán)謹(jǐn)，我通過雷達(dá)圖從以下幾個方面進(jìn)行了對標(biāo)準(zhǔn)版實(shí)例、數(shù)據(jù)庫中間件和NewSQL三者進(jìn)行了評估。

• 事務(wù)管理

基于單機(jī)模式長周期的驗(yàn)證，標(biāo)準(zhǔn)實(shí)例在事務(wù)管理方面最有優(yōu)勢。中間件在事務(wù)管理方面存在瓶頸。NewSQL集群的思路模型依托的是另一種體系，需要時間周期的驗(yàn)證以及業(yè)務(wù)場景的匹配，所以其介于兩者之間。

• 驗(yàn)證周期

單機(jī)模式有長時間的驗(yàn)證周期。

• 遷移升級

三者在遷移方面都有相對成熟的體系。

• 高可用

相較于其他二者，NewSQL在高可用方面具有明顯優(yōu)勢。

• 擴(kuò)縮容

在擴(kuò)縮容方面單機(jī)模式相對受限。NewSQL在擴(kuò)縮容方面最有優(yōu)勢，能夠?qū)崿F(xiàn)某種程度的彈性擴(kuò)縮容。

• 性能

中間件的方案對于一些性能極度敏感，在有良好設(shè)計的情況下，其整體性能更有優(yōu)勢。

綜上所述，應(yīng)該根據(jù)不同的場景選擇適合的方案，切勿一刀切。

四、技術(shù)展望和小結(jié)

1.數(shù)據(jù)庫架構(gòu)演進(jìn)趨勢分析

1）數(shù)據(jù)庫生態(tài)之國產(chǎn)化

從整個數(shù)據(jù)庫架構(gòu)的演進(jìn)過程來看，現(xiàn)在的數(shù)據(jù)庫生態(tài)變得越來越多元化，同時也存在一定的差異化和風(fēng)險，在此我想多提一下國產(chǎn)化數(shù)據(jù)庫，因?yàn)檫@是生態(tài)中不可或缺的。

目前國內(nèi)的數(shù)據(jù)庫國產(chǎn)化程度還是比較高的，如果從近些年來研發(fā)技術(shù)和數(shù)據(jù)庫的緊密結(jié)合來看，很明顯研發(fā)方向是在降低對于數(shù)據(jù)庫的重邏輯依賴，轉(zhuǎn)而通過分布式技術(shù)架構(gòu)來滿足性能和擴(kuò)展性等強(qiáng)烈需求，而互聯(lián)網(wǎng)作為開源技術(shù)的試驗(yàn)田，提供了大量的業(yè)務(wù)場景使得開源軟件能夠不斷成熟迭代。在功能實(shí)現(xiàn)上，國產(chǎn)數(shù)據(jù)庫也更為貼合國內(nèi)用戶的使用需求和體驗(yàn)。從這個層面來看，國產(chǎn)化數(shù)據(jù)庫通常都具有分布式的成長基因。

但是，在行業(yè)中也在短時間內(nèi)產(chǎn)生了大量的數(shù)據(jù)庫定制化產(chǎn)品，這些都是在核心組件和底層服務(wù)之外的偏個性化定制，使得用戶在林林總總的國產(chǎn)化數(shù)據(jù)庫中容易迷茫，另外國產(chǎn)數(shù)據(jù)庫如果僅僅是為了對標(biāo)和其他商業(yè)數(shù)據(jù)庫的兼容度，個人感覺會受到過多束縛和限制，因?yàn)檫^多的泛應(yīng)用化會讓數(shù)據(jù)庫技術(shù)的基礎(chǔ)沉淀不夠扎實(shí)，而過度迎合用戶使用體驗(yàn)而在設(shè)計理念上妥協(xié)，會讓數(shù)據(jù)庫技術(shù)難以聚焦，限制更大的發(fā)揮潛力。

2）做得更少 vs 做得更多

在數(shù)據(jù)庫分布式架構(gòu)的改造中，做得更少對我來說是顛覆認(rèn)知的收獲。我們早期做分布式架構(gòu)性能提升時希望做得更多，支撐更高的OPS，提供更高更強(qiáng)的性能，但我們做架構(gòu)改造的過程中發(fā)現(xiàn)有些情況卻恰恰相反，基于業(yè)務(wù)的視角去做一些架構(gòu)優(yōu)化反而能夠取得更好的效果，最后發(fā)現(xiàn)原來支撐了幾十萬的OPS,經(jīng)過優(yōu)化幾萬OPS就足夠了，從這個層面來說，數(shù)據(jù)庫分布式架構(gòu)的發(fā)展空間很大。

3）分布式共享存儲

云原生數(shù)據(jù)庫有共享存儲的影子，例如Aurora是基于讀寫分離模式，它之所以在分布式方向?qū)崿F(xiàn)彎道超車，是因?yàn)槠浜诵牟糠质欠植际焦蚕泶鎯夹g(shù)，在云原生數(shù)據(jù)庫中，原來看起來“土味的”共享存儲模式其實(shí)玩出了新的花樣。

4）HTAP需要理性

原本單一的OLTP和OLAP業(yè)務(wù)，在開發(fā)和管理中存在諸多不便，而HTAP在一定程度上能夠有效的結(jié)合兩者的優(yōu)勢，從而提供更為統(tǒng)一高效的數(shù)據(jù)服務(wù)，我想這應(yīng)該是近些年來HTAP大火的原因，在這個基礎(chǔ)上我建議要警示數(shù)據(jù)膨脹的問題，ALL IN的問題帶來的隱患會隨著時間的增長而變得更加棘手。

所以對于HTAP方案，我并不十分認(rèn)可All In One 的模式，或者說存在一些擔(dān)心，我們需要理性看待HTAP方案。

2.基于機(jī)器學(xué)習(xí)的數(shù)據(jù)庫監(jiān)控異常預(yù)測研究

近些年來AIOps還是很火的，數(shù)據(jù)庫也會搭上這輛便車。我前段時間進(jìn)行了一些機(jī)器學(xué)習(xí)相關(guān)的研究，將成百上千的服務(wù)器通過機(jī)器學(xué)習(xí)的方式做相關(guān)監(jiān)控數(shù)據(jù)的預(yù)測，如上圖我們基于回歸模型和時序模型進(jìn)行了預(yù)測，整體上基本實(shí)現(xiàn)了對某些指標(biāo)的周期性預(yù)測。

那么問題來了，機(jī)器學(xué)習(xí)異常預(yù)測與分布式架構(gòu)有何關(guān)系呢？根據(jù)我的理解，原本數(shù)據(jù)庫的負(fù)載預(yù)測是基于單機(jī)模式，而我們在考量集群分布式架構(gòu)時，需要從更全局的集群角度看待，定位短板，和單機(jī)模式是有很大的差別。從這個層面來說，如果我們有一些分布式體系的異常預(yù)測模型，我們就可以在此基礎(chǔ)上做更多工作。

?楊建榮?

競技世界 數(shù)據(jù)庫專家

dbaplus社群聯(lián)合發(fā)起人，騰訊云TVP，Oracle ACE，《Oracle DBA工作筆記》和《MySQL DBA工作筆記》作者；

現(xiàn)就職于競技世界，擅長數(shù)據(jù)管理、數(shù)據(jù)遷移、性能優(yōu)化，目前專注于開源技術(shù)、運(yùn)維自動化和性能優(yōu)化，堅持寫技術(shù)博客，已堅持2400多天。?