這篇文章主要介紹“怎么理解數(shù)據(jù)庫的分庫分表、讀寫分離問題”，在日常操作中，相信很多人在怎么理解數(shù)據(jù)庫的分庫分表、讀寫分離問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解數(shù)據(jù)庫的分庫分表、讀寫分離問題”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

成都創(chuàng)新互聯(lián)服務(wù)項目包括淇濱網(wǎng)站建設(shè)、淇濱網(wǎng)站制作、淇濱網(wǎng)頁制作以及淇濱網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，淇濱網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到淇濱省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

一、為什么要用分庫分表

當(dāng)不使用分庫分表的情況下，系統(tǒng)的性能瓶頸主要體現(xiàn)在：

• 當(dāng)面臨高并發(fā)場景的時候，為了避免MySQL崩潰（MySql性能一般的服務(wù)器建議2000/s讀寫并發(fā)以下），只能使用消息隊列來削峰。

• 受制于單機限制。數(shù)據(jù)庫磁盤容量吃緊。

• 數(shù)據(jù)庫單表數(shù)據(jù)量太大，sql越跑越慢

而分庫分表正是為了解決這些問題，提高數(shù)據(jù)庫讀寫并發(fā)量，磁盤容量大大提高，單表數(shù)據(jù)量降低，提高查詢效率。

二、垂直拆分和水平拆分

以表的維度來說：

• 垂直拆分 指根據(jù)表的字段進行拆分，其實很常見，有時候在數(shù)據(jù)庫設(shè)計的時候就完成了，屬于數(shù)據(jù)庫設(shè)計范式，如訂單表、訂單支付表、商品表。

• 水平拆分 表結(jié)構(gòu)一樣，數(shù)據(jù)進行拆分。如原本的t_order表變?yōu)閠_order_0,t_order_1，t_order_3

以庫的維度來說：

• 垂直拆分 指把原本的大庫，按業(yè)務(wù)不同拆到不同的庫（微服務(wù)一般都是這么設(shè)計的，即專庫專用）

• 水平拆分 一個服務(wù)對應(yīng)多個庫，每個庫有相同的業(yè)務(wù)表，如庫1有t_order表，庫2也有t_order表。業(yè)務(wù)系統(tǒng)通過數(shù)據(jù)庫中間件或中間層操作t_order表，分庫操作對于業(yè)務(wù)代碼透明。

所以，我們平常說的分庫分表，一般都是指的水平拆分

三、分庫分表工具

主要關(guān)注MyCat和sharding-jdbc。

兩者對比：

• MyCat:基于中間件的形式，提供讀寫分離、分庫、分表功能。只不過好久都沒更新了，我使用的是1.6版本，并不支持一個邏輯表的分庫、分表同時存在。

• sharding-jdbc：基于jar包中間層的形式，提供讀寫分離、分庫、分表功能。社區(qū)較活躍。支持功能強大。

四、分庫分表的兩種策略

• hash分法，按一個鍵進行hash取模，然后分發(fā)到某張表或庫。優(yōu)點是可以平攤每張表的壓力，缺點是擴容時會存在數(shù)據(jù)遷移問題。

• range分法，按范圍或時間分發(fā)，比如按某個鍵的值區(qū)間、或創(chuàng)建時間進行分發(fā)，優(yōu)點是可以很方便的進行擴容，缺點是會造成數(shù)據(jù)熱點問題。從分表上說還好，如果是分庫，將導(dǎo)致某一個庫節(jié)點壓力過大，節(jié)點間負(fù)載不均。

這里，我認(rèn)為最好的分法是hash分庫、range分表。因為對庫來說重要得是負(fù)載要均衡，對表來說重要的是可以動態(tài)擴容。

五、分庫分表數(shù)據(jù)遷移方案

停機分庫分表

方案很簡單，就是停機維護時，用后臺臨時程序基于數(shù)據(jù)庫中間件將老庫數(shù)據(jù)直接分發(fā)到需要遷移的數(shù)據(jù)庫

此方案的主要缺點是一定會出現(xiàn)幾個小時的停機，如果沒搞定要回滾，第二天繼續(xù)搞，開發(fā)人員心是慌得。

