這篇文章，我們來聊一下對于一個支撐日活百萬用戶的高并系統(tǒng)，他的數(shù)據(jù)庫架構(gòu)應(yīng)該如何設(shè)計?

看到這個題目，很多人***反應(yīng)就是：分庫分表啊!但是實際上，數(shù)據(jù)庫層面的分庫分表到底是用來干什么的，他的不同的作用如何應(yīng)對不同的場景，我覺得很多同學(xué)可能都沒搞清楚。

用一個創(chuàng)業(yè)公司的發(fā)展作為背景引入

假如我們現(xiàn)在是一個小創(chuàng)業(yè)公司，注冊用戶就 20 萬，每天活躍用戶就 1 萬，每天單表數(shù)據(jù)量就 1000，然后高峰期每秒鐘并發(fā)請求最多就 10。

天哪!就這種系統(tǒng)，隨便找一個有幾年工作經(jīng)驗的高級工程師，然后帶幾個年輕工程師，隨便干干都可以做出來。

因為這樣的系統(tǒng)，實際上主要就是在前期快速的進(jìn)行業(yè)務(wù)功能的開發(fā)，搞一個單塊系統(tǒng)部署在一臺服務(wù)器上，然后連接一個數(shù)據(jù)庫就可以了。

接著大家就是不停的在一個工程里填充進(jìn)去各種業(yè)務(wù)代碼，盡快把公司的業(yè)務(wù)支撐起來。

如下圖所示：

結(jié)果呢，沒想到我們運(yùn)氣這么好，碰上個優(yōu)秀的 CEO 帶著我們走上了康莊大道!

公司業(yè)務(wù)發(fā)展迅猛，過了幾個月，注冊用戶數(shù)達(dá)到了 2000 萬!每天活躍用戶數(shù) 100 萬!每天單表新增數(shù)據(jù)量達(dá)到 50 萬條!高峰期每秒請求量達(dá)到 1 萬!

同時公司還順帶著融資了兩輪，估值達(dá)到了驚人的幾億美金!一只朝氣蓬勃的幼年獨角獸的節(jié)奏!

好吧，現(xiàn)在大家感覺壓力已經(jīng)有點大了，為啥呢?因為每天單表新增 50 萬條數(shù)據(jù)，一個月就多 1500 萬條數(shù)據(jù)，一年下來單表會達(dá)到上億條數(shù)據(jù)。

經(jīng)過一段時間的運(yùn)行，現(xiàn)在咱們單表已經(jīng)兩三千萬條數(shù)據(jù)了，勉強(qiáng)還能支撐著。

但是，眼見著系統(tǒng)訪問數(shù)據(jù)庫的性能怎么越來越差呢，單表數(shù)據(jù)量越來越大，拖垮了一些復(fù)雜查詢 SQL 的性能啊!

然后高峰期請求現(xiàn)在是每秒 1 萬，咱們的系統(tǒng)在線上部署了 20 臺機(jī)器，平均每臺機(jī)器每秒支撐 500 請求，這個還能抗住，沒啥大問題。但是數(shù)據(jù)庫層面呢?

如果說此時你還是一臺數(shù)據(jù)庫服務(wù)器在支撐每秒上萬的請求，負(fù)責(zé)任的告訴你，每次高峰期會出現(xiàn)下述問題：

• 你的數(shù)據(jù)庫服務(wù)器的磁盤 IO、網(wǎng)絡(luò)帶寬、CPU 負(fù)載、內(nèi)存消耗，都會達(dá)到非常高的情況，數(shù)據(jù)庫所在服務(wù)器的整體負(fù)載會非常重，甚至都快不堪重負(fù)了。
• 高峰期時，本來你單表數(shù)據(jù)量就很大，SQL 性能就不太好，這時加上你的數(shù)據(jù)庫服務(wù)器負(fù)載太高導(dǎo)致性能下降，就會發(fā)現(xiàn)你的 SQL 性能更差了。
• 最明顯的一個感覺，就是你的系統(tǒng)在高峰期各個功能都運(yùn)行的很慢，用戶體驗很差，點一個按鈕可能要幾十秒才出來結(jié)果。
• 如果你運(yùn)氣不太好，數(shù)據(jù)庫服務(wù)器的配置不是特別的高的話，弄不好你還會經(jīng)歷數(shù)據(jù)庫宕機(jī)的情況，因為負(fù)載太高對數(shù)據(jù)庫壓力太大了。

