蜜桃av色欲a片精品一区,麻豆aⅴ精品无码一区二区,亚洲人成网站在线播放影院在线,亚洲 素人 字幕 在线 最新

  好好的系統(tǒng)，為什么要分庫(kù)分表？

發(fā)布日期：2022/11/25 10:36:52      瀏覽量：

今天是《分庫(kù)分表 ShardingSphere 原理與實(shí)戰(zhàn)》系列的開(kāi)篇文章，之前寫(xiě)過(guò)幾篇關(guān)于分庫(kù)分表的文章反響都還不錯(cuò)，到現(xiàn)在公眾號(hào):程序員小富后臺(tái)不斷的有人留言、咨詢(xún)分庫(kù)分表的問(wèn)題，我也沒(méi)想到大家對(duì)于分庫(kù)分表的話(huà)題會(huì)這么感興趣，可能很多人的工作內(nèi)容業(yè)務(wù)量較小很難接觸到這方面的技能。這個(gè)系列在我腦子里籌劃了挺久的，奈何手說(shuō)啥也不干活，就一直拖到了現(xiàn)在。

其實(shí)網(wǎng)上關(guān)于分庫(kù)分表相關(guān)的文章很多，但我還是堅(jiān)持出這個(gè)系列，主要是自己學(xué)習(xí)研究，順便給分享，對(duì)于一個(gè)知識(shí)，不同的人從不同的角度理解的不盡相同。

網(wǎng)上的資料看似很多，不過(guò)值得學(xué)有價(jià)值的得仔細(xì)挑，很多時(shí)候在篩選甄別的過(guò)程中，逐漸的磨滅了本就不高的學(xué)習(xí)熱情。搬運(yùn)抄襲雷同的東西太多，而且知識(shí)點(diǎn)又都比較零碎，很少有細(xì)致的原理實(shí)戰(zhàn)案例。對(duì)新手來(lái)說(shuō)妥妥的從入門(mén)到放棄，即便有成體系的基本上幾篇后就斷更了（希望我不會(huì)吧?。?。

我不太喜歡堆砌名詞概念，熟悉我的朋友不難發(fā)現(xiàn)，我的文章從來(lái)都是講完原理緊跟著來(lái)一波實(shí)戰(zhàn)操作。學(xué)習(xí)技術(shù)原理必須配合實(shí)操鞏固一下，不然三天半不到忘得干干凈凈，純純的經(jīng)驗(yàn)之談。

上圖是我初步羅列的ShardingSphere提綱，在官網(wǎng)文檔基礎(chǔ)上補(bǔ)充了很多基礎(chǔ)知識(shí)，這個(gè)系列會(huì)用幾十篇文章，詳細(xì)的梳理分庫(kù)分表基礎(chǔ)理論，手把手的實(shí)戰(zhàn)ShardingSphere 5.X框架的功能和解讀源碼，以及開(kāi)發(fā)中容易踩坑的點(diǎn)，每篇附帶代碼案例demo，旨在讓新手也能看的懂，后續(xù)系列完結(jié)全部?jī)?nèi)容會(huì)整理成PDF分享給大家，期待一下吧！

話(huà)不多說(shuō)，咱們這就進(jìn)入正題～

不急于上手實(shí)戰(zhàn)ShardingSphere框架，先來(lái)復(fù)習(xí)下分庫(kù)分表的基礎(chǔ)概念，技術(shù)名詞大多晦澀難懂，不要死記硬背理解最重要，當(dāng)你捅破那層窗戶(hù)紙，發(fā)現(xiàn)其實(shí)它也就那么回事。

什么是分庫(kù)分表

分庫(kù)分表是在海量數(shù)據(jù)下，由于單庫(kù)、表數(shù)據(jù)量過(guò)大，導(dǎo)致數(shù)據(jù)庫(kù)性能持續(xù)下降的問(wèn)題，演變出的技術(shù)方案。

分庫(kù)分表是由分庫(kù)和分表這兩個(gè)獨(dú)立概念組成的，只不過(guò)通常分庫(kù)與分表的操作會(huì)同時(shí)進(jìn)行，以至于我們習(xí)慣性的將它們合在一起叫做分庫(kù)分表。

