來自:大碼侯(微訊號:cool_wier)
上一篇關於DynamoDB的介紹中,有一個特別亮點,就是它無需停機就可以動態擴容。
這個對於我們常用的分庫分表方案來說,有很大的優勢,分庫分表的擴容是一件頭疼的問題,如果採用對db層做一致性hash,或是中間價的支援,它的成本過於高昂了,如果不如此,只能停機維護來處理,對高可用性會產生影響。
那是否有方案,既可以快速擴充套件,又不降低可用性?這一篇,我們聊聊分庫分表的擴充套件方案,供大家一起探討。
一、水平分庫擴充套件問題
為了增加db的併發能力,常見的方案就是對資料進行sharding,也就是常說的分庫分表,這個需要在初期對資料規劃有一個預期,從而預先分配出足夠的庫來處理。
比如目前規劃了3個資料庫,基於uid進行取餘分片,那麼每個庫上的劃分規則如下:
如上我們可以看到,資料可以均衡的分配到3個資料庫裡面。
但是,如果後續業務發展的速度很快,使用者量資料大量上升,當前容量不足以支撐,應該怎麼辦?
需要對資料庫進行水平擴容,再增加新庫來分解。新庫加入之後,原先sharding到3個庫的資料,就可以sharding到四個庫裡面了
不過此時由於分片規則進行了變化(uid%3 變為uid%4),大部分的資料,無法命中在原有的資料庫上了,需要重新分配,大量資料需要遷移。
比如之前uid1透過uid1%3 分配在A庫上,新加入庫D之後,演演算法改為uid1%4 了,此時有可能就分配在B庫上面了。
如果你有看到之前《一致性雜湊的原理與實踐》,就會發現新增一個節點,大概會有90%的資料需要遷移,這個對DB同學的壓力還是蠻大的,那麼如何應對?
一般有以下幾種方式。
二、停服遷移
停服遷移是最常見的一種方案了,一般如下流程:
預估停服時間,釋出停服公告
停服,透過事先做好的資料遷移工具,按照新的分片規則,進行遷移
修改分片規則
啟動服務
我們看到這種方式比較安全,停服之後沒有資料寫入,能夠保證遷移工作的正常進行,沒有一致性的問題。唯一的問題,就是停服了和時間壓力了。
停服,傷害使用者體驗,同時也降低了伺服器的可用性
必須在制定時間內完成遷移,如果失敗,需要擇日再次進行。同時增加了開發人員的壓力,容易發生大的事故
資料量的巨大的時候,遷移需要大量時間
那有沒有其他方式來改進一下,我們看下以下兩種方案。
三、升級從庫
線上資料庫,我們為了保持其高可用,一般都會每臺主庫配一臺從庫,讀寫在主庫,然後主從同步到從庫。如下,A,B是主庫,A0和B0是從庫。
此時,當需要擴容的時候,我們把A0和B0升級為新的主庫節點,如此由2個分庫變為4個分庫。同時在上層的分片配置,做好對映,規則如下:
uid%4=0和uid%4=2的分別指向A和A0,也就是之前指向uid%2=0的資料,分裂為uid%4=0和uid%4=2
uid%4=1和uid%4=3的指向B和B0,也就是之前指向uid%2=1的資料,分裂為uid%4=1和uid%4=3
因為A和A0庫的資料相同,B和B0資料相同,所以此時無需做資料遷移即可。只需要變更一下分片配置即可,透過配置中心更新,無需重啟。
由於之前uid%2的資料分配在2個庫裡面,此時分散到4個庫中,由於老資料還存在(uid%4=0,還有一半uid%4=2的資料),所以需要對冗餘資料做一次清理。
而這個清理,不會影響線上資料的一致性,可是隨時隨地進行。
處理完成以後,為保證高可用,以及下一步擴容需求。可以為現有的主庫再次分配一個從庫。
總結一下此方案步驟如下:
修改分片配置,做好新庫和老庫的對映。
同步配置,從庫升級為主庫
解除主從關係
冗餘資料清理
為新的資料節點搭建新的從庫
四、雙寫遷移
雙寫的方案,更多的是針對線上資料庫遷移來用的,當然了,對於分庫的擴充套件來說也是要遷移資料的,因此,也可以來協助分庫擴容的問題。
原理和上述相同,做分裂擴容,只是資料的同步方式不同了。
1.增加新庫寫連結
雙寫的核心原理,就是對需要擴容的資料庫上,增加新庫,並對現有的分片上增加寫連結,同時寫兩份資料。
因為新庫的資料為空,所以資料的CRUD對其沒有影響,在上層的邏輯層,還是以老庫的資料為主。
2.新老庫資料遷移
透過工具,把老庫的資料遷移到新庫裡面,此時可以選擇同步分裂後的資料(1/2)來同步,也可以全同步,一般建議全同步,最終做資料校檢的時候好處理。
3.資料校檢
按照理想環境情況下,資料遷移之後,因為是雙寫操作,所以兩邊的資料是一致的,特別是insert和update,一致性情況很高。但真實環境中會有網路延遲等情況,對於delete情況並不是很理想,比如:
A庫刪除資料a的時候,資料a正在遷移,還沒有寫入到C庫中,此時C庫的刪除操作已經執行了,C庫會多出一條資料。
此時就需要做好資料校檢了,資料校檢可以多做幾遍,直到資料幾乎一致,儘量以舊庫的資料為準。
4.分片配置修改
資料同步完畢,就可以把新庫的分片對映重新處理了,還是按照老庫分裂的方式來進行,
u之前uid%2=0,變為uid%4=0和uid%4=2的
uid%2=1,變為uid%4=1和uid%4=3的。
參考:
●本文編號272,以後想閱讀這篇文章直接輸入272即可
●輸入m獲取文章目錄
Linux學習
更多推薦《18個技術類微信公眾號》
涵蓋:程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。