目前，在很多 OLTP 場景中，MySQL 數(shù)據(jù)庫都有著廣泛的應(yīng)用，也有很多不同的使用方式。

[[218387]]

從數(shù)據(jù)庫的業(yè)務(wù)需求、架構(gòu)設(shè)計(jì)、運(yùn)營維護(hù)、再到擴(kuò)容遷移，不同的 MySQL 架構(gòu)有不同的特點(diǎn)，適應(yīng)一定的業(yè)務(wù)場景，或者解決一定的業(yè)務(wù)問題。

DBA 作為數(shù)據(jù)庫架構(gòu)的設(shè)計(jì)、實(shí)施、維護(hù)人員，不僅要對(duì)各種 MySQL 架構(gòu)非常熟悉，還要了解業(yè)務(wù)，對(duì)于不同的業(yè)務(wù)有一定的劃分和認(rèn)識(shí)，并根據(jù)業(yè)務(wù)特點(diǎn)和架構(gòu)特點(diǎn)，合理選擇和使用 MySQL，滿足業(yè)務(wù)需求。

本文從以下三個(gè)方面對(duì) MySQL 數(shù)據(jù)庫和業(yè)務(wù)場景進(jìn)行探討和說明：

• MySQL 數(shù)據(jù)庫常見架構(gòu)
• 業(yè)務(wù)環(huán)境分類
• 業(yè)務(wù)與架構(gòu)結(jié)合使用原則

讓大家先分別對(duì) MySQL 的架構(gòu)和業(yè)務(wù)分類有所了解，然后再將兩者貫通起來，使得能夠在進(jìn)行業(yè)務(wù)與 MySQL 架構(gòu)設(shè)計(jì)時(shí)綱舉目張，讓用戶可以用合適的技術(shù)解決支撐業(yè)務(wù)需求。

MySQL 數(shù)據(jù)庫常見架構(gòu)

為了對(duì) MySQL 數(shù)據(jù)庫常見架構(gòu)，能夠有比較清晰的認(rèn)識(shí)，下面先從 MySQL 三種通用基礎(chǔ)架構(gòu)、五種特殊需求架構(gòu)、架構(gòu)組合與綜合使用三個(gè)方面進(jìn)行說明。

MySQL 三種常見基礎(chǔ)架構(gòu)

MySQL 單實(shí)例架構(gòu)

MySQL 單實(shí)例，就是在服務(wù)器上部署一個(gè) MySQL 實(shí)例來對(duì)外提供服務(wù)，這是最開始接觸 MySQL 數(shù)據(jù)庫會(huì)使用的方式，也是常見學(xué)習(xí)、研究 MySQL 數(shù)據(jù)庫的使用方式。

MySQL 單實(shí)例的使用方式，是 MySQL 數(shù)據(jù)庫使用的***階段，通常這種情況下，MySQL 數(shù)據(jù)庫與應(yīng)用程序會(huì)在同一個(gè)服務(wù)器上。

這種方式主要好處就是部署和使用簡單，直接通過編譯安裝，或者二進(jìn)制包解壓安裝，很快就可以有一個(gè)可以使用的 MySQL 數(shù)據(jù)庫環(huán)境。

同時(shí)，這種方式，依賴性少，不需要依賴其他第三方工具或者軟件，維護(hù)和故障定位也比較容易。

熟悉和掌握好 MySQL 單實(shí)例環(huán)境的技能，也是維護(hù)其他 MySQL 架構(gòu)的基礎(chǔ)。

需要注意的是，MySQL 單實(shí)例在學(xué)習(xí)和開發(fā)環(huán)境可以使用一下，但這種方式的可用性和災(zāi)備性較弱，如果作為業(yè)務(wù)系統(tǒng)使用的數(shù)據(jù)庫，盡量不要用這種方式。

MySQL master-slave 主從架構(gòu)

MySQL master-slave 主從環(huán)境，是在 MySQL 單實(shí)例環(huán)境的基礎(chǔ)上，將 MySQL 進(jìn)行全庫備份，再恢復(fù)出一個(gè)或多個(gè) MySQL 實(shí)例。

通過 change maste r命令，指定新恢復(fù)出的 MySQL 實(shí)例，從那個(gè) MySQL 節(jié)點(diǎn)上讀取變化日志，并在本地應(yīng)用，使新恢復(fù)的實(shí)例與原來的 MySQL 實(shí)例數(shù)據(jù)保持一致。

所以，原來的數(shù)據(jù)一致變化的實(shí)例，叫 master 主節(jié)點(diǎn)；從 master 節(jié)點(diǎn)獲取日志，并在本地應(yīng)用，使數(shù)據(jù)與 master 階段保持一致的節(jié)點(diǎn)，叫 slave 從節(jié)點(diǎn)；這樣的架構(gòu)環(huán)境，就叫 master-slave 主從環(huán)境。

master-slave 主從環(huán)境，是 MySQL 數(shù)據(jù)庫非常具有特色的功能，也是 MySQL 數(shù)據(jù)庫應(yīng)用在生產(chǎn)環(huán)境的常見架構(gòu)。