通過(guò)一定的規(guī)則，將原本數(shù)據(jù)量大的數(shù)據(jù)庫(kù)拆分成多個(gè)單獨(dú)的數(shù)據(jù)庫(kù)，將原本數(shù)據(jù)量大的表拆分成若干個(gè)數(shù)據(jù)表，使得單一的庫(kù)、表性能達(dá)到最優(yōu)的效果（響應(yīng)速度快），以此提升整體數(shù)據(jù)庫(kù)性能。

為什么分庫(kù)分表

單機(jī)數(shù)據(jù)庫(kù)的存儲(chǔ)能力、連接數(shù)是有限的，它自身就很容易會(huì)成為系統(tǒng)的瓶頸。當(dāng)單表數(shù)據(jù)量在百萬(wàn)以里時(shí)，我們還可以通過(guò)添加從庫(kù)、優(yōu)化索引提升性能。

一旦數(shù)據(jù)量朝著千萬(wàn)以上趨勢(shì)增長(zhǎng)，再怎么優(yōu)化數(shù)據(jù)庫(kù)，很多操作性能仍下降嚴(yán)重。為了減少數(shù)據(jù)庫(kù)的負(fù)擔(dān)，提升數(shù)據(jù)庫(kù)響應(yīng)速度，縮短查詢(xún)時(shí)間，這時(shí)候就需要進(jìn)行分庫(kù)分表。

為什么需要分庫(kù)？

容量

我們給數(shù)據(jù)庫(kù)實(shí)例分配的磁盤(pán)容量是固定的，數(shù)據(jù)量持續(xù)的大幅增長(zhǎng)，用不了多久單機(jī)的容量就會(huì)承載不了這么多數(shù)據(jù)，解決辦法簡(jiǎn)單粗暴，加容量！

連接數(shù)

單機(jī)的容量可以隨意擴(kuò)展，但數(shù)據(jù)庫(kù)的連接數(shù)卻是有限的，在高并發(fā)場(chǎng)景下多個(gè)業(yè)務(wù)同時(shí)對(duì)一個(gè)數(shù)據(jù)庫(kù)操作，很容易將連接數(shù)耗盡導(dǎo)致too many connections報(bào)錯(cuò)，導(dǎo)致后續(xù)數(shù)據(jù)庫(kù)無(wú)法正常訪(fǎng)問(wèn)。

可以通過(guò)max_connections查看MySQL最大連接數(shù)。

show variables like ’%max_connections%’ 

將原本單數(shù)據(jù)庫(kù)按不同業(yè)務(wù)拆分成訂單庫(kù)、物流庫(kù)、積分庫(kù)等不僅可以有效分?jǐn)倲?shù)據(jù)庫(kù)讀寫(xiě)壓力，也提高了系統(tǒng)容錯(cuò)性。

為什么需要分表？

做過(guò)報(bào)表業(yè)務(wù)的同學(xué)應(yīng)該都體驗(yàn)過(guò)，一條SQL執(zhí)行時(shí)間超過(guò)幾十秒的場(chǎng)景。

導(dǎo)致數(shù)據(jù)庫(kù)查詢(xún)慢的原因有很多，SQL沒(méi)命中索引、like掃全表、用了函數(shù)計(jì)算，這些都可以通過(guò)優(yōu)化手段解決，可唯獨(dú)數(shù)據(jù)量大是MySQL無(wú)法通過(guò)自身優(yōu)化解決的。慢的根本原因是InnoDB存儲(chǔ)引擎，聚簇索引結(jié)構(gòu)的 B+tree 層級(jí)變高，磁盤(pán)IO變多查詢(xún)性能變慢，詳細(xì)原理自行查找一下，這里不用過(guò)多篇幅說(shuō)明。

阿里的開(kāi)發(fā)手冊(cè)中有條建議，單表行數(shù)超500萬(wàn)行或者單表容量超過(guò)2GB，就推薦分庫(kù)分表，然而理想和實(shí)現(xiàn)總是有差距的，阿里這種體量的公司不差錢(qián)當(dāng)然可以這么用，實(shí)際上很多公司單表數(shù)據(jù)幾千萬(wàn)、億級(jí)別仍然不選擇分庫(kù)分表。

什么時(shí)候分庫(kù)分表

技術(shù)群里經(jīng)常會(huì)有小伙伴問(wèn)，到底什么情況下會(huì)用分庫(kù)分表呢？

