存盤高性能[關系型資料庫]

關系型資料庫由于其ACID的特性和功能強大的SQL能力，目前仍舊是各種業務系統關鍵且核心的存盤系統，很多場景下高性能的設計核心部分就是關系型資料庫的設計，尤其是互聯網時代，海量用戶加上海量資料的特點，單個資料庫服務器已經難以滿足業務需求，必須考慮資料庫集群的方式提升性能，高性能資料庫集群的第一種方式是讀寫分離，其本質是將訪問壓力分散到集群中的多個節點，但沒有分散存盤壓力；第二種方式是分庫分表，既可以分散訪問壓力，又可以分散存盤壓力

讀寫分離

讀寫分離的基本原理是將資料庫讀寫操作分散到不同的節點上:

• 資料庫服務器搭建主從集群，一主一叢或一主多從
• 資料庫主機負責讀寫操作，從機之負責讀操作
• 資料庫主機通過復制將資料同步到從機，每臺資料庫服務器都存盤了所有的業務資料
• 業務服務器將寫操作發給資料庫主機，將讀操作發給資料庫從機

讀寫分離的實作邏輯并不復雜，而實際應用程序中需要應對的是復制延遲帶來的復雜性，以MySQL為例，主從復制延遲可能1秒，如果大量資料同步延遲達到1分鐘也很常見，這種情況就帶來了一個問題業務服務器將資料寫入到資料庫主服務器，應用程式立刻進行讀取，此時讀操作訪問的是從機，主機還沒有將資料復制過來，到從機讀取資料是讀不到最新資料的；再距離注冊賬號的功能，注冊完立即登陸是會得到類似“你還沒有注冊”的提示的

解決主從復制延遲

將寫操作后的讀操作發送給資料庫主服務器

例如注冊賬號完成后，立即登陸時讀取賬號的讀操作也要發給資料庫主服務器，這種方式與業務強系結，對業務的侵入和影響較大

讀從機失敗后再讀一次主機

這也就是常說的“二次讀取”，二次讀取和業務無系結，對底層訪問資料庫的API進行封裝，實作代價比較小，缺點在于二次讀取過多，仍舊會增加主機的讀操作壓力

關鍵業務讀寫操作全部指向主機，非關鍵業務采用讀寫分離

分庫分表

讀寫分離分散了資料庫讀寫操作的壓力，但沒有分散存盤壓力，資料量達到千萬級以上的時候，單臺資料庫服務器的存盤能力會成為系統的瓶頸，主要體現在如下三個方面：

• 資料量太大，讀寫的性能就會下降，即使有索引，索引也會變得很大，性能同樣會下降
• 資料檔案會變得很大，資料庫備份和恢復需要消耗很長的時間
• 資料檔案越大，極端情況下丟失資料的風險越高
  因此，單個資料庫服務器存盤的資料量不能太大，需要控制在一定的范圍，需要將存盤分散到多臺資料庫服務器，也就是分庫分表

業務分庫

業務分庫是指按照業務模塊將資料分散到不同的資料庫服務器

分庫雖然分散了存盤和訪問壓力，但同時也帶來了新的問題

join操作問題

業務分庫后，原本在同一個資料庫中的表分散到不同的資料庫中，導致無法使用SQL的join查詢

事務問題

原本在同一個資料庫中不同的表可以在同一個事務中修改，業務分庫后，表分散到不同的資料庫中，無法通過事務統一修改，雖然資料庫提供了分布式事務的解決方案例如MySQL的XA，但性能比較差，與高性能存盤的目標是相違背的

成本問題

業務分庫同時帶來了成本的代價，一臺的事變成了三臺的事

分表

將不同業務資料分散存盤到不同的資料庫服務器，能夠支撐百萬甚至千萬用戶規模的業務，隨著業務的發展同一業務的單表資料也會達到單臺資料庫服務器的處理瓶頸，單表拆分有兩種方式垂直分表和水平分表

• 表的垂直切分：將一個表切成兩個，這兩個表的記錄相同但包含不同的列，例如一個表包含ID、name、age、sex列；另一個表包含ID、nickname、description列
• 表的水平切分：將一個表切成兩個，這兩個表的列相同但包含不同的行資料，例如兩個表都包含ID、name、age、sex、nickname，description列，但一個表包含的是ID從1到999999的行資料，另一個表包含的是ID從100000到99999999的行資料

• 實際上架構設計程序中并不局限切分次數，一個表可以切兩次，也可以多次
• 單表切分后的表是否需要分散在不同的資料庫服務器中，可以根據實際切分效果來確定，并不強制要求單表切分變成多表后一定要分散到不同的資料庫中，原因在于單表切分為多表后，新的表即使在同一個資料庫服務器中，也會帶來可觀的性能提升，如果單表拆分后單臺服務器依然無法滿足性能要求，可以再進行分庫

垂直分表