不停機雙寫方案

主要步驟：

• 修改系統(tǒng)中的所有寫庫的代碼，同時寫老庫和數(shù)據(jù)庫中間件（包括新增、更新、刪除操作）

• 然后后臺用工具將老庫之前的老庫數(shù)據(jù)遷移到新的數(shù)據(jù)庫中間件，注意比對修改時間，若id一樣，按修改時間決定是否覆蓋。

• 使用后臺工具比對一次數(shù)據(jù)，看是否完全一樣，不一樣，則后臺再用工具進行一次遷移。（避免有些數(shù)據(jù)因為網(wǎng)絡(luò)問題沒有遷移成功，或業(yè)務(wù)上的bug導(dǎo)致），這個過程通常需要好幾天。

• 以此循環(huán)幾次，數(shù)據(jù)完全一樣時，就切換為只讀寫新庫

該方案解決了停機造成的服務(wù)不可用。

六、分庫分表下的動態(tài)擴容問題

在分庫分表的情況下，如何在已經(jīng)分庫分表的基礎(chǔ)上進一步分庫分表提高系統(tǒng)效率，是一個麻煩的問題。特別是基于hash分片的服務(wù)器，再次分庫分表，一般只能對服務(wù)器進行停機，然后將所有數(shù)據(jù)又基于新的規(guī)則插入到不同的庫與表。為了避免這種問題，可以在第一次分庫分表的時候就將庫切分的較細，避免二次擴容。比如：

• 最開始就將庫分為32個庫，最開始業(yè)務(wù)量沒那么大，可以將多個庫放在同一臺機器上，以后按照2-4-8-16-32來進行擴容，如最開始2臺機器能夠滿足數(shù)據(jù)庫讀寫并發(fā)，此時一臺服務(wù)器上有16個庫，后來不夠了，就擴容為4臺機器，每臺機器8個庫。。。依次類推，這樣做的好處是只需要遷移需要遷移的庫，并且是按照整個庫進行遷移，不需要重新進行分發(fā)，同時分庫分表的分片機制也不用修改，只需要修改其數(shù)據(jù)源就行了。

• 對于分表來說，也可以分的多一些，推薦分為32張表。

• 以上，分為了32個庫32張表，總共數(shù)據(jù)量可以達到32 * 32 = 1024張表，按每張表500萬正常的容量來算，可以容納約50億數(shù)據(jù)，足以滿足大部分過擴容需求。

• 另外這種方案推薦擴容方案為2-4-8-16-32倍數(shù)進行擴容，深層原因是32是這些數(shù)的公倍數(shù)，按照約數(shù)進行擴容更容易讓每個機器負(fù)載的庫都一樣。

• 需要注意的是如果按照同一分片鍵進行同樣的分片策略分庫分表，會導(dǎo)致數(shù)據(jù)只會達到某庫的某表比如1庫的1表，2庫的2表，（因為庫和表的數(shù)量也是一樣）所以分庫我們可以按32取模策略，分表的話我們可以按整除之后的余數(shù)再對32取模進行分表。

七、全局id的生成策略

幾種生成id的方式對比：

• 通過數(shù)據(jù)庫自增

往公用的一張表（這張表是自增主鍵）插入一條數(shù)據(jù)，獲取id的返回值，用這個id再去插入中間件當(dāng)中去。oracle可以通過自增序列。

缺點：不適合并發(fā)高的場景，畢竟不管是自增序列還是采取自增鍵的方式來生成，會并發(fā)競爭寫鎖，效率太低。

• UUID

缺點：uuid太長了，不規(guī)則

• 時間戳

一般聯(lián)合其他業(yè)務(wù)字段拼接作為一個Id，如時間戳+用戶id+業(yè)務(wù)含義編碼

缺點：并發(fā)高容易重復(fù)

• 雪花算法

原理：前面1位為定值0+41位為時間戳+5位機房id+5位為機器id+12位為序號,唯一需要保證同步的地方是生成一個序號，鎖粒度較低。另外這個算法可用于分布式環(huán)境中。最大的優(yōu)點是不需要依賴任何中間件，核心原理是用5位機房id，5位機器id標(biāo)志了唯一一臺機器，所以不需要分布式鎖去保證不同機器生成id的同步性，只需要在當(dāng)前機器保證生成的序號不一樣就行了。