多臺服務(wù)器分庫支撐高并發(fā)讀寫

首先我們先考慮***個問題，數(shù)據(jù)庫每秒上萬的并發(fā)請求應(yīng)該如何來支撐呢?

要搞清楚這個問題，先得明白一般數(shù)據(jù)庫部署在什么配置的服務(wù)器上。通常來說，假如你用普通配置的服務(wù)器來部署數(shù)據(jù)庫，那也起碼是 16 核 32G 的機(jī)器配置。

這種非常普通的機(jī)器配置部署的數(shù)據(jù)庫，一般線上的經(jīng)驗是：不要讓其每秒請求支撐超過 2000，一般控制在 2000 左右。

控制在這個程度，一般數(shù)據(jù)庫負(fù)載相對合理，不會帶來太大的壓力，沒有太大的宕機(jī)風(fēng)險。

所以首先***步，就是在上萬并發(fā)請求的場景下，部署個 5 臺服務(wù)器，每臺服務(wù)器上都部署一個數(shù)據(jù)庫實例。

然后每個數(shù)據(jù)庫實例里，都創(chuàng)建一個一樣的庫，比如說訂單庫。此時在 5 臺服務(wù)器上都有一個訂單庫，名字可以類似為：db_order_01，db_order_02，等等。

然后每個訂單庫里，都有一個相同的表，比如說訂單庫里有訂單信息表，那么此時 5 個訂單庫里都有一個訂單信息表。

比如 db_order_01 庫里就有一個 tb_order_01 表，db_order_02 庫里就有一個 tb_order_02 表。

這就實現(xiàn)了一個基本的分庫分表的思路，原來的一臺數(shù)據(jù)庫服務(wù)器變成了 5 臺數(shù)據(jù)庫服務(wù)器，原來的一個庫變成了 5 個庫，原來的一張表變成了 5 個表。

然后你在寫入數(shù)據(jù)的時候，需要借助數(shù)據(jù)庫中間件，比如 sharding-jdbc，或者是 mycat，都可以。

你可以根據(jù)比如訂單 id 來 hash 后按 5 取模，比如每天訂單表新增 50 萬數(shù)據(jù)，此時其中 10 萬條數(shù)據(jù)會落入 db_order_01 庫的 tb_order_01 表，另外 10 萬條數(shù)據(jù)會落入 db_order_02 庫的 tb_order_02 表，以此類推。

這樣就可以把數(shù)據(jù)均勻分散在 5 臺服務(wù)器上了，查詢的時候，也可以通過訂單 id 來 hash 取模，去對應(yīng)的服務(wù)器上的數(shù)據(jù)庫里，從對應(yīng)的表里查詢那條數(shù)據(jù)出來即可。

依據(jù)這個思路畫出的圖如下所示，大家可以看看：

做這一步有什么好處呢?***個好處，原來比如訂單表就一張表，這個時候不就成了 5 張表了么，那么每個表的數(shù)據(jù)就變成 1/5 了。

假設(shè)訂單表一年有 1 億條數(shù)據(jù)，此時 5 張表里每張表一年就 2000 萬數(shù)據(jù)了。

那么假設(shè)當(dāng)前訂單表里已經(jīng)有 2000 萬數(shù)據(jù)了，此時做了上述拆分，每個表里就只有 400 萬數(shù)據(jù)了。

而且每天新增 50 萬數(shù)據(jù)的話，那么每個表才新增 10 萬數(shù)據(jù)，這樣是不是初步緩解了單表數(shù)據(jù)量過大影響系統(tǒng)性能的問題?