分庫(kù)分表要解決的是現(xiàn)存海量數(shù)據(jù)訪(fǎng)問(wèn)的性能瓶頸，對(duì)持續(xù)激增的數(shù)據(jù)量所做出的架構(gòu)預(yù)見(jiàn)性。

是否分庫(kù)分表的關(guān)鍵指標(biāo)是數(shù)據(jù)量，我們以fire100.top這個(gè)網(wǎng)站的資源表 t_resource為例，系統(tǒng)在運(yùn)行初始的時(shí)候，每天只有可憐的幾十個(gè)資源上傳，這時(shí)使用單庫(kù)、單表的方式足以支持系統(tǒng)的存儲(chǔ)，數(shù)據(jù)量小幾乎沒(méi)什么數(shù)據(jù)庫(kù)性能瓶頸。

但某天開(kāi)始一股神秘的流量進(jìn)入，系統(tǒng)每日產(chǎn)生的資源數(shù)據(jù)量暴增至十萬(wàn)甚至上百萬(wàn)級(jí)別，這時(shí)資源表數(shù)據(jù)量到達(dá)千萬(wàn)級(jí)，查詢(xún)響應(yīng)變得緩慢，數(shù)據(jù)庫(kù)的性能瓶頸逐漸顯現(xiàn)。

以MySQL數(shù)據(jù)庫(kù)為例，單表的數(shù)據(jù)量在達(dá)到億條級(jí)別，通過(guò)加索引、SQL調(diào)優(yōu)等傳統(tǒng)優(yōu)化策略，性能提升依舊微乎其微時(shí)，就可以考慮做分庫(kù)分表了。

既然MySQL存儲(chǔ)海量數(shù)據(jù)時(shí)會(huì)出現(xiàn)性能瓶頸，那么我們是不是可以考慮用其他方案替代它？比如高性能的非關(guān)系型數(shù)據(jù)庫(kù)MongoDB？

可以，但要看存儲(chǔ)的數(shù)據(jù)類(lèi)型！

現(xiàn)在互聯(lián)網(wǎng)上大部分公司的核心數(shù)據(jù)幾乎是存儲(chǔ)在關(guān)系型數(shù)據(jù)庫(kù)（MySQL、Oracle等），因?yàn)樗鼈冇兄鳱oSQL如法比擬的穩(wěn)定性和可靠性，產(chǎn)品成熟生態(tài)系統(tǒng)完善，還有核心的事務(wù)功能特性，也是其他存儲(chǔ)工具不具備的，而評(píng)論、點(diǎn)贊這些非核心數(shù)據(jù)還是可以考慮用MongoDB的。

如何分庫(kù)分表

分庫(kù)分表的核心就是對(duì)數(shù)據(jù)的分片（Sharding）并相對(duì)均勻的路由在不同的庫(kù)、表中，以及分片后對(duì)數(shù)據(jù)的快速定位與檢索結(jié)果的整合。

分庫(kù)與分表可以從：垂直（縱向）和 水平（橫向）兩種緯度進(jìn)行拆分。下邊我們以經(jīng)典的訂單業(yè)務(wù)舉例，看看如何拆分。

垂直拆分

1、垂直分庫(kù)

垂直分庫(kù)一般來(lái)說(shuō)按照業(yè)務(wù)和功能的維度進(jìn)行拆分，將不同業(yè)務(wù)數(shù)據(jù)分別放到不同的數(shù)據(jù)庫(kù)中，核心理念 專(zhuān)庫(kù)專(zhuān)用。

按業(yè)務(wù)類(lèi)型對(duì)數(shù)據(jù)分離，剝離為多個(gè)數(shù)據(jù)庫(kù)，像訂單、支付、會(huì)員、積分相關(guān)等表放在對(duì)應(yīng)的訂單庫(kù)、支付庫(kù)、會(huì)員庫(kù)、積分庫(kù)。不同業(yè)務(wù)禁止跨庫(kù)直連，獲取對(duì)方業(yè)務(wù)數(shù)據(jù)一律通過(guò)API接口交互，這也是微服務(wù)拆分的一個(gè)重要依據(jù)。

