打通MySQL架構和業務的任督二脈

標籤：連網   資料架構   width   成本   表拆分   通用   bdr   官方   sbt   

目前，在很多OLTP情境中，MySQL資料庫都有著廣泛的應用，也有很多不同的使用方式。從資料庫的業務需求、架構設計、運營維護、再到擴容遷移，不同的MySQL架構有不同的特點，適應一定的業務情境，或者解決一定的業務問題。

 

DBA作為資料庫結構描述的設計、實施、維護人員，不僅要對各種MySQL架構非常熟悉，還要瞭解業務，對於不同的業務有一定的劃分和認識，並根據業務特點和架構特點，合理選擇和使用MySQL，滿足業務需求。

 

本文從MySQL常見架構、業務環境分類、業務與架構結合使用原則三個方面對MySQL資料庫和業務情境進行探討和說明，讓大家先分別對MySQL的架構和業務分類有所瞭解，然後再將兩者貫通起來，使得能夠在進行業務與MySQL架構設計時綱舉目張，讓使用者可以用合適的技術解決支撐業務需求。

一、MySQL資料庫常見架構

為了對MySQL資料庫常見架構，能夠有進行比較清晰的認識，下面先從MySQL三種通用基礎架構、五種特殊需求架構、架構組合與綜合使用三個方面進行說明。

1、 MySQL三種常見基礎架構

（1）MySQL單一實例架構

MySQL單一實例，就是在伺服器上部署一個MySQL執行個體來對外提供服務，這是最開始接觸MySQL資料庫會使用的方式，也是常見學習、研究MySQL資料庫的使用方式。

MySQL單一實例的使用方式，是MySQL資料庫使用的第一階段，通常這種情況下，MySQL資料庫與應用程式會在同一個伺服器上。

 

這種方式主要好處就是部署和使用簡單，直接通過編譯安裝，或者二進位包解壓安裝，很快就可以有一個可以使用的MySQL資料庫環境。同時，這種方式，依賴性少，不需要依賴其他第三方工具或者軟體，維護和故障定位也比較容易。

 

熟悉和掌握好MySQL單一實例環境的技能，也是維護其它MySQL架構的基礎。

需要注意的是，MySQL單一實例在學習和開發環境可以使用一下，但這種方式的可用性和災備性較弱，如果作為業務系統使用的資料庫，盡量不要用這種方式。

（2）MySQL master-slave主從架構

MySQL master-slave主從環境，是在MySQL單一實例環境的基礎上，將MySQL進行全庫備份，再恢複出一個或多個MySQL執行個體，通過change master命令，指定新恢複出的MySQL執行個體，從那個MySQL節點上讀取變化日誌，並在本地應用，使新恢複的執行個體與原來的MySQL執行個體資料一致保持一致。

 

所以，原來的資料一致變化的執行個體，叫master主節點；從master節點擷取日誌，並在本地應用，使資料與master階段保持一致的節點，叫slave從節點；這樣的架構環境，就叫 master-slave主從環境。

 

Master-slave主從環境，是MySQL資料庫非常具有特色的功能，也是MySQL資料庫應用在生產環境的常見架構。

 

通過master-slave架構，就可以使線上資料庫的資料有了多份，起到了一定的資料備份功能。Slave從庫資料變化只通過應用日誌實現，一般不會主動產生寫資料的情況，但可以提供對外資料讀服務，這樣通過增加幾個slave從庫，讓只進行資料讀取的業務到slave從庫上查詢，就都可以大大提高業務的讀效能和輸送量。在互連網行業中，非常多的資料讀操作遠高於資料寫操作的業務情境，通過在master主節點寫資料，在slave節點上讀資料，進行這種讀寫分離的架構，可以很好地滿足業務需求。

 