另外就是每秒 1 萬請求到 5 臺數(shù)據(jù)庫上，每臺數(shù)據(jù)庫就承載每秒 2000 的請求，是不是一下子把每臺數(shù)據(jù)庫服務(wù)器的并發(fā)請求降低到了安全范圍內(nèi)?

這樣，降低了數(shù)據(jù)庫的高峰期負(fù)載，同時還保證了高峰期的性能。

大量分表來保證海量數(shù)據(jù)下的查詢性能

但是上述的數(shù)據(jù)庫架構(gòu)還有一個問題，那就是單表數(shù)據(jù)量還是過大，現(xiàn)在訂單表才分為了 5 張表，那么如果訂單一年有 1 億條，每個表就有 2000 萬條，這也還是太大了。

所以還應(yīng)該繼續(xù)分表，大量分表。比如可以把訂單表一共拆分為 1024 張表，這樣 1 億數(shù)據(jù)量的話，分散到每個表里也就才 10 萬量級的數(shù)據(jù)量，然后這上千張表分散在 5 臺數(shù)據(jù)庫里就可以了。

在寫入數(shù)據(jù)的時候，需要做兩次路由，先對訂單 id hash 后對數(shù)據(jù)庫的數(shù)量取模，可以路由到一臺數(shù)據(jù)庫上，然后再對那臺數(shù)據(jù)庫上的表數(shù)量取模，就可以路由到數(shù)據(jù)庫上的一個表里了。

通過這個步驟，就可以讓每個表里的數(shù)據(jù)量非常小，每年 1 億數(shù)據(jù)增長，但是到每個表里才 10 萬條數(shù)據(jù)增長，這個系統(tǒng)運(yùn)行 10 年，每個表里可能才***的數(shù)據(jù)量。

這樣可以一次性為系統(tǒng)未來的運(yùn)行做好充足的準(zhǔn)備，看下面的圖，一起來感受一下：

全局唯一 id 如何生成

在分庫分表之后你必然要面對的一個問題，就是 id 咋生成?因為要是一個表分成多個表之后，每個表的 id 都是從 1 開始累加自增長，那肯定不對啊。

舉個例子，你的訂單表拆分為了 1024 張訂單表，每個表的 id 都從 1 開始累加，這個肯定有問題了!

你的系統(tǒng)就沒辦法根據(jù)表主鍵來查詢訂單了，比如 id = 50 這個訂單，在每個表里都有!

所以此時就需要分布式架構(gòu)下的全局唯一 id 生成的方案了，在分庫分表之后，對于插入數(shù)據(jù)庫中的核心 id，不能直接簡單使用表自增 id，要全局生成唯一 id，然后插入各個表中，保證每個表內(nèi)的某個 id，全局唯一。

比如說訂單表雖然拆分為了 1024 張表，但是 id = 50 這個訂單，只會存在于一個表里。

那么如何實現(xiàn)全局唯一 id 呢?有以下幾種方案：

方案一：獨立數(shù)據(jù)庫自增 id

這個方案就是說你的系統(tǒng)每次要生成一個 id，都是往一個獨立庫的一個獨立表里插入一條沒什么業(yè)務(wù)含義的數(shù)據(jù)，然后獲取一個數(shù)據(jù)庫自增的一個 id。拿到這個 id 之后再往對應(yīng)的分庫分表里去寫入。

比如說你有一個 auto_id 庫，里面就一個表，叫做 auto_id 表，有一個 id 是自增長的。

那么你每次要獲取一個全局唯一 id，直接往這個表里插入一條記錄，獲取一個全局唯一 id 即可，然后這個全局唯一 id 就可以插入訂單的分庫分表中。

這個方案的好處就是方便簡單，誰都會用。缺點就是單庫生成自增 id，要是高并發(fā)的話，就會有瓶頸的，因為 auto_id 庫要是承載個每秒幾萬并發(fā)，肯定是不現(xiàn)實的了。