垂直分庫(kù)很大程度上取決于業(yè)務(wù)的劃分，但有時(shí)候業(yè)務(wù)間的劃分并不是那么清晰，比如：電商中訂單數(shù)據(jù)的拆分，其他很多業(yè)務(wù)都依賴(lài)于訂單數(shù)據(jù)，有時(shí)候界線(xiàn)不是很好劃分。

垂直分庫(kù)把一個(gè)庫(kù)的壓力分?jǐn)偟蕉鄠€(gè)庫(kù)，提升了一些數(shù)據(jù)庫(kù)性能，但并沒(méi)有解決由于單表數(shù)據(jù)量過(guò)大導(dǎo)致的性能問(wèn)題，所以就需要配合后邊的分表來(lái)解決。

2、垂直分表

垂直分表針對(duì)業(yè)務(wù)上字段比較多的大表進(jìn)行的，一般是把業(yè)務(wù)寬表中比較獨(dú)立的字段，或者不常用的字段拆分到單獨(dú)的數(shù)據(jù)表中，是一種大表拆小表的模式。

例如：一張t_order訂單表上有幾十個(gè)字段，其中訂單金額相關(guān)字段計(jì)算頻繁，為了不影響訂單表t_order的性能，就可以把訂單金額相關(guān)字段拆出來(lái)單獨(dú)維護(hù)一個(gè)t_order_price_expansion擴(kuò)展表，這樣每張表只存儲(chǔ)原表的一部分字段，通過(guò)訂單號(hào)order_no做關(guān)聯(lián)，再將拆分出來(lái)的表路由到不同的庫(kù)中。

數(shù)據(jù)庫(kù)它是以行為單位將數(shù)據(jù)加載到內(nèi)存中，這樣拆分以后核心表大多是訪(fǎng)問(wèn)頻率較高的字段，而且字段長(zhǎng)度也都較短，因而可以加載更多數(shù)據(jù)到內(nèi)存中，減少磁盤(pán)IO，增加索引查詢(xún)的命中率，進(jìn)一步提升數(shù)據(jù)庫(kù)性能。

水平拆分

上邊垂直分庫(kù)、垂直分表后還是會(huì)存在單庫(kù)、表數(shù)據(jù)量過(guò)大的問(wèn)題，當(dāng)我們的應(yīng)用已經(jīng)無(wú)法在細(xì)粒度的垂直切分時(shí)，依舊存在單庫(kù)讀寫(xiě)、存儲(chǔ)性能瓶頸，這時(shí)就要配合水平分庫(kù)、水平分表一起了。

1、水平分庫(kù)

水平分庫(kù)是把同一個(gè)表按一定規(guī)則拆分到不同的數(shù)據(jù)庫(kù)中，每個(gè)庫(kù)可以位于不同的服務(wù)器上，以此實(shí)現(xiàn)水平擴(kuò)展，是一種常見(jiàn)的提升數(shù)據(jù)庫(kù)性能的方式。

例如：db_orde_1、db_order_2兩個(gè)數(shù)據(jù)庫(kù)內(nèi)有完全相同的t_order表，我們?cè)谠L(fǎng)問(wèn)某一筆訂單時(shí)可以通過(guò)對(duì)訂單的訂單編號(hào)取模的方式 訂單編號(hào) mod 2 （數(shù)據(jù)庫(kù)實(shí)例數(shù)） ，指定該訂單應(yīng)該在哪個(gè)數(shù)據(jù)庫(kù)中操作。

這種方案往往能解決單庫(kù)存儲(chǔ)量及性能瓶頸問(wèn)題，但由于同一個(gè)表被分配在不同的數(shù)據(jù)庫(kù)中，數(shù)據(jù)的訪(fǎng)問(wèn)需要額外的路由工作，因此系統(tǒng)的復(fù)雜度也被提升了。

2、水平分表

水平分表是在同一個(gè)數(shù)據(jù)庫(kù)內(nèi)，把一張大數(shù)據(jù)量的表按一定規(guī)則，切分成多個(gè)結(jié)構(gòu)完全相同表，而每個(gè)表只存原表的一部分?jǐn)?shù)據(jù)。

例如：一張t_order訂單表有900萬(wàn)數(shù)據(jù)，經(jīng)過(guò)水平拆分出來(lái)三個(gè)表，t_order_1、t_order_2、t_order_3，每張表存有數(shù)據(jù)300萬(wàn)，以此類(lèi)推。