當然，MySQL的master-slave主從架構，具體實現也可以非常靈活，1個master主節點，可以有1個或多個slave從節點；而一個slave節點，也可以當做其它節點的slave節點，如果一個slave節點後面再有其它節點當做這個節點的slave從節點，就叫做級聯複製。

 

MySQL的master-save架構，在MySQL單一實例架構的基礎上，提高了MySQL資料庫的效能、可用性和可擴充性，同時也為MySQL資料庫追求更高的可用性，提供了基礎保障。

（3）MySQL MHA高可用架構

雖然MySQL資料庫的master-salve主從架構，使資料庫有了多份，但這些maste主節點和slave從節點之間，仍然是相對獨立的，尤其是master主節點如果出現故障了，仍然是不能對外提供資料庫服務的。為了應該各種故障和特殊情況，實現資料庫更高的可用性，就需要在master-slave的基礎上，通過其它組件來實現更高的可用性。

 

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

 

簡單來說，為了實現更高的可用性，就要在master-slave主從環境的基礎上，將Business Connectivitymaster的IP，有master主機的實際IP，變成虛擬VIP或者網域名稱。應用程式通過VIP訪問資料庫，進行資料讀寫，在正常情況下，業務在master上進行讀寫；如果master節點出現故障，高可用組件會監測到這個故障，並將VIP切換到slave從庫上，同時對於slave從庫上進行日誌的傳輸和應用，保證slave上的資料，與master節點故障前的資料盡量一致，這樣切換後新的slave節點就仍然可以對外提供資料庫服務。

 

當然，對於具體實現來說，在MySQL的master-slave主從結構外，VIP和資料庫日誌追平的方案也是有多種實現方式，也可進行各種深入定製，甚至一些公司不使用開源軟體，直接自己開發來實現高可用組件的各個功能。

 

目前MySQL + MHA這種高可用實現方式，是比較主流和成熟的實現方式，後面也可能會有一些其它更加完善的高可用實現方式，但都可以歸類到實現提高可用性這個範圍。

 

小結

這裡就介紹完了MySQL單一實例架構、MySQLmaster-slave主從架構、MySQL+MHA高可用架構，對於MySQL資料庫的各種通用性需求，這三種基礎架構都可以很好地滿足，換句話說，這是MySQL資料庫結構描述中必須要用到和掌握的三種基礎架構。

 

2、 五種特殊業務需求架構

通過MySQL中這三種常見基礎架構，絕大多數MySQL資料庫情境和問題，都可以很好得滿足和解決。但一些特殊的情境，或一些特殊的問題，也可以使用除MySQL資料庫以外的其它資料庫、專門某一類或幾類問題的解決方案。針對這些特殊的業務需求，接下來我會先從要解決的問題進行描述和說明，然後再提出對應的解決方案。

（1）MySQL + 分布式Proxy 水平擴充架構

問題：如果業務規模進一步擴大，讀寫量級尤其是寫的量級達到非常大的地步，比如每秒資料寫入幾十萬，甚至幾百萬，每天的資料量有幾億甚至幾十億的規模，這樣的讀寫就遠遠不是一個master節點可以支撐的，這時就必須要進行擴充了。

 

一般來說，MySQL的擴充可分為：按照不同業務進行垂直分割的垂直擴充，和通過一定的分庫分表策略實現的庫表水平擴充兩種方式。這兩種方式可以單獨使用，也可以結合使用。但如果是解決大量資料和高並發讀寫，主要方式還是MySQL水平擴充。

MySQL水平擴充的思路

在一個伺服器上的database庫和table表，總會受到一台伺服器的資源限制，即使伺服器的硬體各方面都達到頂配，也還是會有瓶頸。對於業務訪問來說，如果有一個Proxy代理層或者中介軟體層的一個database和一個table，通過代理層按照一定的規則映射和轉換，轉換成底層多台伺服器上的多個database和多個table，這樣就相當於多台伺服器共同支撐一個業務，可支援的容量就與底層伺服器的數量有關。在Proxy代理沒有到瓶頸的情況下，底層伺服器數量越多，整個水平擴充叢集的效能和容量也會越多，幾乎可以線性擴充。通過這樣的思路，就可以解決大量資料存放區和並發的問題。

 