方案二：UUID

這個每個人都應(yīng)該知道吧，就是用 UUID 生成一個全局唯一的 id。

好處就是每個系統(tǒng)本地生成，不要基于數(shù)據(jù)庫來了。不好之處就是，UUID 太長了，作為主鍵性能太差了，不適合用于主鍵。

如果你是要隨機(jī)生成個什么文件名了，編號之類的，你可以用 UUID，但是作為主鍵是不能用 UUID 的。

方案三：獲取系統(tǒng)當(dāng)前時間

這個方案的意思就是獲取當(dāng)前時間作為全局唯一的 id。但是問題是，并發(fā)很高的時候，比如一秒并發(fā)幾千，會有重復(fù)的情況，這個肯定是不合適的。

一般如果用這個方案，是將當(dāng)前時間跟很多其他的業(yè)務(wù)字段拼接起來，作為一個 id，如果業(yè)務(wù)上你覺得可以接受，那么也是可以的。

你可以將別的業(yè)務(wù)字段值跟當(dāng)前時間拼接起來，組成一個全局唯一的編號，比如說訂單編號：時間戳 + 用戶 id + 業(yè)務(wù)含義編碼。

方案四：SnowFlake 算法的思想分析

SnowFlake 算法，是 Twitter 開源的分布式 id 生成算法。其核心思想就是：使用一個 64 bit 的 long 型的數(shù)字作為全局唯一 id。

這 64 個 bit 中，其中 1 個 bit 是不用的，然后用其中的 41 bit 作為毫秒數(shù)，用 10 bit 作為工作機(jī)器 id，12 bit 作為序列號。

給大家舉個例子吧，比如下面那個 64 bit 的 long 型數(shù)字：

• ***個部分，是 1 個 bit：0，這個是無意義的。
• 第二個部分是 41 個 bit：表示的是時間戳。
• 第三個部分是 5 個 bit：表示的是機(jī)房 id，10001。
• 第四個部分是 5 個 bit：表示的是機(jī)器 id，1 1001。
• 第五個部分是 12 個 bit：表示的序號，就是某個機(jī)房某臺機(jī)器上這一毫秒內(nèi)同時生成的 id 的序號，0000 00000000。

①1 bit：是不用的，為啥呢?

因為二進(jìn)制里***個 bit 為如果是 1，那么都是負(fù)數(shù)，但是我們生成的 id 都是正數(shù)，所以***個 bit 統(tǒng)一都是 0。

②41 bit：表示的是時間戳，單位是毫秒。

41 bit 可以表示的數(shù)字多達(dá) 2^41 - 1，也就是可以標(biāo)識 2 ^ 41 - 1 個毫秒值，換算成年就是表示 69 年的時間。

③10 bit：記錄工作機(jī)器 id，代表的是這個服務(wù)最多可以部署在 2^10 臺機(jī)器上，也就是 1024 臺機(jī)器。

但是 10 bit 里 5 個 bit 代表機(jī)房 id，5 個 bit 代表機(jī)器 id。意思就是最多代表 2 ^ 5 個機(jī)房(32 個機(jī)房)，每個機(jī)房里可以代表 2 ^ 5 個機(jī)器(32 臺機(jī)器)。

④12 bit：這個是用來記錄同一個毫秒內(nèi)產(chǎn)生的不同 id。

12 bit 可以代表的***正整數(shù)是 2 ^ 12 - 1 = 4096，也就是說可以用這個 12 bit 代表的數(shù)字來區(qū)分同一個毫秒內(nèi)的 4096 個不同的 id。

簡單來說，你的某個服務(wù)假設(shè)要生成一個全局唯一 id，那么就可以發(fā)送一個請求給部署了 SnowFlake 算法的系統(tǒng)，由這個 SnowFlake 算法系統(tǒng)來生成唯一 id。

這個 SnowFlake 算法系統(tǒng)首先肯定是知道自己所在的機(jī)房和機(jī)器的，比如機(jī)房 id = 17，機(jī)器 id = 12。