水平分表盡管拆分了表，但子表都還是在同一個(gè)數(shù)據(jù)庫(kù)實(shí)例中，只是解決了單一表數(shù)據(jù)量過(guò)大的問(wèn)題，并沒(méi)有將拆分后的表分散到不同的機(jī)器上，還在競(jìng)爭(zhēng)同一個(gè)物理機(jī)的CPU、內(nèi)存、網(wǎng)絡(luò)IO等。要想進(jìn)一步提升性能，就需要將拆分后的表分散到不同的數(shù)據(jù)庫(kù)中，達(dá)到分布式的效果。

數(shù)據(jù)存在哪個(gè)庫(kù)的表

分庫(kù)分表以后會(huì)出現(xiàn)一個(gè)問(wèn)題，一張表會(huì)出現(xiàn)在多個(gè)數(shù)據(jù)庫(kù)里，到底該往哪個(gè)庫(kù)的哪個(gè)表里存呢？

上邊我們多次提到過(guò)一定規(guī)則 ，其實(shí)這個(gè)規(guī)則它是一種路由算法，決定了一條數(shù)據(jù)具體應(yīng)該存在哪個(gè)數(shù)據(jù)庫(kù)的哪張表里。

常見(jiàn)的有 取模算法 、范圍限定算法、范圍+取模算法 、預(yù)定義算法

1、取模算法

關(guān)鍵字段取模（對(duì)hash結(jié)果取余數(shù) hash(XXX) mod N)，N為數(shù)據(jù)庫(kù)實(shí)例數(shù)或子表數(shù)量）是最為常見(jiàn)的一種路由方式。

以t_order訂單表為例，先給數(shù)據(jù)庫(kù)從 0 到 N-1進(jìn)行編號(hào)，對(duì) t_order訂單表中order_no訂單編號(hào)字段進(jìn)行取模hash(order_no) mod N，得到余數(shù)i。i=0存第一個(gè)庫(kù)，i=1存第二個(gè)庫(kù)，i=2存第三個(gè)庫(kù)，以此類(lèi)推。

同一筆訂單數(shù)據(jù)會(huì)落在同一個(gè)庫(kù)、表里，查詢(xún)時(shí)用相同的規(guī)則，用t_order訂單編號(hào)作為查詢(xún)條件，就能快速的定位到數(shù)據(jù)。

優(yōu)點(diǎn)

實(shí)現(xiàn)簡(jiǎn)單，數(shù)據(jù)分布相對(duì)比較均勻，不易出現(xiàn)請(qǐng)求都打到一個(gè)庫(kù)上的情況。

缺點(diǎn)

取模算法對(duì)集群的伸縮支持不太友好，集群中有N個(gè)數(shù)據(jù)庫(kù)實(shí)·hash(user_id) mod N，當(dāng)某一臺(tái)機(jī)器宕機(jī)，本應(yīng)該落在該數(shù)據(jù)庫(kù)的請(qǐng)求就無(wú)法得到處理，這時(shí)宕掉的實(shí)例會(huì)被踢出集群。

此時(shí)機(jī)器數(shù)減少算法發(fā)生變化hash(user_id) mod N-1，同一用戶(hù)數(shù)據(jù)落在了在不同數(shù)據(jù)庫(kù)中，等這臺(tái)機(jī)器恢復(fù)，用user_id作為條件查詢(xún)用戶(hù)數(shù)據(jù)就會(huì)少一部分。

2、范圍限定算法

范圍限定算法以某些范圍字段，如時(shí)間或ID區(qū)拆分。

用戶(hù)表t_user被拆分成t_user_1、t_user_2、t_user_3三張表，后續(xù)將user_id范圍為1 ~ 1000w的用戶(hù)數(shù)據(jù)放入t_user_1，1000~ 2000w放入t_user_2，2000~3000w放入t_user_3，以此類(lèi)推。按日期范圍劃分同理。

優(yōu)點(diǎn)

• 單表數(shù)據(jù)量是可控的
• 水平擴(kuò)展簡(jiǎn)單只需增加節(jié)點(diǎn)即可，無(wú)需對(duì)其他分片的數(shù)據(jù)進(jìn)行遷移

缺點(diǎn)