• 垂直分表適合將表中某些不常用且占了大量空間的列拆分出去，例如用戶在篩選其他用戶的時候，主要是用age和sex兩個欄位進行查詢，而nickname和description兩個欄位主要用于展示，一般不會用到業務查詢中使用，這個時候將nickname和description獨立到另外一張表中，這樣在查詢age和sex時，就會帶來性能提升
• 垂直分表引入的復雜性主要體現在表操作的數量要增加，例如分表前一次查詢就可以獲取name、age、sex、nickname、description，現在需要查詢兩次，一次查詢獲取name、age、sex，另一次查詢獲取nickname、description

水平分表

水平分表適合表行數特別大的表，通常單表行數超過5000萬就必須進行分表，但不絕對標準需要視情況而定做取舍，但單表行數達到千萬級架構師就必須警覺，水平分表比垂直分表更復雜，主要體現在如下幾個方面

路由

水平分表后，某條資料具體屬于哪個切分后的字表，需要增加路由演算法進行計算，常見的路由演算法有

范圍路由

• 選取有序的資料列（例如，整型、時間戳等）作為路由的條件，不同分段分散到不同的數 據庫表中 以最常見的用戶ID為例，路由演算法可以按照1000000 的范圍大小進行分段，1～999999 放到A資料庫的表中，1000000～1999999放到B資料庫的表中 ，以此類推
• 范圍路由設計的復雜點主要體現在分段大小的選取上，分段太小會導致切分后子表數量過多，增加維護復雜度；分段太大可能會導致單表依然存在性能問題，一般建議分段大小在100 萬至 2000 萬之間具體需要根據業務選取合適的分段大小
• 范圍路由的優點是可以隨著資料的增加平滑地擴充新的表，例如，現在的用戶是100 萬，如果增加到 1000萬，只需要增加新的表就可以了，原有的資料不需要動
• 范圍路由的一個比較隱含的缺點是分布不均勻，假如按照 1000萬來進行分表，有可能某個分段實際存盤的資料只有 1000 條， 而另外一個分段實際存盤的資料有900萬條

Hash路由

• 選取某個列（或者某幾個列組合也可以〉的值進行 Hash 運算，然后根據 Hash 結果分散到不同的資料庫表中，同樣以用戶ID為例，假如我們一開始就規劃了 10 個資料庫表，路由演算法可以簡單地用user id %10的值來表示資料所屬的資料庫表編號，ID為985的用戶放到編號為5的子表中，ID為10086 的用 戶放到編號為 6 的字表中
• Hash 路由設計的復雜點主要體現在初始表數量的選取上，表數量太多維護比較麻煩，表數 量太少又可能導致單表性能存在問題，而用了Hash路由后，增加字表數量是非常麻煩的， 所有 資料都要重分布
• Hash 路由的優缺點和范圍路由基本相反， Hash路由的優點是表分布比較均勻，缺點是擴充新的表很麻煩，所有資料都要重分布

配置路由

• 配置路由就是路由表，用 一張獨立的表來記錄路由資訊，同樣以用戶 ID 為例 ，我們新增一張user router 表，這個表包含 user_id 和 table_id 兩列，根據 user_id 就可以查詢對應的 table_id
• 配置路由設計簡單，使用起來非常靈活，尤其是在擴充表的時候，只需要遷移指定的資料， 然后修改路由表就可以了
• 配置路由的缺點就是必須多查詢一次，會影響整體性能 ； 而且路由表本身如果太大（幾億條資料），性能同樣可能成為瓶頸，如果我們再次將路由表分庫分表，則又面臨一個死回圈式的路由演算法選擇問題

join 操作問題

水平分表后，資料分散在多個表中 ，如果需要與其他表進行join查詢，需要在業務代碼或資料庫中間件中進行多次join查詢，然后將結果合井

count 操作問題

水平分表后，雖然物理上資料分散到多個表中，但某些業務邏輯上還是會將這些表當作一個表來處理,例如，獲取記錄總數用于分頁或展示，水平分表前用 一個count()就能完成的操作，在分表后就沒那么簡單了, 常見的處理方式有:

count() 相加

具體做法是在業務代碼或資料庫中間件中對每個表進行count()操作，然后將結果相加 ，這種方式實作簡單，缺點就是性能比較低 ,例如，水平分表后切分為20張表，則要進行20次count(*) 操作，如果串行的話， 則可能需要幾秒鐘才能得到結果，

記錄數表