通過 master-slave 架構(gòu)，就可以使線上數(shù)據(jù)庫的數(shù)據(jù)有了多份，起到了一定的數(shù)據(jù)備份功能。

Slave 從庫數(shù)據(jù)變化只通過應(yīng)用日志實(shí)現(xiàn)，一般不會(huì)主動(dòng)產(chǎn)生寫數(shù)據(jù)的情況，但可以提供對(duì)外數(shù)據(jù)讀服務(wù)，這樣通過增加幾個(gè) slave 從庫，讓只進(jìn)行數(shù)據(jù)讀取的業(yè)務(wù)到 slave 從庫上查詢，可以大大提高業(yè)務(wù)的讀性能和吞吐量。

在互聯(lián)網(wǎng)行業(yè)中，非常多的數(shù)據(jù)讀操作遠(yuǎn)高于數(shù)據(jù)寫操作的業(yè)務(wù)場景，通過在 master 主節(jié)點(diǎn)寫數(shù)據(jù)，在 slave 節(jié)點(diǎn)上讀數(shù)據(jù)，進(jìn)行這種讀寫分離的架構(gòu)，可以很好地滿足業(yè)務(wù)需求。

當(dāng)然，MySQL 的 master-slave 主從架構(gòu)，具體實(shí)現(xiàn)也可以非常靈活，1 個(gè) master 主節(jié)點(diǎn)，可以有 1 個(gè)或多個(gè) slave 從節(jié)點(diǎn)。

而一個(gè) slave 節(jié)點(diǎn)，也可以當(dāng)做其他節(jié)點(diǎn)的 slave 節(jié)點(diǎn)，如果一個(gè) slave 節(jié)點(diǎn)后面再有其他節(jié)點(diǎn)當(dāng)做這個(gè)節(jié)點(diǎn)的 slave 從節(jié)點(diǎn)，就叫做級(jí)聯(lián)復(fù)制。

MySQL 的 master-save 架構(gòu)，在 MySQL 單實(shí)例架構(gòu)的基礎(chǔ)上，提高了 MySQL 數(shù)據(jù)庫的性能、可用性和可擴(kuò)展性，同時(shí)也為 MySQL 數(shù)據(jù)庫追求更高的可用性，提供了基礎(chǔ)保障。

MySQL MHA 高可用架構(gòu)

雖然 MySQL 數(shù)據(jù)庫的 master-salve 主從架構(gòu)，使數(shù)據(jù)庫有了多份，但這些 maste 主節(jié)點(diǎn)和 slave 從節(jié)點(diǎn)之間，仍然是相對(duì)獨(dú)立的，尤其是 master 主節(jié)點(diǎn)如果出現(xiàn)故障了，仍然是不能對(duì)外提供數(shù)據(jù)庫服務(wù)的。

為了應(yīng)對(duì)各種故障和特殊情況，實(shí)現(xiàn)數(shù)據(jù)庫更高的可用性，就需要在 master-slave 的基礎(chǔ)上，通過其他組件來實(shí)現(xiàn)更高的可用性。

MySQL 高可用性的方案比較多，但目前比較主流、比較成熟的方案，還是 MySQL + MHA 高可用架構(gòu)。

簡單來說，為了實(shí)現(xiàn)更高的可用性，就要在 master-slave 主從環(huán)境的基礎(chǔ)上，將業(yè)務(wù)連接 master 的 IP，有 master 主機(jī)的實(shí)際 IP，變成虛擬的 VIP 或者域名。

應(yīng)用程序通過 VIP 訪問數(shù)據(jù)庫，進(jìn)行數(shù)據(jù)讀寫，在正常情況下，業(yè)務(wù)在 master 上進(jìn)行讀寫；如果 master 節(jié)點(diǎn)出現(xiàn)故障，高可用組件會(huì)監(jiān)測到這個(gè)故障，并將 VIP 切換到 slave 從庫上。

同時(shí)在 slave 從庫上進(jìn)行日志的傳輸和應(yīng)用，保證 slave 上的數(shù)據(jù)，與 master 節(jié)點(diǎn)故障前的數(shù)據(jù)盡量一致，這樣切換后新的 slave 節(jié)點(diǎn)就仍然可以對(duì)外提供數(shù)據(jù)庫服務(wù)。

當(dāng)然，對(duì)于具體實(shí)現(xiàn)來說，在 MySQL 的 master-slave 主從結(jié)構(gòu)外，VIP 和數(shù)據(jù)庫日志追平的方案也是有多種實(shí)現(xiàn)方式，也可進(jìn)行各種深入定制，甚至一些公司不使用開源軟件，直接自己開發(fā)來實(shí)現(xiàn)高可用組件的各個(gè)功能。

目前 MySQL + MHA 這種高可用實(shí)現(xiàn)方式，是比較主流和成熟的實(shí)現(xiàn)方式，后面也可能會(huì)有一些其他更加完善的高可用實(shí)現(xiàn)方式，但都可以歸類到實(shí)現(xiàn)提高可用性這個(gè)范圍。

小結(jié)：對(duì)于 MySQL 數(shù)據(jù)庫的各種通用性需求，這三種基礎(chǔ)架構(gòu)都可以很好地滿足，換句話說，這是 MySQL 數(shù)據(jù)庫架構(gòu)中必須要用到和掌握的三種基礎(chǔ)架構(gòu)。

