系統(tǒng)架構(gòu)設(shè)計之擴容

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

成都創(chuàng)新互聯(lián)是一家專注網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷策劃、微信小程序開發(fā)、電子商務(wù)建設(shè)、網(wǎng)絡(luò)推廣、移動互聯(lián)開發(fā)、研究、服務(wù)為一體的技術(shù)型公司。公司成立十載以來，已經(jīng)為近千家輕質(zhì)隔墻板各業(yè)的企業(yè)公司提供互聯(lián)網(wǎng)服務(wù)?，F(xiàn)在，服務(wù)的近千家客戶與我們一路同行，見證我們的成長；未來，我們一起分享成功的喜悅。

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

以后再考慮擴容？

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

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

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

雙寫移庫，其實是我認為一種比較low的懶惰的方法，是讓別人接坑的方法。說下特點：

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

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

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

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

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

??

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

? ?而如果存儲的用戶信息，是不能隨便增加節(jié)點和減少節(jié)點的，因為任何變動都會引起用戶信息的丟失，這種丟失不可逆，不能通過重新登錄解決。此時，對于你采取 一致性hash，取模，或者區(qū)間算法實際是相同的。

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

一致性hash

有些時候還是需要客戶端在代碼中進行hash，這時候選擇hash算法尤為重要。有些項目中，架構(gòu)師用了一致性hash算法做分庫分表，其實真的沒有考慮后期縮容和擴容的問題。

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

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

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

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

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

Redis集群架構(gòu)

某項目一致性hash的算法示意圖：

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

總之，當你選擇服務(wù)的時候，你會選擇一種在你擴容的時候?qū)€上有影響，還是一種靠線下努力，按照步驟對線上沒影響的擴容方案呢。

本文題目：系統(tǒng)架構(gòu)設(shè)計之擴容
URL網(wǎng)址：http://bm7419.com/article12/pcspdc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、標簽優(yōu)化、網(wǎng)頁設(shè)計公司、小程序開發(fā)、電子商務(wù)、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)