建站
咨詢
售后
建站咨詢
新聞中心
一、基本概念
創(chuàng)新互聯(lián)建站憑借專業(yè)的設(shè)計團(tuán)隊扎實的技術(shù)支持、優(yōu)質(zhì)高效的服務(wù)意識和豐厚的資源優(yōu)勢，提供專業(yè)的網(wǎng)站策劃、成都網(wǎng)站制作、網(wǎng)站設(shè)計、網(wǎng)站優(yōu)化、軟件開發(fā)、網(wǎng)站改版等服務(wù)，在成都十載的網(wǎng)站建設(shè)設(shè)計經(jīng)驗，為成都上千多家中小型企業(yè)策劃設(shè)計了網(wǎng)站。
概念一：單庫
概念二：分片
分片解決“數(shù)據(jù)量太大”這一問題，也就是通常說的“水平切分”。
一旦引入分片，勢必面臨“數(shù)據(jù)路由”的新問題，數(shù)據(jù)到底要訪問哪個庫。路由規(guī)則通常有3種方法：
(1)范圍：range
- 優(yōu)點(diǎn)：簡單，容易擴(kuò)展。
- 缺點(diǎn)：各庫壓力不均(新號段更活躍)。
(2)哈希：hash
- 優(yōu)點(diǎn)：簡單，數(shù)據(jù)均衡，負(fù)載均勻。
- 缺點(diǎn)：遷移麻煩(2庫擴(kuò)3庫數(shù)據(jù)要遷移)。
(3)統(tǒng)一路由服務(wù)：router-config-server
- 優(yōu)點(diǎn)：靈活性強(qiáng)，業(yè)務(wù)與路由算法解耦。
- 缺點(diǎn)：每次訪問數(shù)據(jù)庫前多一次查詢。
大部分互聯(lián)網(wǎng)公司采用的方案二：哈希路由。
概念三：分組
分組解決“可用性，性能提升”這一問題，分組通常通過主從復(fù)制的方式實現(xiàn)。
互聯(lián)網(wǎng)公司數(shù)據(jù)庫實際軟件架構(gòu)是“既分片，又分組”：
數(shù)據(jù)庫軟件架構(gòu)，究竟設(shè)計些什么呢，至少要考慮以下四點(diǎn)：
- 如何保證數(shù)據(jù)可用性
- 如何提高數(shù)據(jù)庫讀性能(大部分應(yīng)用讀多寫少，讀會先成為瓶頸)
- 如何保證一致性
- 如何提高擴(kuò)展性
二、如何保證數(shù)據(jù)的可用性?
解決可用性問題的思路是：冗余。
- 如何保證站點(diǎn)的可用性?冗余站點(diǎn)。
- 如何保證服務(wù)的可用性?冗余服務(wù)。
- 如何保證數(shù)據(jù)的可用性?冗余數(shù)據(jù)。
數(shù)據(jù)的冗余，會帶來一個副作用：一致性問題。
1. 如何保證數(shù)據(jù)庫“讀”高可用?
冗余讀庫。
2. 冗余讀庫帶來什么副作用?
讀寫有延時，數(shù)據(jù)可能不一致。
上圖是很多互聯(lián)網(wǎng)公司mysql的架構(gòu)，寫仍然是單點(diǎn)，不能保證寫高可用。
3. 如何保證數(shù)據(jù)庫“寫”高可用?
冗余寫庫。
采用雙主互備的方式，可以冗余寫庫。
4. 冗余寫庫帶來什么副作用?
雙寫同步，數(shù)據(jù)可能沖突(例如“自增id”同步?jīng)_突)。
如何解決同步?jīng)_突，有兩種常見解決方案：
- 兩個寫庫使用不同的初始值，相同的步長來增加id：1寫庫的id為0,2,4,6...;2寫庫的id為1,3,5,7…;
- 不使用數(shù)據(jù)的id，業(yè)務(wù)層自己生成唯一的id，保證數(shù)據(jù)不沖突;
阿里云的RDS服務(wù)號稱寫高可用，是如何實現(xiàn)的呢?
他們采用的就是類似于“雙主同步”的方式(不再有從庫了)。
仍是雙主，但只有一個主提供讀寫服務(wù)，另一個主是“shadow-master”，只用來保證高可用，平時不提供服務(wù)。
master掛了，shadow-master頂上，虛IP漂移，對業(yè)務(wù)層透明，不需要人工介入。
這種方式的好處：
- 讀寫沒有延時，無一致性問題;
- 讀寫高可用;
不足是：
- 不能通過加從庫的方式擴(kuò)展讀性能;
- 資源利用率為50%，一臺冗余主沒有提供服務(wù);
畫外音：所以，高可用RDS還挺貴的。
三、如何擴(kuò)展讀性能?
提高讀性能的方式大致有三種，第一種是增加索引。
這種方式不展開，要提到的一點(diǎn)是，不同的庫可以建立不同的索引。
如上圖：
- 寫庫不建立索引;
- 線上讀庫建立線上訪問索引，例如uid;
- 線下讀庫建立線下訪問索引，例如time;
第二種擴(kuò)充讀性能的方式是，增加從庫。
這種方法大家用的比較多，存在兩個缺點(diǎn)：
- 從庫越多，同步越慢;
- 同步越慢，數(shù)據(jù)不一致窗口越大;
第三種增加系統(tǒng)讀性能的方式是，增加緩存。
常見的緩存架構(gòu)如下：
- 上游是業(yè)務(wù)應(yīng)用;
- 下游是主庫，從庫(讀寫分離)，緩存;
如果系統(tǒng)架構(gòu)實施了服務(wù)化：
- 上游是業(yè)務(wù)應(yīng)用;
- 中間是服務(wù);
- 下游是主庫，從庫，緩存;
業(yè)務(wù)層不直接面向db和cache，服務(wù)層屏蔽了底層db、cache的復(fù)雜性。
不管采用主從的方式擴(kuò)展讀性能，還是緩存的方式擴(kuò)展讀性能，數(shù)據(jù)都要復(fù)制多份(主+從，db+cache)，一定會引發(fā)一致性問題。
四、如何保證一致性?
主從數(shù)據(jù)庫的一致性，通常有兩種解決方案：
1. 中間件
如果某一個key有寫操作，在不一致時間窗口內(nèi)，中間件會將這個key的讀操作也路由到主庫上。
2. 強(qiáng)制讀主
“雙主高可用”的架構(gòu)，主從一致性的問題能夠大大緩解。
第二類不一致，是db與緩存間的不一致。
另外建議，所有允許cache miss的業(yè)務(wù)場景，緩存中的KEY都設(shè)置一個超時時間，這樣即使出現(xiàn)不一致，有機(jī)會得到自修復(fù)。
五、如何保障數(shù)據(jù)庫的擴(kuò)展性?
秒級成倍數(shù)據(jù)庫擴(kuò)容：《億級數(shù)據(jù)DB秒級平滑擴(kuò)容》
如果不是成倍擴(kuò)容：《100億數(shù)據(jù)平滑數(shù)據(jù)遷移,不影響服務(wù)》
也可能，是要對字段進(jìn)行擴(kuò)展：《1萬屬性，100億數(shù)據(jù)，架構(gòu)設(shè)計?》
這些方案，都有相關(guān)文章展開寫過，本文不再贅述。
數(shù)據(jù)庫軟件架構(gòu)，到底要設(shè)計些什么?
- 可用性
- 讀性能
- 一致性
- 擴(kuò)展性
希望對大家系統(tǒng)性理解數(shù)據(jù)庫軟件架構(gòu)有幫助。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
當(dāng)前名稱：數(shù)據(jù)庫軟件架構(gòu)，到底要設(shè)計些什么？
當(dāng)前網(wǎng)址：http://www.5511xx.com/article/dhehegg.html