五種特殊業(yè)務(wù)需求架構(gòu)

通過 MySQL 中這三種常見基礎(chǔ)架構(gòu)，絕大多數(shù) MySQL 數(shù)據(jù)庫場景和問題，都可以很好得到滿足和解決。

但一些特殊的場景，或一些特殊的問題，也可以使用除 MySQL 數(shù)據(jù)庫以外的其他數(shù)據(jù)庫、專門某一類或幾類問題的解決方案。

針對(duì)這些特殊的業(yè)務(wù)需求，接下來我會(huì)先從要解決的問題進(jìn)行描述和說明，然后再提出對(duì)應(yīng)的解決方案。

MySQL + 分布式 Proxy 水平擴(kuò)展架構(gòu)

問題：如果業(yè)務(wù)規(guī)模進(jìn)一步擴(kuò)大，讀寫量級(jí)尤其是寫的量級(jí)達(dá)到非常大的地步。

比如每秒數(shù)據(jù)寫入幾十萬，甚至幾百萬，每天的數(shù)據(jù)量有幾億甚至幾十億的規(guī)模，這樣的讀寫就遠(yuǎn)遠(yuǎn)不是一個(gè) master 節(jié)點(diǎn)可以支撐的，這時(shí)就必須要進(jìn)行擴(kuò)展了。

一般來說，MySQL 的擴(kuò)展可分為：按照不同業(yè)務(wù)進(jìn)行垂直拆分的垂直擴(kuò)展，和通過一定的分庫分表策略實(shí)現(xiàn)的庫表水平擴(kuò)展兩種方式。

這兩種方式可以單獨(dú)使用，也可以結(jié)合使用。但如果是解決大量數(shù)據(jù)和高并發(fā)讀寫，主要方式還是 MySQL 水平擴(kuò)展。

MySQL 水平擴(kuò)展的思路：在一個(gè)服務(wù)器上的 database 庫和 table 表，總會(huì)受到一臺(tái)服務(wù)器的資源限制，即使服務(wù)器的硬件各方面都達(dá)到頂配，也還是會(huì)有瓶頸。

對(duì)于業(yè)務(wù)訪問來說，如果有一個(gè) Proxy 代理層或者中間件層的一個(gè) database 和一個(gè) table，通過代理層按照一定的規(guī)則映射和轉(zhuǎn)換，轉(zhuǎn)換成底層多臺(tái)服務(wù)器上的多個(gè) database 和多個(gè) table，這樣就相當(dāng)于多臺(tái)服務(wù)器共同支撐一個(gè)業(yè)務(wù)，可支持的容量就與底層服務(wù)器的數(shù)量有關(guān)。

在 Proxy 代理沒有到瓶頸的情況下，底層服務(wù)器數(shù)量越多，整個(gè)水平擴(kuò)展集群的性能和容量也會(huì)越多，幾乎可以線性擴(kuò)展。通過這樣的思路，就可以解決大量數(shù)據(jù)存儲(chǔ)和并發(fā)的問題。

具體實(shí)現(xiàn)來說，水平擴(kuò)展集群除了 MySQL 數(shù)據(jù)庫，需要一個(gè)分布式 Proxy 中間件，這種水平擴(kuò)展中間件種類也比較多，MySQL 官方和一些大的的公司都有開發(fā)。

我們用的比較多的是 MyCAT 中間件，對(duì)于底層的分片，可以有幾十個(gè)、幾百個(gè)甚至幾千個(gè)。

當(dāng)然，水平擴(kuò)展可以解決大數(shù)據(jù)量的問題，需要有分片策略，那相應(yīng)地，也會(huì)有使用這種策略的限制，比如片鍵選擇，跨節(jié)點(diǎn)訪問，分布式事務(wù)等問題，需要與業(yè)務(wù)進(jìn)行對(duì)應(yīng)結(jié)合和考慮后，才可以很好地使用。

TokuDB/MyRocks/InnoDB 高性能寫入架構(gòu)

問題：MySQL 數(shù)據(jù)庫水平拆分，可以對(duì)于大數(shù)據(jù)量的讀寫進(jìn)行線性擴(kuò)展，相應(yīng)地底層服務(wù)器數(shù)量也需要比較多。

但對(duì)于數(shù)據(jù)寫入量非常大，數(shù)據(jù)讀很少，數(shù)據(jù)總量大的情況，使用高性能寫入架構(gòu)，會(huì)更合適一些。

業(yè)務(wù)數(shù)據(jù)寫入量非常大，讀取量非常高的情況，一般主要對(duì)數(shù)據(jù) insert 寫入性能，同時(shí)對(duì)數(shù)據(jù)壓縮效率有特別高的要求。

這種特殊的寫入要求，需要對(duì)數(shù)據(jù)寫入有特殊的優(yōu)化和設(shè)計(jì)，并且有比較好的壓縮效率和算法，能夠?qū)懭氲拇罅繑?shù)據(jù)進(jìn)行壓縮，節(jié)省空間。這種寫入架構(gòu)， 通?？梢钥醋鍪?MySQL 數(shù)據(jù)庫的一種特殊的存儲(chǔ)引擎。

