系統架構設計之擴容

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

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

以后再考慮擴容？

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

為什么后期后期難重構？

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

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

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

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

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

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

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

??

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

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

?3. 擴容：擴容的目標應該是，解決問題而又線上業務沒有問題，這個應該最高優先的目標。也就是，優化是程序架構側的事不是產品層面的事，不應引起系統服務的波動。

一致性hash

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

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

結合redis的集群架構槽指派思路，我在某個項目中使用了區間算法,理由如下：

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

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

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

Redis集群架構

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

區間算法示意圖：

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