系統(tǒng)架構(gòu)設(shè)計(jì)之?dāng)U容

能夠進(jìn)入互聯(lián)網(wǎng)相關(guān)公司做開(kāi)發(fā)工作的，或多或少都了解分布式擴(kuò)容等內(nèi)容，或者從書(shū)本上學(xué)到，或者從博客中找到。但到用的時(shí)候卻很少考慮以后怎么擴(kuò)容，怎么更方便的擴(kuò)展。本文結(jié)合我在實(shí)際工作中碰到的擴(kuò)容的情況進(jìn)行實(shí)例說(shuō)明。

說(shuō)個(gè)現(xiàn)實(shí)一點(diǎn)兒的現(xiàn)象，在新項(xiàng)目初期基本上不考慮以后怎么擴(kuò)容誰(shuí)去擴(kuò)容的問(wèn)題，某次其他組的一個(gè)同學(xué)問(wèn)我：愿哥，我們有個(gè)線上的業(yè)務(wù)需要擴(kuò)容，怎么辦？我問(wèn)他采用什么方式分片的，他告訴我hash取模。我頭暈，這。。。沒(méi)啥好辦法，只能停服。如果不能停服，只能用雙寫(xiě)移庫(kù)的方法。

以后再考慮擴(kuò)容？

這是典型的不負(fù)責(zé)任的表現(xiàn)，以我這幾年對(duì)項(xiàng)目的觀察看，一般擴(kuò)容發(fā)生在兩年后，而新項(xiàng)目如果還算成功的話，第一年基本上該拿的獎(jiǎng)基本上都拿了，該被肯定的也被肯定了。第三年的時(shí)候，主程還在不在還不好說(shuō)，大多數(shù)項(xiàng)目的初期開(kāi)發(fā)者都離職了。而沒(méi)有離職的都把項(xiàng)目轉(zhuǎn)手給其他人了，而其他人用1周解決，還是用兩個(gè)月解決不關(guān)最初設(shè)計(jì)者的事情了。當(dāng)然，如果是dau成直線上升的項(xiàng)目除外，這種項(xiàng)目最考驗(yàn)初期架構(gòu)師的能力，如果設(shè)計(jì)不好，真的會(huì)坑自己。

為什么后期后期難重構(gòu)？

業(yè)務(wù)是延續(xù)的，如果是一個(gè)重要的業(yè)務(wù)，肯定是不會(huì)停掉，給你留下慢慢的搞的時(shí)間，老板的期望是你能夠立即解決問(wèn)題。這時(shí)你說(shuō)，初期沒(méi)考慮擴(kuò)容。。。我剛來(lái)北京的時(shí)候，當(dāng)時(shí)做農(nóng)場(chǎng)項(xiàng)目的兩個(gè)公司就是，同樣的項(xiàng)目，同樣的DAU爆發(fā)式增長(zhǎng)。一個(gè)公司的項(xiàng)目因?yàn)殡y以擴(kuò)容，結(jié)果在一周之后所有用戶都走光了，而另外一個(gè)公司因?yàn)槌跗诩軜?gòu)方便擴(kuò)容，開(kāi)啟了輝煌的一章。

雙寫(xiě)移庫(kù)，其實(shí)是我認(rèn)為一種比較low的懶惰的方法，是讓別人接坑的方法。說(shuō)下特點(diǎn)：

1. 影響接口速度，雙寫(xiě)無(wú)疑會(huì)增加調(diào)用redis的次數(shù)，增大時(shí)間，提高錯(cuò)誤率。

2. 周期，從4個(gè)庫(kù)，移動(dòng)幾百G的數(shù)據(jù)，在線上 用多長(zhǎng)時(shí)間，開(kāi)著飛機(jī)換輪子是否會(huì)造成出現(xiàn)偏差。在之前給某業(yè)務(wù)導(dǎo)數(shù)據(jù)過(guò)程中，掛死過(guò)一個(gè)redis，導(dǎo)致線上的業(yè)務(wù)出現(xiàn)問(wèn)題。

那么程序設(shè)計(jì)之初就要有明確的目標(biāo)：