具體實現來說，水平擴充叢集除了MySQL資料庫，需要一個分布式Proxy中介軟體，這種水平擴充中介軟體種類也比較多，MySQL官方和一些大的的公司都有開發。我們用的比較多的是MyCAT中介軟體。對於底層的分區，可以有幾十個、幾百個甚至幾千個。

 

當然，水平擴充可以解決大資料量的問題，需要有分區策略，那相應地，也會有使用這種策略的限制，比如片鍵選擇，跨節點訪問，分散式交易等問題，需要與業務進行對應結合和考慮後，才可以很好地使用。

 

（2）TokuDB/MyRocks/InnoDB 高效能寫入架構

問題：MySQL資料庫水平分割，可以對於大資料量的讀寫進行線性擴充，但相應地底層伺服器數量也需要比較多；但對於資料寫入量非常大，資料讀很少，資料總量大的情況，使用高效能寫入架構，會更合適一些。

 

業務資料寫入量非常大，讀取量非常高的情況，一般主要對資料insert寫入效能，同時對資料壓縮效率有特別高的要求。這種特殊的寫入要求，需要對資料寫入有特殊的最佳化和設計，並且有比較好的壓縮效率和演算法，能夠將寫入的大量資料進行壓縮，節省空間的。這種寫入架構， 通常可以看做是MySQL資料庫的一種特殊的儲存引擎。

 

具體到實現而言，MySQL的高效能寫入叢集，可以使用TokuDB儲存引擎。近幾年Facebook也開源了其內部實現的MyRocks，可以作為高效能寫入的儲存引擎。MySQL預設的InnoDB儲存引擎，在新的5.7及以後版本最佳化後，寫入效能和壓縮效能也有了更高的效能，也可以作為資料寫入的一種選擇。

（3）MySQL + 緩衝（Memcached、Redis等） 高並發讀架構

問題：如果業務訪問MySQL中的某一些少量熱資料，訪問的並發量非常高，訪問的時效性，資料的一致性要求都非常高，這時候使用MySQL資料庫本身支援這些資料讀取，可能會在並發性、時效性上出現瓶頸。這時，就可以使用緩衝系統結合MySQL來使用。

 

緩衝系統是將MySQL資料庫中的少量熱資料存放到記憶體當中，由於記憶體的IO效率遠高於硬碟的IO，相應的CPU消耗也會少很多，這樣緩衝系統中響應一次業務請求的時間，會遠少於直接從MySQL資料庫訪問需要的時間。於是緩衝系統就可以支撐熱資料的高並發訪問，資料寫還是寫入MySQL資料庫中，資料讀操作，優先讀取緩衝；如果緩衝中有，則直接從緩衝中返回結果；如果緩衝中沒有，則從MySQL資料庫中讀取資料返回應用，並把資料結果再放到緩衝的內容中。

 

具體實現來說，緩衝系統常用的技術架構有Memcached 和Redis。Memcached是比較經典的緩衝系統，在之前常與LAMP、LNMP流行架構結合使用。Redis是幾年新興的Key-Value索引值型NoSQL資料庫，除了作為緩衝，還可以持久化作為Key-Value資料庫使用。

 

（4）MySQL + 小檔案系統（MongoDB、Ceph等） 大欄位存取架構

問題：在MySQL資料庫中，通常是儲存符合關係型資料庫原理的小欄位，比如數值型、字元型資料；但在實際環境中，除了這些常用欄位，還會有一些大欄位，比如帳戶圖片這種圖片檔案、上傳的音頻、視頻檔案、文章內容等大text欄位，另外還有一些JSON檔案、XML檔案等，這些可以以二進位形式儲存在MySQL資料庫中，但讀取和管理都會比較麻煩。這時，就可以使用小檔案系統來結合MySQL來使用。

 