接著 SnowFlake 算法系統(tǒng)接收到這個請求之后，首先就會用二進(jìn)制位運(yùn)算的方式生成一個 64 bit 的 long 型 id，64 個 bit 中的***個 bit 是無意義的。

接著 41 個 bit，就可以用當(dāng)前時間戳(單位到毫秒)，然后接著 5 個 bit 設(shè)置上這個機(jī)房 id，還有 5 個 bit 設(shè)置上機(jī)器 id。

***再判斷一下，當(dāng)前這臺機(jī)房的這臺機(jī)器上這一毫秒內(nèi)，這是第幾個請求，給這次生成 id 的請求累加一個序號，作為***的 12 個 bit。

最終一個 64 個 bit 的 id 就出來了，類似于：

這個算法可以保證說，一個機(jī)房的一臺機(jī)器上，在同一毫秒內(nèi)，生成了一個唯一的 id。可能一個毫秒內(nèi)會生成多個 id，但是有*** 12 個 bit 的序號來區(qū)分開來。

下面我們簡單看看這個 SnowFlake 算法的一個代碼實現(xiàn)，這就是個示例，大家如果理解了這個意思之后，以后可以自己嘗試改造這個算法。

總之就是用一個 64 bit 的數(shù)字中各個 bit 位來設(shè)置不同的標(biāo)志位，區(qū)分每一個 id。

SnowFlake 算法的實現(xiàn)代碼如下：

public class IdWorker { 
  private long workerId; // 這個就是代表了機(jī)器id 
  private long datacenterId; // 這個就是代表了機(jī)房id 
  private long sequence; // 這個就是代表了一毫秒內(nèi)生成的多個id的***序號 
  public IdWorker(long workerId, long datacenterId, long sequence) { 
    // sanity check for workerId 
    // 這兒不就檢查了一下，要求就是你傳遞進(jìn)來的機(jī)房id和機(jī)器id不能超過32，不能小于0 
    if (workerId > maxWorkerId || workerId < 0) { 
 
      throw new IllegalArgumentException( 
        String.format("worker Id can't be greater than %d or less than 0",maxWorkerId)); 
    } 
 
    if (datacenterId > maxDatacenterId || datacenterId < 0) { 
 
      throw new IllegalArgumentException( 
        String.format("datacenter Id can't be greater than %d or less than 0",maxDatacenterId)); 
    } 
    this.workerId = workerId; 
    this.datacenterId = datacenterId; 
    this.sequence = sequence; 
  } 
  private long twepoch = 1288834974657L; 
  private long workerIdBits = 5L; 
  private long datacenterIdBits = 5L; 
 