具體到實(shí)現(xiàn)而言，MySQL 的高性能寫入集群，可以使用 TokuDB 存儲(chǔ)引擎。近幾年 Facebook 也開源了其內(nèi)部實(shí)現(xiàn)的 MyRocks，可以作為高性能寫入的存儲(chǔ)引擎。

MySQL 默認(rèn)的 InnoDB 存儲(chǔ)引擎，在新的 5.7 及以后版本優(yōu)化后，寫入性能和壓縮性能也有了更高的性能，也可以作為數(shù)據(jù)寫入的一種選擇。

MySQL + 緩存（Memcached、Redis等） 高并發(fā)讀架構(gòu)

問題：如果業(yè)務(wù)訪問 MySQL 中的某一些少量熱數(shù)據(jù)，訪問的并發(fā)量非常高，訪問的時(shí)效性，數(shù)據(jù)的一致性要求都非常高。

這時(shí)候使用 MySQL 數(shù)據(jù)庫本身支持這些數(shù)據(jù)讀取，可能會(huì)在并發(fā)性、時(shí)效性上出現(xiàn)瓶頸，所以就可以使用緩存系統(tǒng)結(jié)合 MySQL 來使用。

緩存系統(tǒng)是將 MySQL 數(shù)據(jù)庫中的少量熱數(shù)據(jù)存放到內(nèi)存當(dāng)中，由于內(nèi)存的 IO 效率遠(yuǎn)高于硬盤的 IO，相應(yīng)的 CPU 消耗也會(huì)少很多，這樣緩存系統(tǒng)中響應(yīng)一次業(yè)務(wù)請(qǐng)求的時(shí)間，會(huì)遠(yuǎn)少于直接從 MySQL 數(shù)據(jù)庫訪問需要的時(shí)間。

于是緩存系統(tǒng)就可以支撐熱數(shù)據(jù)的高并發(fā)訪問，數(shù)據(jù)寫還是寫入 MySQL 數(shù)據(jù)庫中，數(shù)據(jù)讀操作，優(yōu)先讀取緩存。

如果緩存中有，則直接從緩存中返回結(jié)果；如果緩存中沒有，則從 MySQL 數(shù)據(jù)庫中讀取數(shù)據(jù)返回應(yīng)用，并把數(shù)據(jù)結(jié)果再放到緩存的內(nèi)容中。

具體實(shí)現(xiàn)來說，緩存系統(tǒng)常用的技術(shù)架構(gòu)有 Memcached 和 Redis：

• Memcached 是比較經(jīng)典的緩存系統(tǒng)，在之前常與 LAMP、LNMP 流行架構(gòu)結(jié)合使用。
• Redis 是幾年新興的 Key-Value 鍵值型 NoSQL 數(shù)據(jù)庫，除了作為緩存，還可以持久化作為 Key-Value 數(shù)據(jù)庫使用。

MySQL + 小文件系統(tǒng)（MongoDB、Ceph等） 大字段存取架構(gòu)

問題：在 MySQL 數(shù)據(jù)庫中，通常是存儲(chǔ)符合關(guān)系型數(shù)據(jù)庫原理的小字段，比如數(shù)值型、字符型數(shù)據(jù)。

但在實(shí)際環(huán)境中，除了這些常用字段，還會(huì)有一些大字段，比如用戶頭像這種圖片文件、上傳的音頻、視頻文件、帖子內(nèi)容等大 text 字段，另外還有一些 JSON 文件、XML 文件等。

這些可以以二進(jìn)制形式存儲(chǔ)在 MySQL 數(shù)據(jù)庫中，但讀取和管理都會(huì)比較麻煩。這時(shí)，就可以使用小文件系統(tǒng)來結(jié)合 MySQL 來使用。

小文件系統(tǒng)，是可以存儲(chǔ)并快速訪問結(jié)構(gòu)化數(shù)據(jù)的系統(tǒng)。對(duì)于圖片、音頻、視頻、TXT 文件、JSON 文件、XML 文件等大字段，一般就只有簡單的讀寫操作，將這些字段存入到小文件系統(tǒng)中，并將對(duì)應(yīng)的訪問鏈接存入到 MySQL 數(shù)據(jù)庫的表中。

這樣通過數(shù)據(jù)庫表，可以快速讀寫文件位置信息，在小文件系統(tǒng)中，通過文件位置信息，可以實(shí)現(xiàn)對(duì)大字段的快速讀寫訪問。

具體實(shí)現(xiàn)而言，小文件系統(tǒng)也有很多技術(shù)軟件，比較常見的有 MongoDB 文檔型 NoSQL 數(shù)據(jù)庫、Ceph 分布式小文件系統(tǒng)等。

MySQL + Inforbright/Greenplum 統(tǒng)計(jì)分析架構(gòu)

問題：在 MySQL 數(shù)據(jù)庫上實(shí)時(shí)響應(yīng)業(yè)務(wù)需要的查詢，通常是指 OLTP 業(yè)務(wù)，但對(duì)于已經(jīng)產(chǎn)生的數(shù)據(jù)，通常會(huì)在第二天之后，有結(jié)果匯總和統(tǒng)計(jì)分析需求。