小檔案系統，是可以儲存並快速存取結構化資料的系統。對於圖片、音頻、視頻、TXT檔案、JSON檔案、XML檔案等大欄位，一般就只有簡單的讀寫操作，將這些欄位存入到小檔案系統中，並將對應的訪問連結存入到MySQL資料庫的表中。這樣通過資料庫表，可以快速讀寫檔案位置資訊，在小檔案系統中，通過檔案位置資訊，可以實現對大欄位的快速讀寫訪問。

 

具體實現而言，小檔案系統也有很多技術軟體，比較常見的有MongoDB文檔型NoSQL資料庫、Ceph分布式小檔案系統等。

 

（5）MySQL + Inforbright/Greenplum 統計分析架構

問題：在MySQL資料庫上即時響應業務需要的查詢，通常是指OLTP業務，但對於已經產生的資料，通常會在第二天之後，有結果匯總和統計分析需求。這類OLAP需求通常執行頻率較低，但每次執行消耗的資源很大，如果與OLTP一樣在一個系統上運行，就會造成這兩大類業務的相互影響。這時就可以使用MySQL資料庫與OLAP統計業務分類結合的架構。

 

MySQL產生了業務資料後，通常需要在第二天，要對前一天的資料進行各個角度、各個維度統計、彙總、分析，以體現和反映業務的運營情況。這是讓MySQL支援線上OLTP業務，通過資料流轉程式，將每天產生的資料流轉到離線的資料倉儲系統中，在資料倉儲系統中，進行各種資料統計分析、結果匯總，並將資料統計結果再流轉到結果展示庫中。這樣就可以很好地實現線上OLTP和線下OLAP的結合使用和執行。

 

具體實現而言，對於MySQL資料庫可以結合的OLAP資料倉儲架構，可以選用Inforbright資料倉儲，也可以選用 Greenplum分布式MPP資料庫倉庫。相對而言，Inforbright資料倉儲比較輕量級，與MySQL使用類似；Greenplum分布式MPP資料倉儲可以支撐海量資料的統計分析，功能、效能、容量等也比Inforbright要更強一下，成本也更大一些。

小結

MySQL五種特殊業務架構，可以說是在MySQL三種常見的、通用的架構基礎上，面對特殊的業務情境，遇到特殊的問題，進行針對性解決。

 

對於大量資料讀寫，可以採用水平擴充架構；對於有大量資料寫入需求，可以採用MySQL高效能寫入架構；對於熱資料的高並發、快速響應的需求，可以採用MySQL+緩衝架構；對於特殊的大欄位存取需求，可以採用MySQL+小檔案系統架構；對於離線統計分析需求，可以採用MySQL+統計分析架構。

3、 架構組合與綜合

MySQL三種比較通用的基礎架構和五種特殊需求架構，都可以根據情境單獨使用，也可以根據特定的情境進行組合幾種架構使用，或者綜合起來一起使用。

（1）架構組合

對於只有一兩種特殊情況的架構，選擇基礎架構和特殊架構的簡單組合就可以了，生產環境中可用到的架構組合類別型有：

• MySQL+MHA高可用架構 與 MySQL分布式Proxy水平擴充架構 組合

• MySQL+MHA高可用架構 與 MySQL小檔案系統大欄位存取架構 組合

• MySQL+MHA高可用架構 與 MySQL緩衝高並發讀架構 組合

• MySQL分布式Proxy水平擴充架構 與 MySQL小檔案系統大欄位存取架構 組合

• MySQL分布式Proxy水平擴充架構 與 MySQL緩衝高並發讀架構 組合

• MySQL高效能寫入架構  與 MySQL Inforbright/Greenplum統計分析架構 組合

（2）架構綜合

如果是比較複雜的業務情境，幾種特殊的資料庫結構描述可以綜合起來使用：