• 由于連續(xù)分片可能存在數(shù)據(jù)熱點(diǎn)，比如按時(shí)間字段分片時(shí)，如果某一段時(shí)間（雙11等大促）訂單驟增，存11月數(shù)據(jù)的表可能會(huì)被頻繁的讀寫(xiě)，其他分片表存儲(chǔ)的歷史數(shù)據(jù)則很少被查詢(xún)，導(dǎo)致數(shù)據(jù)傾斜，數(shù)據(jù)庫(kù)壓力分?jǐn)偛痪鶆颉?

3、范圍 + 取模算法

為了避免熱點(diǎn)數(shù)據(jù)的問(wèn)題，我們可以對(duì)上范圍算法優(yōu)化一下

這次我們先通過(guò)范圍算法定義每個(gè)庫(kù)的用戶(hù)表t_user只存1000w數(shù)據(jù)，第一個(gè)db_order_1庫(kù)存放userId從1 ~ 1000w，第二個(gè)庫(kù)1000_{2000w，第三個(gè)庫(kù)2000}3000w，以此類(lèi)推。

每個(gè)庫(kù)里再把用戶(hù)表t_user拆分成t_user_1、t_user_2、t_user_3等，對(duì)userd進(jìn)行取模路由到對(duì)應(yīng)的表中。

有效的避免數(shù)據(jù)分布不均勻的問(wèn)題，數(shù)據(jù)庫(kù)水平擴(kuò)展也簡(jiǎn)單，直接添加實(shí)例無(wú)需遷移歷史數(shù)據(jù)。

4、地理位置分片

地理位置分片其實(shí)是一個(gè)更大的范圍，按城市或者地域劃分，比如華東、華北數(shù)據(jù)放在不同的分片庫(kù)、表。

5、預(yù)定義算法

預(yù)定義算法是事先已經(jīng)明確知道分庫(kù)和分表的數(shù)量，可以直接將某類(lèi)數(shù)據(jù)路由到指定庫(kù)或表中，查詢(xún)的時(shí)候亦是如此。

分庫(kù)分表出來(lái)的問(wèn)題

了解了上邊分庫(kù)分表的拆分方式不難發(fā)現(xiàn)，相比于拆分前的單庫(kù)單表，系統(tǒng)的數(shù)據(jù)存儲(chǔ)架構(gòu)演變到現(xiàn)在已經(jīng)變得非常復(fù)雜?？磶讉€(gè)具有代表性的問(wèn)題，比如：

分頁(yè)、排序、跨節(jié)點(diǎn)聯(lián)合查詢(xún)

分頁(yè)、排序、聯(lián)合查詢(xún)，這些看似普通，開(kāi)發(fā)中使用頻率較高的操作，在分庫(kù)分表后卻是讓人非常頭疼的問(wèn)題。把分散在不同庫(kù)中表的數(shù)據(jù)查詢(xún)出來(lái)，再將所有結(jié)果進(jìn)行匯總合并整理后提供給用戶(hù)。

比如：我們要查詢(xún)11、12月的訂單數(shù)據(jù)，如果兩個(gè)月的數(shù)據(jù)是分散到了不同的數(shù)據(jù)庫(kù)實(shí)例，則要查詢(xún)兩個(gè)數(shù)據(jù)庫(kù)相關(guān)的數(shù)據(jù)，在對(duì)數(shù)據(jù)合并排序、分頁(yè)，過(guò)程繁瑣復(fù)雜。

事務(wù)一致性

分庫(kù)分表后由于表分布在不同庫(kù)中，不可避免會(huì)帶來(lái)跨庫(kù)事務(wù)問(wèn)題。后續(xù)會(huì)分別以阿里的Seata和MySQL的XA協(xié)議實(shí)現(xiàn)分布式事務(wù)，用來(lái)比較各自的優(yōu)勢(shì)與不足。

全局唯一的主鍵

分庫(kù)分表后數(shù)據(jù)庫(kù)表的主鍵ID業(yè)務(wù)意義就不大了，因?yàn)闊o(wú)法在標(biāo)識(shí)唯一一條記錄，例如：多張表t_order_1、t_order_2的主鍵ID全部從1開(kāi)始會(huì)重復(fù)，此時(shí)我們需要主動(dòng)為一條記錄分配一個(gè)ID，這個(gè)全局唯一的ID就叫分布式ID，發(fā)放這個(gè)ID的系統(tǒng)通常被叫發(fā)號(hào)器。

