數據是是一個企業(yè)的核心價值，現在每個企業(yè)都把數據視為公司核心機密。而數據庫是存儲數據的地方，在一個系統(tǒng)中的重要性更不言而喻。如何設計一個高性能的數據庫系統(tǒng)，直接影響一個系統(tǒng)的存亡。目前常用的架構方案有主備、主從、讀寫分離、雙主等，以及數據庫擴容方案分庫分表。今天講一講企業(yè)中常用的方案。

主備架構

主備架構是比較常見的架構方案，中有主庫提供讀寫服務，備份庫同步主庫數據，當主庫故障時系統(tǒng)自動切換至備份庫。

優(yōu)點：讀寫都操作主庫，不存在數據一致性問題。架構相對簡單運維成本比較低。

缺點：讀寫都在主庫，很容易產生系統(tǒng)瓶頸。大部分情況下讀多寫少，讀會先成為瓶頸，進而影響寫性能。備庫只是單純的備份，資源利用率低。只能通過建立索引和增加緩存的方式提高性能。

主從架構

主從架構也是一種比較常用的架構，一般會一主多從，讀寫分離進行實現。寫數據會在主庫上進行操作，然后從庫會同步主庫數據。讀數據只在從庫上進行操作，分擔了主庫的壓力。

優(yōu)點：一般大型系統(tǒng)讀多寫少，讀會成瓶頸，這樣的架構分擔了主庫的壓力。索引不用建在主庫，可以建在只用于查詢的從庫上，這樣可以提高寫的效率?？梢酝ㄟ^增加從庫來提高讀的性能。

缺點：存在單點故障，如果主庫掛了，寫操作無法進行。從庫越多，需要從主庫拉取日志的從庫端就越多，進而影響主庫的性能，并且數據同步完成的時間也會更長。

數據同步一致性問題

由于從庫拉取主庫數據一般通過日志方式，即主庫獲取日志記錄，然后同步到從庫上執(zhí)行。這個過程中可能存在延遲。假如一個用戶剛寫入一條數據，然后就開始刷新數據列表，這條數據有可能還未同步至從庫，造成無法顯示在用戶端。有以下方案進行解決：

選擇讀主

首先在寫數據的時候同時往緩存里寫一份數據，比如根據庫 表 業(yè)務特征生成一個key放到Cache里并設置超時時間（大于等于主從數據同步時間）。讀請求時，同樣的方式生成key先去查Cache，再判斷是否命中。若命中，則讀主庫，否則讀從庫。代價是多了一次緩存讀寫，基本可以忽略。

同步復制

同步復制等主從同步完成，寫請求才返回。這里利用數據庫自帶的功能，實現比較簡單。代價是寫請求時延增長，吞吐量降低。

強制讀主

比如一些剛剛存儲的數據，大概率還沒有同步到從庫的情況下，可以強制從主庫讀取。

分庫分表方案

數據庫瓶頸

服務器都有IO和CPU的瓶頸，隨著數據庫的活躍連接數增加，數據庫會達到活躍連接數的閾值。如果一個數據庫的列比較多，請求也比較多，這樣可以采用垂直分表方案，把數據分開放不同表，這樣可以加快讀速度。如果網絡IO也比較大，就可以采取垂直分庫技術，把數據存在在不同的數據庫，以加快返回速度。單表數據量太大，查詢時掃描的行太多，SQL效率低，CPU率先出現瓶頸，可以采用水平分表方式優(yōu)化。

水平分庫(表)

以字段為依據，按照一定策略（hash、range等），將一個庫中的數據拆分到多個庫(表)中。每個庫或表的結構都是一樣的，但是數據是不一致的，所有數據的并集就是全量數據。

如果庫只有一張表數據量大性能太低，就考慮水平分表。假如庫里的表字段相對比較少，數據量大且服務器運行達到極限，就要考慮水平分庫。水平分庫(表)主要解決單庫(表)數據量太大的問題。

垂直分庫(表)

以表為依據，按照業(yè)務歸屬不同，將不同的表字段拆分到不同的庫中。每個庫(表)結構都不一樣，每個庫(表)結構也不一樣，所有庫(表)數據的并集為全量數據。

表的記錄并不多，但是字段多，并且熱點數據和非熱點數據在一起，單行數據所需的存儲空間較大。以至于數據庫緩存的數據行減少，查詢時會去讀磁盤數據產生大量的隨機讀IO，產生IO瓶頸。這個時候就需要垂直分表。隨著業(yè)務的發(fā)展一些公用的配置表、字典表等越來越多，這時可以將這些表拆到單獨的庫?？傊褪歉鶕I(yè)務邏輯及運行情況，把數據進行拆分，減少單表字段很多的情況。