MySQL+MHA高可用架構 、MySQL分布式Proxy水平擴充架構、 MySQL緩衝高並發讀架構、 MySQL小檔案系統大欄位存取架構、MySQL Inforbright/Greenplum統計分析架構。

二、業務環境分類

第一部分對MySQL的架構進行了說明，這是對MySQL資料庫本身的瞭解，算作“知己”。所有的資料庫系統提供服務的對象都是業務系統，所以DBA要對業務系統進行瞭解，對業務的特點和適合的情境，做到心中有數，可以算作是“知彼”。做到知己知彼，就能更好地貫通兩者了。

1、從資料庫使用推導資料使用分類

從資料庫操作角度看，業務系統對於資料庫的操作，大的方面可以分為“讀資料”和“寫資料”兩類。展開來說，寫資料有可以具體分為insert插入資料、update修改資料、delete刪除資料三種情況。所以，資料庫的使用也可以細分為增insert、刪delete、改update、查select四種情況。

依據業務系統對資料的操作分類，就可以對業務系統進行歸類：

 

（1）唯讀業務系統

唯讀是指只有查詢select，沒有資料修改的情況。這種情況，是資料庫中已經存在一些資料，並且這些資料只作查詢或展示用，不會有任何資料變化，比如緩衝中的資料、歸檔後的資料、曆史結果資料、統計結果資料等，都是只能進行查詢和展示，不會再發生資料變化的。

 

（2）可讀寫業務系統

按照寫操作的具體情況，可以對可讀寫業務系統分成三類：

• 只有插入Insert，沒有Update和Delete的可讀寫業務系統

這種情況是指資料表的資料只會增加，且表中的資料不能再變化，不會再有修改或者刪除操作；比如操作記錄表、狀態變化記錄表、留言記錄表等。

• 有Insert和Update，沒有Delete的可以讀寫業務系統

這種情況是指資料表中的資料，可以進行增加和修改，但資料一旦產生，可以變化，但不能修改。這也是一種常見的資料庫設計思路，即資料表可以有失效，但生效刪除，並不是真正從資料表中刪除，而是修改了表中表示狀態位的列值，這樣就可以保證資料一直具有可回溯性。

• Insert、Update、Delete都有的可讀寫業務系統

這種情況是指資料表中的資料可進行各種操作，可以查詢，也可以進行各種變化，添刪改除各種操作也都可以進行。

 

2、常見業務表分類

從業務角度對錶進行分類，雖然不同的應用程式對錶的使用不同，但還是能夠抽象成為幾大類表。

 

（1）配置表

這種表通常存放業務一些基礎的配置資訊或者字典資訊。表的資料量一般都比較小，修改變化的操作不太頻繁，通常都是Select查詢操作。

 

（2）狀態表

這種表通常存放在業務系統中實體讀象的狀態資訊，常見的有使用者資訊表，訂單資訊表等。這種表的資料量與實體讀象的規模有直接關係，比如一個APP有多少註冊使用者，通常這個APP的使用者表都會有多少條記錄。狀態表的變化通常比較頻繁，而且Insert、Update、Select操作都會有，Delete操作是否有，通常會根據業務情況的規定決定。

 

（3）日誌表

這種表通常用來記錄業務系統中某種實體的狀態資訊，常見的有使用者登入表、儲值資訊記錄表等。這種表的資料規模通常比較大，而且如果業務狀態變化頻繁，記錄的變化資訊比較多，這種表的資料量和插入效能都要求比較高。日誌表的操作，通常會以Insert操作為主，個別業務會對日誌表進行查詢。MySQL五種特殊需求架構中的高效能寫入架構，主要就是應用這種表的需求。

 

（4）歸檔表