• redis中間件生成

原理：利用redis單線程工作線程屬性去維護一個自增變量。

八、讀寫分離

為什么要讀寫分離

• 理論上來說讀寫請求不要超過2000/s，如果加了緩存之后，到數(shù)據(jù)庫請求還是超過2000以上考慮讀寫分離

• 使得讀請求可以在不同機器并發(fā)，用了讀寫分離之后可以通過動態(tài)擴展讀服務(wù)器增加讀效率，這與redis中的主從架構(gòu)讀寫分離、copyOnWrite機制的并發(fā)容器、以及數(shù)據(jù)庫MVCC機制有點相識，都是通過讀請求的數(shù)據(jù)備份增加讀寫并發(fā)效率。

• 適用于業(yè)務(wù)場景中，讀請求大于寫請求的情況，讀寫分離使得系統(tǒng)能夠更多的容納讀請求并發(fā)。

讀寫分離的實現(xiàn)方式

一般來說是基于mysql自帶的主從復(fù)制功能。mysql主從復(fù)制的流程圖如下：

總結(jié)mysql的主從復(fù)制過程大體是主庫有一個進程專門是將將記錄的Binlog日志發(fā)送到從庫，從庫有一個io線程（5.6.x之后IO線程可以多線程寫入relay日志）將收到的數(shù)據(jù)寫入relay日志當(dāng)中，另外還有一個SQL進程專門讀取relay日志，根據(jù)relay日志重做命令(5.7版本之后，從可以并行讀取relay log重放命令（按庫并行，每個庫一個線程）)。

主從同步的三種模式：

• 異步模式（mysql async-mode）

異步模式如下圖所示，這種模式下，主節(jié)點不會主動push bin log到從節(jié)點，這樣有可能導(dǎo)致failover的情況下，也許從節(jié)點沒有即時地將最新的bin log同步到本地。

• 半同步模式（mysql semi-sync）

這種模式下主節(jié)點只需要接收到其中一臺從節(jié)點的返回信息，就會commit；否則需要等待直到超時時間然后切換成異步模式再提交；這樣做的目的可以使主從數(shù)據(jù)庫的數(shù)據(jù)延遲縮小，可以提高數(shù)據(jù)安全性，確保了事務(wù)提交后，binlog至少傳輸?shù)搅艘粋€從節(jié)點上，不能保證從節(jié)點將此事務(wù)更新到db中。性能上會有一定的降低，響應(yīng)時間會變長。如下圖所示：

• 同步模式（mysql semi-sync）

全同步模式是指主節(jié)點和從節(jié)點全部執(zhí)行了commit并確認(rèn)才會向客戶端返回成功。

讀寫分離場景下主從延遲可能導(dǎo)致的問題

在代碼中插入之后，又查詢這樣的操作是不可靠，可能導(dǎo)致插入之后，查出來的時候還沒有同步到從庫，所以查出來為null。如何應(yīng)對這種情況了？其實并不能從根本上解決這種情況的方案。只能一定程度通過降低主從延遲來盡量避免。

降低主從延遲的方法有：

• 拆主庫，降低主庫并發(fā)，降低主庫并發(fā)，此時主從延遲可以忽略不計，但并不能保證一定不會出現(xiàn)上述情況。

• 打開并行復(fù)制-但這個效果一般不大，因為寫入數(shù)據(jù)可能只針對某個庫并發(fā)高，而mysql的并行粒度并不小，是以庫為粒度的。

但這并不能根本性解決這個問題，其實面對這種情況最好的處理方式是：

• 重寫代碼，插入之后不要更新

• 如果確實是存在先插入，立馬就能查詢到，然后立馬執(zhí)行一些操作，那么可以對這個查詢設(shè)置直連主庫（通過中間件可以辦到）

到此，關(guān)于“怎么理解數(shù)據(jù)庫的分庫分表、讀寫分離問題”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
分享題目：怎么理解數(shù)據(jù)庫的分庫分表、讀寫分離問題
路徑分享：http://weahome.cn/article/pcpipi.html