?1. DBA如果能在提供固定實(shí)例端口的基礎(chǔ)上，內(nèi)容消化擴(kuò)容，那么問(wèn)題就好辦了，也就沒(méi)有以下內(nèi)容。

我們?cè)?jīng)碰到過(guò)一種case，DBA提供了4個(gè)端口，然后通過(guò)內(nèi)部中間件實(shí)現(xiàn)，然而，大約兩年過(guò)后，中間件維護(hù)者離職了，此方法就再也沒(méi)有人維護(hù)了。然后3年后，DBA說(shuō)單臺(tái)機(jī)器空間打滿了，需要擴(kuò)容。此時(shí)接收的RD滿滿都是淚。

??

?2. 你存儲(chǔ)的信息是什么，根據(jù)不同的內(nèi)容其實(shí)是有不同的方案的，如果存共享session這類臨時(shí)數(shù)據(jù)，那么無(wú)疑一致性hash是最好的解決方案，運(yùn)維增加一臺(tái)機(jī)器或者減少一臺(tái)機(jī)器，頂多會(huì)造成，一部分用戶重新登錄下，不會(huì)造成其他問(wèn)題。

? ?而如果存儲(chǔ)的用戶信息，是不能隨便增加節(jié)點(diǎn)和減少節(jié)點(diǎn)的，因?yàn)槿魏巫儎?dòng)都會(huì)引起用戶信息的丟失，這種丟失不可逆，不能通過(guò)重新登錄解決。此時(shí)，對(duì)于你采取 一致性hash，取模，或者區(qū)間算法實(shí)際是相同的。

?3. 擴(kuò)容：擴(kuò)容的目標(biāo)應(yīng)該是，解決問(wèn)題而又線上業(yè)務(wù)沒(méi)有問(wèn)題，這個(gè)應(yīng)該最高優(yōu)先的目標(biāo)。也就是，優(yōu)化是程序架構(gòu)側(cè)的事不是產(chǎn)品層面的事，不應(yīng)引起系統(tǒng)服務(wù)的波動(dòng)。

一致性hash

有些時(shí)候還是需要客戶端在代碼中進(jìn)行hash，這時(shí)候選擇hash算法尤為重要。有些項(xiàng)目中，架構(gòu)師用了一致性hash算法做分庫(kù)分表，其實(shí)真的沒(méi)有考慮后期縮容和擴(kuò)容的問(wèn)題。

一致性hash算法主要解決的是從N到N-1的問(wèn)題。

結(jié)合redis的集群架構(gòu)槽指派思路，我在某個(gè)項(xiàng)目中使用了區(qū)間算法,理由如下：

1. 由一個(gè)簡(jiǎn)單的算法如md5 (uid) 取得最后兩位，哈希到00-FF共計(jì)256個(gè)節(jié)點(diǎn)，假設(shè)分配如下：00-3F? 40-7F 80-BF? C0-FF? 分別對(duì)應(yīng)4個(gè)redis實(shí)例A B C D。此時(shí)如果4個(gè)redis滿了，想盡快增加端口解決問(wèn)題?？梢?中的步驟。

2. 對(duì)于00-3F的數(shù)據(jù)，可以摘取一個(gè)從庫(kù)，單獨(dú)最為主庫(kù)。如A? A1， 此時(shí)A和A1中的數(shù)據(jù)是一樣的。然后修改配置 00-1F到A上面， 20-3F到A1上面，這樣就完成了擴(kuò)充端口。

然后再寫(xiě)一個(gè)腳本，線下刪除A里面根據(jù)算法落到20-3F的數(shù)據(jù)，A1里面根據(jù)算法落到A的數(shù)據(jù)。這樣，應(yīng)該會(huì)很快的刪除到制定大小，無(wú)疑刪除數(shù)據(jù)遠(yuǎn)大于移動(dòng)寫(xiě)入數(shù)據(jù)的速度。

Redis集群架構(gòu)

某項(xiàng)目一致性hash的算法示意圖：

區(qū)間算法示意圖：

總之，當(dāng)你選擇服務(wù)的時(shí)候，你會(huì)選擇一種在你擴(kuò)容的時(shí)候?qū)€上有影響，還是一種靠線下努力，按照步驟對(duì)線上沒(méi)影響的擴(kuò)容方案呢。