這種表，是將上面三種OLTP業務表的資料進行歸檔或者冷熱分離的表。對線上業務三類表進行資料歸檔、冷熱分離，一方面可以控制線上業務表的資料規模，保證業務表效能；另一方面進行歸檔後，可用於對歸檔曆史資料進行更好的查詢反映和支援。歸檔表的資料量大小與對應的線上表大小、歸檔周期有關。歸檔表的操作，除了歸檔過程的資料載入外，主要就是Select查詢操作了，歸檔後就算是唯讀表。

 

（5）統計資料表

統計資料表，是指業務有離線統計分析需求時，需要將各種線上表和歸檔表的資料，通過ETL過程流轉到線上OLAP統計分析系統中的未經處理資料表。這類表通常資料量會非常大，一個OLAP統計分析平台會匯總多個線上業務系統的資料進行統計分析。統計資料表的操作，除了資料流轉動作外，主要就是各種統計剖析器的訪問計算。

 

（6）統計結果表

統計結果表是在業務有離線統計分析需求時，各種統計分析過程訪問統計資料表中的資料，按照一定的邏輯進行統計分析後的結果資料。這種統計結果資料，通常資料量會比較小。統計結果表的操作，處理結果流轉動作外，主要就是供提供者進行Select查詢。

 

通過對業務表類型的梳理，可以對所有的業務系統進行一個大體的劃分，做到心中有數。

 

3、 DBA對業務的把握

通過資料使用方式對業務系統劃分為四類，再通過業務常見表類型劃分，就可以對通用的業務使用資料庫有一個整體的瞭解。但對於具體的業務情境，還需要根據每個公司具體的實際情況進行具體確認和考慮。

 

大多數情況下，某一種具體的業務都可以根據情況歸入某一種業務類型中，只是每個業務具體的量級會有不同，大家需要先瞭解具體業務環境中的量級，再根據業務類型與MySQL架構的使用方式，進行對應就可以了。

 

如果實際環境中確認有不在現有分類中的情況，則可以通過現有的思路，進行新的類型劃分和架構對應。

三、MySQL業務與架構結合使用原則

上面兩部分通過對MySQL各種架構進行說明，並通過對業務環境的分類，可以讓大家對MySQL架構和業務環境本身有一定的瞭解。下面我將就我在架構設計和營運當中兩者結合的使用原則，對MySQL業務和架構的結合使用進行說明。

1、 適用性原則

適用性原則就是在考慮某一個具體業務情境具體使用哪一種或者幾種業務情境時，我們要盡量使用合適的技術架構解決合適的問題。

（1）需求與情境

MySQL的三種通用基礎架構，適用的情境多一些。但通用業務情境在資料量級、訪問規模、讀寫方式等發生比較大的變化時，就變成了有特殊需求的情境，可以考慮使用某種特定情境對應的MySQL架構技術，盡量保證適用性。

 

反之，如果實際業務在量級、規模、讀寫方式還沒有達到非常特殊的情境時，盡量使用通用的基礎架構就可以滿足業務需求，也可以降低系統複雜度和隱患。

 

（2）整體與部分

不論對於一個業務系統，還是MySQL資料庫結構描述而言，都要從整體和部分兩個角度進行看待和考慮。

 

一個業務系統，首先是一個整體，從整體上看各種業務需求和使用方式，把握好整體，然後再考慮具體的需求；如果沒有特殊的需求，則可以按照通用情境來設計和考慮；如果某一部分有特殊的需求，則可以把這部分內容單獨劃分出來，進行對應的架構設計。

 

多個通用和特殊的架構，相互組合，完成一個對業務系統支撐的架構總體。

 

（3）穩定與升級

一般情況下，業務系統都是先用通用架構進行資料支援，在通用架構適用時，業務系統也可以穩定運行。在業務系統不斷運行過程中，有新業務情境需求產生時，要綜合考慮保證現有業務穩定性、以及升級業務系統到新架構的步驟和階段。

 

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

 

2、 階段性原則