這類 OLAP 需求通常執(zhí)行頻率較低，但每次執(zhí)行消耗的資源很大，如果與 OLTP 一樣在一個(gè)系統(tǒng)上運(yùn)行，就會(huì)造成這兩大類業(yè)務(wù)的相互影響。這時(shí)就可以使用 MySQL 數(shù)據(jù)庫與 OLAP 統(tǒng)計(jì)業(yè)務(wù)分類結(jié)合的架構(gòu)。

MySQL 產(chǎn)生了業(yè)務(wù)數(shù)據(jù)后，通常需要在第二天，要對(duì)前一天的數(shù)據(jù)進(jìn)行各個(gè)角度、各個(gè)維度的統(tǒng)計(jì)、聚合、分析，以體現(xiàn)和反映業(yè)務(wù)的運(yùn)營情況。

這是讓 MySQL 支持線上 OLTP 業(yè)務(wù)，通過數(shù)據(jù)流轉(zhuǎn)程序，將每天產(chǎn)生的數(shù)據(jù)流轉(zhuǎn)到離線的數(shù)據(jù)倉庫系統(tǒng)中，在數(shù)據(jù)倉庫系統(tǒng)中，進(jìn)行各種數(shù)據(jù)統(tǒng)計(jì)分析、結(jié)果匯總，并將數(shù)據(jù)統(tǒng)計(jì)結(jié)果再流轉(zhuǎn)到結(jié)果展示庫中。這樣就可以很好地實(shí)現(xiàn)線上 OLTP 和線下 OLAP 的結(jié)合使用和執(zhí)行。

具體實(shí)現(xiàn)而言，對(duì)于 MySQL 數(shù)據(jù)庫可以結(jié)合的 OLAP 數(shù)據(jù)倉庫架構(gòu)，可以選用 Inforbright 數(shù)據(jù)倉庫，也可以選用 Greenplum 分布式 MPP 數(shù)據(jù)庫倉庫。

相對(duì)而言，Inforbright 數(shù)據(jù)倉庫比較輕量級(jí)，與 MySQL 使用類似；Greenplum 分布式 MPP 數(shù)據(jù)倉庫可以支撐海量數(shù)據(jù)的統(tǒng)計(jì)分析，功能、性能、容量等也比 Inforbright 要更強(qiáng)一下，成本也更大一些。

小結(jié)：MySQL 五種特殊業(yè)務(wù)架構(gòu)，可以說是在 MySQL 三種常見的、通用的架構(gòu)基礎(chǔ)上，面對(duì)特殊的業(yè)務(wù)場景，遇到特殊的問題，進(jìn)行針對(duì)性解決：

• 對(duì)于大量數(shù)據(jù)讀寫，可以采用水平擴(kuò)展架構(gòu)。
• 對(duì)于有大量數(shù)據(jù)寫入需求，可以采用 MySQL 高性能寫入架構(gòu)。
• 對(duì)于熱數(shù)據(jù)的高并發(fā)、快速響應(yīng)的需求，可以采用 MySQL+緩存架構(gòu)。
• 對(duì)于特殊的大字段存取需求，可以采用 MySQL+小文件系統(tǒng)架構(gòu)。
• 對(duì)于離線統(tǒng)計(jì)分析需求，可以采用 MySQL+統(tǒng)計(jì)分析架構(gòu)。

架構(gòu)組合與綜合使用

MySQL 三種比較通用的基礎(chǔ)架構(gòu)和五種特殊需求架構(gòu)，都可以根據(jù)場景單獨(dú)使用，也可以根據(jù)特定的場景進(jìn)行組合幾種架構(gòu)使用，或者綜合起來一起使用。

架構(gòu)組合

對(duì)于只有一兩種特殊情況的架構(gòu)，選擇基礎(chǔ)架構(gòu)和特殊架構(gòu)的簡單組合就可以了，生產(chǎn)環(huán)境中可用到的架構(gòu)組合類型有：

• MySQL+MHA 高可用架構(gòu)與 MySQL 分布式 Proxy 水平擴(kuò)展架構(gòu)組合。
• MySQL+MHA 高可用架構(gòu)與 MySQL 小文件系統(tǒng)大字段存取架構(gòu)組合。
• MySQL+MHA 高可用架構(gòu)與 MySQL 緩存高并發(fā)讀架構(gòu)組合。
• MySQL 分布式 Proxy 水平擴(kuò)展架構(gòu)與 MySQL 小文件系統(tǒng)大字段存取架構(gòu)組合。
• MySQL 分布式 Proxy 水平擴(kuò)展架構(gòu)與 MySQL 緩存高并發(fā)讀架構(gòu)組合。
• MySQL 高性能寫入架構(gòu)與 MySQL Inforbright/Greenplum 統(tǒng)計(jì)分析架構(gòu)組合。

架構(gòu)綜合

如果是比較復(fù)雜的業(yè)務(wù)場景，幾種特殊的數(shù)據(jù)庫架構(gòu)可以綜合起來使用：