• 具體做法是新建一張表，假如表名為"記錄數表",包含table_name、row_count兩個欄位，每次插入或洗掉子表資料成功后，都更新“記錄數表”
• 這種方式獲取表記錄數的性能要大大優于count()相加的方式，因為只需要一次簡單查詢就可以獲取資料
• 缺點是復雜度增加不少，對子表的操作要同步操作“記錄數表”，如果有一個業務邏輯遺漏了，資料就會不一致；且針對“記錄數表”的操作和針對子表的操作無法放在同一事務中進行處理，例外的情況下會出現操作子表成功了而操作記錄數表失敗，同樣會導致資料 不一致，
• 此外，記錄數表的方式也增加了資料庫的寫壓力，因為每次針對子表的insert和delete操作都要update記錄數表，所以對于一些不要求記錄數實時保持精確的業務，也可以通過后臺定時更新記錄數表，定時更新實際上就是“ count()相加”和“記錄數表”的結合，即定時通過count()相加計算表的記錄數，然后更新記錄數表中的資料，

order by 操作

水平分表后，資料分散到過個字表中，排序操作無法在資料庫中完成，只能由業務代碼或資料庫中間件分別查詢每個字表中的資料，然后匯總再排序

實作方法

讀寫分離需要將讀寫操作區分開來，然后訪問不同的資料庫服務器;分庫分表需要根據不同的資料訪問不同的資料庫服務器，兩者本質上都是一種分配機制，即將不同的 SQL 陳述句發送 到不同 的 資料庫服務器，常見的分配實作方式有兩種：程式代碼封裝和中間件封裝

程式代碼封裝

程式代碼封裝指在代碼中抽象一個資料訪問層來實作讀寫分離、分庫分表，例如，基于Hibernate進行簡單封裝，就可以實作讀寫分離 ， 基本架構如下圖所示

程式代碼封裝的方式具備如下幾個特點:

• 實作簡單 ， 而且可以根據業務做較多定制化的功能
• 每個編程語言都需要自己實作一次,無法通用 ,如果一個業務包含多個編程語言寫的多個子系統 ，則重復開發 的作業量比較大
• 故障情況下，如果主從發生切換， 則可能需要所有系統都修改配置井重啟 ，

目前開源的實作方案中，淘寶的TDDL ( Taobao Distributed Data Layer）是比較有名的，它是一個通用資料訪問層，所有功能封裝在jar包中供業務代碼呼叫，其基本原 理是一個基于集中式配置的jdbc datasource實作，具有主備、讀寫分離、動態資料庫配置等功 能，基本架構如下圖所示

中間件封裝

中間件封裝指的是獨立一套系統 出來，實作讀寫分離和分庫分表操作,中間件對業務服務器提供 SQL兼容的協議，對于業務服務器來說，訪問中間件和訪問資料庫沒有區別，事實上在業務服務器看來，中間件就是一個資料庫服務器，例如，中間件實作讀寫分離的基本架構如下圖所示

資料庫中間件的方式具備如下特點：

• 能夠支持多種編程語言 ，因為資料庫中間件對業務服務器提供的是標準SQL介面
• 資料庫中間件要支持完整的SQL語法和資料庫服務器的協議（例如，MySQL客戶端和服務器的連接協議），這是一個很復雜的事情，而且細節特別多，很容易出現bug
• 資料庫中間件自己不執行真正的讀寫操作，但所有的資料庫操作請求都要經過中間件，中間件的性能要求也很高
• 資料庫主從切換對業務服務器無感知，資料庫中間件可以探測資料庫服務器的主從狀態，例如，向某個測驗表寫入1條資料，成功的就是主機，失敗的就是從機，

由于資料庫中間件的復雜度要比程式代碼封裝高出一個數量級， 一般情況下建議采用程式語言封裝的方式，或者使用成熟的開源資料庫中間件，這個系統一旦做好，接入的業務系統越多，節省的程式開發投入也就越多價值也越大

目前的開源資料庫中間件方案中， MySQL官方先是提供了mysql-proxy ，但 mysql-proxy一直沒有正式 GA ，現在 MySQL官方推薦 MySQL Router，MySQL Router 的主要功能有讀寫分離、故障自動切換、負載均衡、連接池等，其基本架構如下圖所示

奇虎360公司也開源了自己的資料庫中間件Atlas，它基于MySQL proxy實作的，基本架構如下圖所示

Atlas 是一個位于應用程式與 MySQL 之間的中間件 ， 在后端DB看來，Atlas相當于連接它的客戶端，在前端應用看來，Atlas相當于一個DB，Atlas作為服務端與應用程式通信，它實作了MySQL的客戶端和服務端協議，同時作為客戶端與MySQL通信，它對應用程式屏蔽了DB的細節，同時為了降低MySQL負擔，它還維護了連接池

實作復雜度

• 讀寫分離實作時只要識別SQL操作是讀操作還是寫操作即可，通過簡單地判斷SELECT、UPDATE、INSERT、DELETE幾個關鍵字就可以實作
• 分庫分表的實作除了要判斷操作型別， 還要判斷SQL中的具體需要操作的表、操作函式（例如， count函式)、order by 、 group by 操作等，然后根據不同的操作進行不同的處理 ， 例如order by操作需要先從多個庫查詢各個庫的資料，然后重新執行order by才能得到最終的結果 相比來說，分庫分表的實作要復雜得多