前言

我們都知道初創(chuàng)公司一開始都是以單體應(yīng)用為首要架構(gòu)，一般都是單體單庫的形式。但是版本以及版本的迭代，數(shù)據(jù)庫需要承受更多的高并發(fā)已經(jīng)成了 架構(gòu)設(shè)計 需要考慮的點。

那么解決問題，就得說到方案。但是方案有很多，我們該怎么選擇呢？

優(yōu)化與方案

基本上，我們優(yōu)化要從幾個關(guān)鍵字入手： 短距離 ， 少數(shù)據(jù) ， 分散壓力 。

短距離

所謂的短距離，指的是從前端到數(shù)據(jù)庫的路徑要短。

頁面靜態(tài)。有些頁面的數(shù)據(jù)是在某些時段是不變的，那么這個頁面可以靜態(tài)化，這樣可以提高訪問的速度。 使用緩存。緩存大家都知道，快的原因就是基于內(nèi)存。所以使用基于內(nèi)存的緩存的話，可以減少對數(shù)據(jù)庫的訪問，同時加速訪問速度。 批量讀取。高并發(fā)的情況下，可以將多個請求的查詢合在一次進行，以減少對數(shù)據(jù)庫的訪問速度。 延遲修改。延遲修改的意思高并發(fā)的情況西可能是將多次修改數(shù)據(jù)放在緩存中，然后定時將緩存中的數(shù)據(jù)過更新到數(shù)據(jù)庫；也可以是通過緩存的同步策略通過解析異步同步到數(shù)據(jù)庫中。 使用索引。這個不用說了，索引有著比較多的類型，例如普通索引/主鍵索引/組合索引/全文索引等。

少數(shù)據(jù)

所謂的少數(shù)據(jù)，其實是查詢的數(shù)據(jù)要少。

分表。所謂的分表，其實有水平切分和垂直拆分。玩過單機的小伙伴都知道，往往一些具有歷史性的表單，都會有成百上千萬級別的數(shù)據(jù)。這樣子對于 MySQL 來說，即使是加了索引，SQL 方面繼續(xù)優(yōu)化，也很難做到更快的查詢速度。那么我們可以通過分表的操作來實現(xiàn)。例如說最常見的我們可以根據(jù)時間的維度來進行表的水平拆分，今年的數(shù)據(jù)保持下來，而去年的數(shù)據(jù)可以存在另外一個表里。 分離活躍數(shù)據(jù)。其實這個有點類似緩存，但是不同之處在于數(shù)據(jù)還是在 MySQL 上面的。例如一個查詢商品的業(yè)務(wù)，有一些火爆/經(jīng)常被搜索的商品可以存在一張活躍表。查詢的時候先查詢活躍表，沒有的話再查詢總商品表。 分塊。這個分塊有點類似于算法里面的“索引順序查找”。通過數(shù)據(jù)層面的優(yōu)化，將數(shù)據(jù)放在不同的塊中，而我們只需要計算找到對應(yīng)的塊就行了。

分散壓力

所謂的分散壓力，其實是分散不同數(shù)據(jù)庫服務(wù)器的壓力

集群。集群的概念相信大家都很清楚，對于業(yè)務(wù)服務(wù)器來說其實就是具備相同業(yè)務(wù)流程的服務(wù)器部署多臺，通過負載均衡或其他方式來將請求分配到不同服務(wù)器。而數(shù)據(jù)庫也一樣，通過特定的規(guī)則策略將數(shù)據(jù)導(dǎo)向特定的數(shù)據(jù)庫服務(wù)器上。 分布式。所謂的分布式，其實就是將原本處于同個流程的業(yè)務(wù)邏輯分配到不同的服務(wù)器上面執(zhí)行，達到了“并發(fā)”執(zhí)行的效果，加快執(zhí)行速度。 分庫分表。分庫分表主要是水平拆分和垂直拆分。對于訪問頻率高而數(shù)據(jù)量巨大的單表，可以減少單表的數(shù)據(jù)，根據(jù)特定的維度進行水平拆分，增加數(shù)據(jù)庫的吞吐量，這就是 分表水平拆分 ；而對于業(yè)務(wù)耦合性低的多表來說，可以將不同的表存儲在不同的數(shù)據(jù)庫上，對數(shù)據(jù)庫進行垂直拆分，提高數(shù)據(jù)庫寫的能力，即 分庫的垂直拆分 。 建立主從。建立主從的目的其實就是為了讀寫分離。我們都知道，只要數(shù)據(jù)庫的事務(wù)級別夠高，那么并發(fā)讀是不會影響到數(shù)據(jù)的混亂，而并發(fā)寫則會。所以建立主從一般來說，寫會留在主服務(wù)器上寫，而會在從服務(wù)器上讀。 所以基本上讓主服務(wù)器進行事務(wù)性操作，從服務(wù)器進行 select 查詢。這樣子的話，事務(wù)性操作（增加/刪除/修改）導(dǎo)致的改變更新同步到集群中的從數(shù)據(jù)庫 。

結(jié)語

以上就是MySQL 如何處理高并發(fā)的詳細內(nèi)容，更多關(guān)于MySQL 高并發(fā)的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！