MySQL+MHA 高可用架構(gòu) 、MySQL 分布式 Proxy 水平擴(kuò)展架構(gòu)、MySQL 緩存高并發(fā)讀架構(gòu)、MySQL 小文件系統(tǒng)大字段存取架構(gòu)、MySQL  Inforbright/Greenplum 統(tǒng)計(jì)分析架構(gòu)。

業(yè)務(wù)環(huán)境分類

***部分對(duì) MySQL 的架構(gòu)進(jìn)行了說明，這是對(duì) MySQL 數(shù)據(jù)庫本身的了解，算作“知己”。

所有的數(shù)據(jù)庫系統(tǒng)提供服務(wù)的對(duì)象都是業(yè)務(wù)系統(tǒng)，所以 DBA 要對(duì)業(yè)務(wù)系統(tǒng)進(jìn)行了解，對(duì)業(yè)務(wù)的特點(diǎn)和適合的場景，做到心中有數(shù)，可以算作是“知彼”。做到知己知彼，就能更好地貫通兩者了。

從數(shù)據(jù)庫使用推導(dǎo)數(shù)據(jù)使用分類

從數(shù)據(jù)庫操作角度看，業(yè)務(wù)系統(tǒng)對(duì)于數(shù)據(jù)庫的操作，大的方面可以分為“讀數(shù)據(jù)”和“寫數(shù)據(jù)”兩類。

展開來說，寫數(shù)據(jù)也可以具體分為：insert 插入數(shù)據(jù)、update 修改數(shù)據(jù)、delete 刪除數(shù)據(jù)三種情況。

所以，數(shù)據(jù)庫的使用也可以細(xì)分為：增 insert、刪 delete、改 update、查 select 四種情況。

依據(jù)業(yè)務(wù)系統(tǒng)對(duì)數(shù)據(jù)的操作分類，就可以對(duì)業(yè)務(wù)系統(tǒng)進(jìn)行歸類：

只讀業(yè)務(wù)系統(tǒng)

只讀是指只有查詢 select，沒有數(shù)據(jù)修改的情況。這種情況，是數(shù)據(jù)庫中已經(jīng)存在一些數(shù)據(jù)，并且這些數(shù)據(jù)只作查詢或展示用，不會(huì)有任何數(shù)據(jù)變化。

比如緩存中的數(shù)據(jù)、歸檔后的數(shù)據(jù)、歷史結(jié)果數(shù)據(jù)、統(tǒng)計(jì)結(jié)果數(shù)據(jù)等，都是只能進(jìn)行查詢和展示，不會(huì)再發(fā)生數(shù)據(jù)變化的。

可讀寫業(yè)務(wù)系統(tǒng)

按照寫操作的具體情況，可以對(duì)可讀寫業(yè)務(wù)系統(tǒng)分成三類：

• 只有插入 insert，沒有 update 和 delete 的可讀寫業(yè)務(wù)系統(tǒng)，這種情況是指數(shù)據(jù)表的數(shù)據(jù)只會(huì)增加，且表中的數(shù)據(jù)不能再變化，不會(huì)再有修改或者刪除操作；比如操作記錄表、狀態(tài)變化記錄表、留言記錄表等。
• 有 insert 和 update，沒有 delete 的可以讀寫業(yè)務(wù)系統(tǒng)，這種情況是指數(shù)據(jù)表中的數(shù)據(jù)，可以進(jìn)行增加和修改，但數(shù)據(jù)一旦產(chǎn)生，可以變化，但不能修改。

這也是一種常見的數(shù)據(jù)庫設(shè)計(jì)思路，即數(shù)據(jù)表可以有失效，但生效刪除，并不是真正從數(shù)據(jù)表中刪除，而是修改了表中表示狀態(tài)位的列值，這樣就可以保證數(shù)據(jù)一直具有可回溯性。

• insert、update、delete 都有的可讀寫業(yè)務(wù)系統(tǒng)，這種情況是指數(shù)據(jù)表中的數(shù)據(jù)可進(jìn)行各種操作，可以查詢，也可以進(jìn)行各種變化，添刪改除各種操作也都可以進(jìn)行。

常見業(yè)務(wù)表分類

從業(yè)務(wù)角度對(duì)表進(jìn)行分類，雖然不同的應(yīng)用程序?qū)Ρ淼氖褂貌煌?，但還是能夠抽象成為幾大類表。

配置表

這種表通常存放業(yè)務(wù)一些基礎(chǔ)的配置信息或者字典信息。表的數(shù)據(jù)量一般都比較小，修改變化的操作不太頻繁，通常都是 select 查詢操作。

狀態(tài)表

這種表通常存放在業(yè)務(wù)系統(tǒng)中實(shí)體讀象的狀態(tài)信息，常見的有用戶信息表，訂單信息表等。這種表的數(shù)據(jù)量與實(shí)體讀象的規(guī)模有直接關(guān)系，比如一個(gè) APP 有多少注冊(cè)用戶，通常這個(gè) APP 的用戶表都會(huì)有多少條記錄。

狀態(tài)表的變化通常比較頻繁，而且 insert、update、select 操作都會(huì)有，delete 操作是否有，通常會(huì)根據(jù)業(yè)務(wù)情況的規(guī)定決定。

日志表