  // 這個是二進(jìn)制運(yùn)算，就是5 bit最多只能有31個數(shù)字，也就是說機(jī)器id最多只能是32以內(nèi) 
  private long maxWorkerId = -1L ^ (-1L << workerIdBits);  
  // 這個是一個意思，就是5 bit最多只能有31個數(shù)字，機(jī)房id最多只能是32以內(nèi) 
  private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);  
  private long sequenceBits = 12L; 
  private long workerIdShift = sequenceBits; 
  private long datacenterIdShift = sequenceBits + workerIdBits; 
  private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits; 
  private long sequenceMask = -1L ^ (-1L << sequenceBits); 
  private long lastTimestamp = -1L; 
  public long getWorkerId(){ 
    return workerId; 
  } 
  public long getDatacenterId() { 
    return datacenterId; 
  } 
  public long getTimestamp() { 
    return System.currentTimeMillis(); 
  } 
  // 這個是核心方法，通過調(diào)用nextId()方法，讓當(dāng)前這臺機(jī)器上的snowflake算法程序生成一個全局唯一的id 
  public synchronized long nextId() { 
    // 這兒就是獲取當(dāng)前時間戳，單位是毫秒 
    long timestamp = timeGen(); 
    if (timestamp < lastTimestamp) { 
      System.err.printf( 
        "clock is moving backwards. Rejecting requests until %d.", lastTimestamp); 
      throw new RuntimeException( 
        String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", 
               lastTimestamp - timestamp)); 
    } 
 
    // 下面是說假設(shè)在同一個毫秒內(nèi)，又發(fā)送了一個請求生成一個id 
    // 這個時候就得把seqence序號給遞增1，最多就是4096 
    if (lastTimestamp == timestamp) { 
 
      // 這個意思是說一個毫秒內(nèi)最多只能有4096個數(shù)字，無論你傳遞多少進(jìn)來， 
      //這個位運(yùn)算保證始終就是在4096這個范圍內(nèi)，避免你自己傳遞個sequence超過了4096這個范圍 
      sequence = (sequence + 1) & sequenceMask;  
      if (sequence == 0) { 
        timestamp = tilNextMillis(lastTimestamp); 
      } 
 
    } else { 
      sequence = 0; 
    } 
    // 這兒記錄一下最近一次生成id的時間戳，單位是毫秒 
    lastTimestamp = timestamp; 
    // 這兒就是最核心的二進(jìn)制位運(yùn)算操作，生成一個64bit的id 
    // 先將當(dāng)前時間戳左移，放到41 bit那兒；將機(jī)房id左移放到5 bit那兒；將機(jī)器id左移放到5 bit那兒；將序號放***12 bit 
    // ***拼接起來成一個64 bit的二進(jìn)制數(shù)字，轉(zhuǎn)換成10進(jìn)制就是個long型 
    return ((timestamp - twepoch) << timestampLeftShift) | 
        (datacenterId << datacenterIdShift) | 
        (workerId << workerIdShift) | sequence; 
  } 
  private long tilNextMillis(long lastTimestamp) { 
 
    long timestamp = timeGen(); 
 
    while (timestamp <= lastTimestamp) { 
      timestamp = timeGen(); 
    } 
    return timestamp; 
  } 
  private long timeGen(){ 
    return System.currentTimeMillis(); 
  } 
  //---------------測試--------------- 
  public static void main(String[] args) { 
 
    IdWorker worker = new IdWorker(1,1,1); 
 
    for (int i = 0; i < 30; i++) { 
      System.out.println(worker.nextId()); 
    } 
  } 
} 

SnowFlake 算法一個小小的改進(jìn)思路：其實在實際的開發(fā)中，這個SnowFlake算法可以做一點點改進(jìn)。

因為大家可以考慮一下，我們在生成唯一 id 的時候，一般都需要指定一個表名，比如說訂單表的唯一 id。

所以上面那 64 個 bit 中，代表機(jī)房的那 5 個 bit，可以使用業(yè)務(wù)表名稱來替代，比如用 00001 代表的是訂單表。

因為其實很多時候，機(jī)房并沒有那么多，所以那 5 個 bit 用做機(jī)房 id 可能意義不是太大。

這樣就可以做到，SnowFlake 算法系統(tǒng)的每一臺機(jī)器，對一個業(yè)務(wù)表，在某一毫秒內(nèi)，可以生成一個唯一的 id，一毫秒內(nèi)生成很多 id，用*** 12 個 bit 來區(qū)分序號對待。

讀寫分離來支撐按需擴(kuò)容以及性能提升

這個時候整體效果已經(jīng)挺不錯了，大量分表的策略保證可能未來 10 年，每個表的數(shù)據(jù)量都不會太大，這可以保證單表內(nèi)的 SQL 執(zhí)行效率和性能。

然后多臺數(shù)據(jù)庫的拆分方式，可以保證每臺數(shù)據(jù)庫服務(wù)器承載一部分的讀寫請求，降低每臺服務(wù)器的負(fù)載。

但是此時還有一個問題，假如說每臺數(shù)據(jù)庫服務(wù)器承載每秒 2000 的請求，然后其中 400 請求是寫入，1600 請求是查詢。