多數(shù)據(jù)庫(kù)高效治理

對(duì)多個(gè)數(shù)據(jù)庫(kù)以及庫(kù)內(nèi)大量分片表的高效治理，是非常有必要，因?yàn)橄衲硨氝@種大廠一次大促下來(lái)，訂單表可能會(huì)被拆分成成千上萬(wàn)個(gè)t_order_n表，如果沒(méi)有高效的管理方案，手動(dòng)建表、排查問(wèn)題是一件很恐怖的事。

歷史數(shù)據(jù)遷移

分庫(kù)分表架構(gòu)落地以后，首要的問(wèn)題就是如何平滑的遷移歷史數(shù)據(jù)，增量數(shù)據(jù)和全量數(shù)據(jù)遷移，這又是一個(gè)比較麻煩的事情，后邊詳細(xì)講。

分庫(kù)分表架構(gòu)模式

分庫(kù)分表架構(gòu)主要有兩種模式：client客戶(hù)端模式和proxy代理模式

客戶(hù)模式

client模式指分庫(kù)分表的邏輯都在你的系統(tǒng)應(yīng)用內(nèi)部進(jìn)行控制，應(yīng)用會(huì)將拆分后的SQL直連多個(gè)數(shù)據(jù)庫(kù)進(jìn)行操作，然后本地進(jìn)行數(shù)據(jù)的合并匯總等操作。

代理模式

proxy代理模式將應(yīng)用程序與MySQL數(shù)據(jù)庫(kù)隔離，業(yè)務(wù)方的應(yīng)用不在需要直連數(shù)據(jù)庫(kù)，而是連接proxy代理服務(wù)，代理服務(wù)實(shí)現(xiàn)了MySQL的協(xié)議，對(duì)業(yè)務(wù)方來(lái)說(shuō)代理服務(wù)就是數(shù)據(jù)庫(kù)，它會(huì)將SQL分發(fā)到具體的數(shù)據(jù)庫(kù)進(jìn)行執(zhí)行，并返回結(jié)果。該服務(wù)內(nèi)有分庫(kù)分表的配置，根據(jù)配置自動(dòng)創(chuàng)建分片表。

如何抉擇

如何選擇client模式和proxy模式，我們可以從以下幾個(gè)方面來(lái)簡(jiǎn)單做下比較。

1、性能

性能方面client模式表現(xiàn)的稍好一些，它是直接連接MySQL執(zhí)行命令；
proxy代理服務(wù)則將整個(gè)執(zhí)行鏈路延長(zhǎng)了，應(yīng)用->代理服務(wù)->MySQL，可能導(dǎo)致性能有一些損耗，但兩者差距并不是非常大。

2、復(fù)雜度

client模式在開(kāi)發(fā)使用通常引入一個(gè)jar可以；
proxy代理模式則需要搭建單獨(dú)的服務(wù)，有一定的維護(hù)成本，既然是服務(wù)那么就要考慮高可用，畢竟應(yīng)用的所有SQL都要通過(guò)它轉(zhuǎn)發(fā)至MySQL。

3、升級(jí)

client模式分庫(kù)分表一般是依賴(lài)基礎(chǔ)架構(gòu)團(tuán)隊(duì)的Jar包，一旦有版本升級(jí)或者Bug修改，所有應(yīng)用到的項(xiàng)目都要跟著升級(jí)。小規(guī)模的團(tuán)隊(duì)服務(wù)少升級(jí)問(wèn)題不大，如果是大公司服務(wù)規(guī)模大，且涉及到跨多部門(mén)，那么升級(jí)一次成本就比較高；

proxy模式在升級(jí)方面優(yōu)勢(shì)很明顯，發(fā)布新功能或者修復(fù)Bug，只要重新部署代理服務(wù)集群即可，業(yè)務(wù)方是無(wú)感知的，但要保證發(fā)布過(guò)程中服務(wù)的可用性。

4、治理、監(jiān)控

client模式由于是內(nèi)嵌在應(yīng)用內(nèi)，應(yīng)用集群部署不太方便統(tǒng)一處理；proxy模式在對(duì)SQL限流、讀寫(xiě)權(quán)限控制、監(jiān)控、告警等服務(wù)治理方面更優(yōu)雅一些。

結(jié)束語(yǔ)