這種表通常用來記錄業(yè)務(wù)系統(tǒng)中某種實(shí)體的狀態(tài)信息，常見的有用戶登錄表、充值信息記錄表等。

這種表的數(shù)據(jù)規(guī)模通常比較大，而且如果業(yè)務(wù)狀態(tài)變化頻繁，記錄的變化信息比較多，這種表的數(shù)據(jù)量和插入性能都要求比較高。

日志表的操作，通常會(huì)以 insert 操作為主，個(gè)別業(yè)務(wù)會(huì)對(duì)日志表進(jìn)行查詢。MySQL 五種特殊需求架構(gòu)中的高性能寫入架構(gòu)，主要就是應(yīng)用這種表的需求。

歸檔表

這種表，是將上面三種 OLTP 業(yè)務(wù)表的數(shù)據(jù)進(jìn)行歸檔或者冷熱分離的表。對(duì)線上業(yè)務(wù)三類表進(jìn)行數(shù)據(jù)歸檔、冷熱分離。

一方面可以控制線上業(yè)務(wù)表的數(shù)據(jù)規(guī)模，保證業(yè)務(wù)表性能；另一方面進(jìn)行歸檔后，可用于對(duì)歸檔歷史數(shù)據(jù)進(jìn)行更好的查詢反映和支持。

歸檔表的數(shù)據(jù)量大小與對(duì)應(yīng)的線上表大小、歸檔周期有關(guān)。歸檔表的操作，除了歸檔過程的數(shù)據(jù)加載外，主要就是 select 查詢操作了，歸檔后就算是只讀表。

統(tǒng)計(jì)數(shù)據(jù)表

統(tǒng)計(jì)數(shù)據(jù)表，是指業(yè)務(wù)有離線統(tǒng)計(jì)分析需求時(shí)，需要將各種線上表和歸檔表的數(shù)據(jù)，通過ETL過程流轉(zhuǎn)到線上 OLAP 統(tǒng)計(jì)分析系統(tǒng)中的原始數(shù)據(jù)表。

這類表通常數(shù)據(jù)量會(huì)非常大，一個(gè) OLAP 統(tǒng)計(jì)分析平臺(tái)會(huì)匯總多個(gè)線上業(yè)務(wù)系統(tǒng)的數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析。統(tǒng)計(jì)數(shù)據(jù)表的操作，除了數(shù)據(jù)流轉(zhuǎn)動(dòng)作外，主要就是各種統(tǒng)計(jì)分析程序的訪問計(jì)算。

統(tǒng)計(jì)結(jié)果表

統(tǒng)計(jì)結(jié)果表是在業(yè)務(wù)有離線統(tǒng)計(jì)分析需求時(shí)，各種統(tǒng)計(jì)分析過程訪問統(tǒng)計(jì)數(shù)據(jù)表中的數(shù)據(jù)，按照一定的邏輯進(jìn)行統(tǒng)計(jì)分析后的結(jié)果數(shù)據(jù)。

這種統(tǒng)計(jì)結(jié)果數(shù)據(jù)，通常數(shù)據(jù)量會(huì)比較小。統(tǒng)計(jì)結(jié)果表的操作，處理結(jié)果流轉(zhuǎn)動(dòng)作外，主要就是供訪問接口進(jìn)行 select 查詢。

通過對(duì)業(yè)務(wù)表類型的梳理，可以對(duì)所有的業(yè)務(wù)系統(tǒng)進(jìn)行一個(gè)大體的劃分，做到心中有數(shù)。

DBA 對(duì)業(yè)務(wù)的把握

通過數(shù)據(jù)使用方式將業(yè)務(wù)系統(tǒng)劃分為四類，再通過業(yè)務(wù)常見表類型劃分，就可以對(duì)通用的業(yè)務(wù)使用數(shù)據(jù)庫有一個(gè)整體的了解。但對(duì)于具體的業(yè)務(wù)場景，還需要根據(jù)每個(gè)公司具體的實(shí)際情況進(jìn)行具體確認(rèn)和考慮。

大多數(shù)情況下，某一種具體的業(yè)務(wù)都可以根據(jù)情況歸入某一種業(yè)務(wù)類型中，只是每個(gè)業(yè)務(wù)具體的量級(jí)會(huì)有不同，大家需要先了解具體業(yè)務(wù)環(huán)境中的量級(jí)，再根據(jù)業(yè)務(wù)類型與 MySQL 架構(gòu)的使用情況，進(jìn)行對(duì)應(yīng)就可以了。

如果實(shí)際環(huán)境中確認(rèn)有不在現(xiàn)有分類中的情況，則可以通過現(xiàn)有的思路，進(jìn)行新的類型劃分和架構(gòu)對(duì)應(yīng)。

業(yè)務(wù)與架構(gòu)結(jié)合使用原則

上面兩部分通過對(duì) MySQL 各種架構(gòu)進(jìn)行說明，并通過對(duì)業(yè)務(wù)環(huán)境的分類，可以讓大家對(duì) MySQL 架構(gòu)和業(yè)務(wù)環(huán)境本身有一定的了解。