業務系統的發展是有階段的，MySQL資料庫結構描述的發展也是有階段的。不同階段關注的資訊和主要處理思路都是不同的，從不同維度考慮階段性也是使用架構和業務的重要原則。

（1）數量階段

數量是一個比較明顯的階段判斷指標。業務系統通常會有DAU、UV、PV等指標，來協助判斷業務系統的規模。資料庫系統、QPS、TPS、一個表的資料量、一個庫下的表數量、一個執行個體下的庫數量、總的執行個體數量、伺服器數量，都是與架構結合比較緊密的指標。

 

以表資料量舉例：如果一個表運行一年，數量在10萬以下，就可以認為是小表了資料量在10萬-1000萬以上的，可以認為是中表；資料量在1000萬以上，就可以認為是大表，這時就需要考慮歸檔或水平分割了；如果資料量在1億以上，就必須要用特殊架構進行單獨處理了。

 

（2）統一組織

在業務規模和資料規模都比較小的時候，若存在多種不同的架構，還是可以維護的。但如果資料庫執行個體數量和業務模組都大起來之後，統一一種或少數幾種資料架構就非常重要了。統一架構組織，可以讓業務系統和架構，更加容易控制和維護。

 

（3）規模控制

業務發展到一定規模，底層架構中的資料庫都必須要控制規模，一個執行個體不能太大，一個表也不能太大，如果超過了約定好的規模，需要進行實力拆分，或者表拆分，以使執行個體和庫表都保持在統一設定的規模當中。

 

3、 擴充性原則

應用業務隨著時間會不斷變化，底層的MySQL架構也需要隨著業務的變化能夠具有一定的擴充性，保持變化和擴充的空間，以不斷支援業務的發展。

（1）架構之間的打通

從MySQL的三種基礎架構就可以看出來，MySQL單一實例架構→MySQL master-slave主從架構→MySQL MHA高可用架構，這中間是逐步演化的，有直接的依賴關係。後續Oracle推出的InnoDB Cluster架構，也與這些基礎架構有直接演化關係。

 

其它五種特殊需求的架構，隨著業務分類的變化，特殊情況也可能發生變化，可根據這些變化從一種特殊架構調整成為另一種特殊的架構。

 

（2）OLTP與OLAP

資料庫系統一般分為OLTP和OLAP兩大類，但實際在目前的業務系統和架構設計中，這兩種需求都是需要支援的。只要建立好一個比較穩定、可靠的資料流轉體系，將這兩者打通，就可以很容易地實現OLTP和OLAP的互連，OLTP的業務資料傳送到OLAP中進行統計，OLAP的統計結果，再返回到OLTP中進行展示。

 

（3）新架構的使用

MySQL架構中除了常見的三種基礎架構和五種特殊架構，還有一些新的技術和趨勢來嘗試完善和解決現有架構的一些問題，比如InnoDB Cluster等技術，對MySQL的擴充和高可用會有更好的解決方式。

 

雖然目前這些新技術還沒有完全穩定和成熟，但在後續新技術架構穩定成熟後，可以很容易地將現有架構擴充成新的技術架構，這樣就可以更好地解決業務問題了。

 

後記

本文嘗試從MySQL架構，業務環境分類，MySQL業務和架構結合使用原則三個方面對MySQL架構和業務進行了說明，希望能夠從架構角度讓大家對架構和業務的理解，能夠更深一層、觸類旁通地面對和解決各種業務問題。其中某些與架構關聯性不太大的具體細節，在本文中沒有完全展開，會在以後的文章中再進行說明。

 

本文來轉載於：  https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650765228&idx=1&sn=c9122f974413c28a7499df2089ed7e4d&chksm=f3f9c239c48e4b2f448f93964dd6c5cd91a45281f48a91df35e89d38c891f46176ea2689e3a4&mpshare=1&scene=1&srcid=0122XmRArstRGfPAOK9JGiXi#rd

 

打通MySQL架構和業務的任督二脈