也就是說，增刪改的 SQL 才占到了 20% 的比例，80% 的請求是查詢。此時假如說隨著用戶量越來越大，又變成每臺服務(wù)器承載 4000 請求了。

那么其中 800 請求是寫入，3200 請求是查詢，如果說你按照目前的情況來擴(kuò)容，就需要增加一臺數(shù)據(jù)庫服務(wù)器。

但是此時可能就會涉及到表的遷移，因為需要遷移一部分表到新的數(shù)據(jù)庫服務(wù)器上去，是不是很麻煩?

其實完全沒必要，數(shù)據(jù)庫一般都支持讀寫分離，也就是做主從架構(gòu)。

寫入的時候?qū)懭胫鲾?shù)據(jù)庫服務(wù)器，查詢的時候讀取從數(shù)據(jù)庫服務(wù)器，就可以讓一個表的讀寫請求分開落地到不同的數(shù)據(jù)庫上去執(zhí)行。

這樣的話，假如寫入主庫的請求是每秒 400，查詢從庫的請求是每秒 1600。

那么圖大概如下所示：

寫入主庫的時候，會自動同步數(shù)據(jù)到從庫上去，保證主庫和從庫數(shù)據(jù)一致。

然后查詢的時候都是走從庫去查詢的，這就通過數(shù)據(jù)庫的主從架構(gòu)實現(xiàn)了讀寫分離的效果了。

現(xiàn)在的好處就是，假如說現(xiàn)在主庫寫請求增加到 800，這個無所謂，不需要擴(kuò)容。然后從庫的讀請求增加到了 3200，需要擴(kuò)容了。

這時，你直接給主庫再掛載一個新的從庫就可以了，兩個從庫，每個從庫支撐 1600 的讀請求，不需要因為讀請求增長來擴(kuò)容主庫。

實際上線上生產(chǎn)你會發(fā)現(xiàn)，讀請求的增長速度遠(yuǎn)遠(yuǎn)高于寫請求，所以讀寫分離之后，大部分時候就是擴(kuò)容從庫支撐更高的讀請求就可以了。

而且另外一點，對同一個表，如果你既寫入數(shù)據(jù)(涉及加鎖)，還從該表查詢數(shù)據(jù)，可能會牽扯到鎖沖突等問題，無論是寫性能還是讀性能，都會有影響。

所以一旦讀寫分離之后，對主庫的表就僅僅是寫入，沒任何查詢會影響他，對從庫的表就僅僅是查詢。

高并發(fā)下的數(shù)據(jù)庫架構(gòu)設(shè)計總結(jié)

從大的一個簡化的角度來說，高并發(fā)的場景下，數(shù)據(jù)庫層面的架構(gòu)肯定是需要經(jīng)過精心的設(shè)計的。

尤其是涉及到分庫來支撐高并發(fā)的請求，大量分表保證每個表的數(shù)據(jù)量別太大，讀寫分離實現(xiàn)主庫和從庫按需擴(kuò)容以及性能保證。

這篇文章就是從一個大的角度來梳理了一下思路，各位同學(xué)可以結(jié)合自己公司的業(yè)務(wù)和項目來考慮自己的系統(tǒng)如何做分庫分表。

另外就是，具體的分庫分表落地的時候，需要借助數(shù)據(jù)庫中間件來實現(xiàn)分庫分表和讀寫分離，大家可以自己參考 Sharding-JDBC 或者 MyCAT 的官網(wǎng)即可，里面的文檔都有詳細(xì)的使用描述。

中華石杉：十余年 BAT 架構(gòu)經(jīng)驗，一線互聯(lián)網(wǎng)公司技術(shù)總監(jiān)。帶領(lǐng)上百人團(tuán)隊開發(fā)過多個億級流量高并發(fā)系統(tǒng)。現(xiàn)將多年工作中積累下的研究手稿、經(jīng)驗總結(jié)整理成文，傾囊相授。微信公眾號：石杉的架構(gòu)筆記(ID：shishan100)。