下面我將就我在架構(gòu)設(shè)計(jì)和運(yùn)維當(dāng)中兩者結(jié)合的使用原則，對(duì) MySQL 業(yè)務(wù)和架構(gòu)的結(jié)合使用進(jìn)行說明。

適用性原則

適用性原則就是在考慮某一個(gè)具體業(yè)務(wù)場景具體使用哪一種或者幾種業(yè)務(wù)場景時(shí)，我們要盡量使用合適的技術(shù)架構(gòu)解決合適的問題。

需求與場景

MySQL 的三種通用基礎(chǔ)架構(gòu)，適用的場景多一些。但通用業(yè)務(wù)場景在數(shù)據(jù)量級(jí)、訪問規(guī)模、讀寫方式等發(fā)生比較大的變化時(shí)，就變成了有特殊需求的場景，可以考慮使用某種特定場景對(duì)應(yīng)的 MySQL 架構(gòu)技術(shù)，盡量保證適用性。

反之，如果實(shí)際業(yè)務(wù)在量級(jí)、規(guī)模、讀寫方式還沒有達(dá)到非常特殊的場景時(shí)，盡量使用通用的基礎(chǔ)架構(gòu)就可以滿足業(yè)務(wù)需求，也可以降低系統(tǒng)復(fù)雜度和隱患。

整體與部分

不論對(duì)于一個(gè)業(yè)務(wù)系統(tǒng)，還是 MySQL 數(shù)據(jù)庫架構(gòu)而言，都要從整體和部分兩個(gè)角度進(jìn)行看待和考慮。

一個(gè)業(yè)務(wù)系統(tǒng)，首先是一個(gè)整體，從整體上看各種業(yè)務(wù)需求和使用方式，把握好整體，然后再考慮具體的需求。

如果沒有特殊的需求，則可以按照通用場景來設(shè)計(jì)和考慮；如果某一部分有特殊的需求，則可以把這部分內(nèi)容單獨(dú)劃分出來，進(jìn)行對(duì)應(yīng)的架構(gòu)設(shè)計(jì)。

多個(gè)通用和特殊的架構(gòu)，相互組合，完成一個(gè)對(duì)業(yè)務(wù)系統(tǒng)支撐的架構(gòu)總體。

穩(wěn)定與升級(jí)

一般情況下，業(yè)務(wù)系統(tǒng)都是先用通用架構(gòu)進(jìn)行數(shù)據(jù)支持，在通用架構(gòu)適用時(shí)，業(yè)務(wù)系統(tǒng)也可以穩(wěn)定運(yùn)行。

在業(yè)務(wù)系統(tǒng)不斷運(yùn)行過程中，有新業(yè)務(wù)場景需求產(chǎn)生時(shí)，要綜合考慮保證現(xiàn)有業(yè)務(wù)穩(wěn)定性、以及升級(jí)業(yè)務(wù)系統(tǒng)到新架構(gòu)的步驟和階段。

一般不要一下子全部升級(jí)，建議采用先測試、再上線、分批次逐步過渡和升級(jí)的方式。

階段性原則

業(yè)務(wù)系統(tǒng)的發(fā)展是有階段的，MySQL 數(shù)據(jù)庫架構(gòu)的發(fā)展也是有階段的。不同階段關(guān)注的信息和主要處理思路都是不同的，從不同維度考慮階段性也是使用架構(gòu)和業(yè)務(wù)的重要原則。

數(shù)量階段

數(shù)量是一個(gè)比較明顯的階段判斷指標(biāo)。業(yè)務(wù)系統(tǒng)通常會(huì)有 DAU、UV、PV 等指標(biāo)，來幫助判斷業(yè)務(wù)系統(tǒng)的規(guī)模。

數(shù)據(jù)庫系統(tǒng)、QPS、TPS、一個(gè)表的數(shù)據(jù)量、一個(gè)庫下的表數(shù)量、一個(gè)實(shí)例下的庫數(shù)量、總的實(shí)例數(shù)量、服務(wù)器數(shù)量，都是與架構(gòu)結(jié)合比較緊密的指標(biāo)。

以表數(shù)據(jù)量舉例：如果一個(gè)表運(yùn)行一年，數(shù)量在 10 萬以下，就可以認(rèn)為是小表了；數(shù)據(jù)量在 10 萬-1000 萬以上的，可以認(rèn)為是中表。

數(shù)據(jù)量在 1000 萬以上，就可以認(rèn)為是大表，這時(shí)就需要考慮歸檔或水平拆分了；如果數(shù)據(jù)量在 1 億以上，就必須要用特殊架構(gòu)進(jìn)行單獨(dú)處理了。

統(tǒng)一組織

在業(yè)務(wù)規(guī)模和數(shù)據(jù)規(guī)模都比較小的時(shí)候，若存在多種不同的架構(gòu)，還是可以維護(hù)的。

但如果數(shù)據(jù)庫實(shí)例數(shù)量和業(yè)務(wù)模塊都大起來之后，統(tǒng)一一種或少數(shù)幾種數(shù)據(jù)架構(gòu)就非常重要了。統(tǒng)一架構(gòu)組織，可以讓業(yè)務(wù)系統(tǒng)和架構(gòu)，更加容易控制和維護(hù)。

規(guī)?？刂?/strong>