6 永無止境：網站的伸縮性架構
6.1 網站架構的伸縮性設計
一般說來，網站的伸縮性設計可分爲兩類，一類是根據功能進行物理分離實現伸縮；一類是單一功能通過集羣實現伸縮。前者是不同的服務器部署不同的服務，提供不同的功能；後者是集羣內的多臺服務器部署相同的服務，提供相同的功能。
6.1.1 不同功能進行物理分離實現伸縮
每次分離都會有更多的服務器加入網站，使用新增的服務器處理某種特定的服務。具體可分爲如下兩種情況：
縱向分離（分層後分離）：將業務處理流程上的不同部分分離部署，實現系統的伸縮性。
橫向分離（業務分割後分離）：將不同的業務模塊分離部署，實現系統伸縮性。
6.1.2 單一功能通過集羣規模實現伸縮
“當一頭牛拉不動車的時候，不要去尋找一頭更強壯的牛，而是用兩頭牛來拉車。”
6.2 應用服務器集羣的伸縮性設計
負載均衡服務器：請求分發裝置
實現負載均衡的基礎技術不外以下幾種：
6.2.1 HTTP重定向負載均衡
根據用戶的HTTP請求計算一臺真實的Web服務器地址，並將該Web服務器地址下乳HTTP重定向響應中（響應狀態碼302）返回給用戶瀏覽器。
缺點是：瀏覽器需要兩次請求服務器才能完成一次訪問，性能較差；重定向服務器自身處理能力有可能成爲瓶頸，整個集羣的伸縮性規模有限；有可能使搜索引擎判斷爲SEO作弊。
6.2.2 DNS域名解析負載均衡
DNS域名解析負載均衡的優點是將負載均衡的工作轉交給DNS，省掉了網站管理維護負載均衡服務器的麻煩。
缺點是：DNS更新需要一定的時間；DNS負載均衡的控制權在域名服務商那裏，網站無法對其做更多改善和更強大的管理。
大型網站總是部分使用DNS域名解析，利用域名解析作爲第一級負載均衡手段，即域名解析得到的一組服務器並不是實際提供Web服務的物理服務器，而是同樣提供負載均衡服務的內部服務器，這組內部負載均衡服務器再進行負載均衡，將請求分發到真實的Web服務器上。
6.2.3 反向代理負載均衡
大多數反向代理服務器同時提供負載均衡的功能，管理一組Web服務器，將請求根據負載均衡算法轉發到不同Web服務器上。
由於反向代理服務器轉發請求在HTTP協議層面，因此也叫應用層負載均衡。優點是和反向代理服務器功能集成在一起，部署簡單。缺點是反向代理服務器是所有請求和響應的中轉站，其性能可能會成爲瓶頸。
6.2.4 IP負載均衡
在網絡層通過修改請求目標地址進行負載均衡。
6.2.5 數據鏈路層負載均衡
在Linux平臺上最好的二鏈路層負載均衡的開源產品是LVS（Linux Virtual Server）。
6.2.6 負載均衡算法
負載均衡服務器的實現可分爲以下兩部分：
- 根據負載均衡算法和Web服務器列表計算得到集羣中一臺Web服務器的地址
- 將請求數據發送到該地址對應的Web服務器上
具體的負載均衡算法通常有以下幾種：
- 輪詢：所有請求被依次發到每臺應用服務器上
- 加權輪詢：根據應用服務器硬件性能的情況，在輪詢的基礎上，按照配置的權重將請求發到每個服務器，高性能的服務器能分配到更多的請求
- 隨機
- 最少連接：記錄每個應用服務器正在處理的連接數（請求數），將新到的請求分發到最少連接的服務器上
- 源地址散列：根據請求來源IP地址進行Hash計算，得到應用服務器，這樣來自同一個IP地址的請求總是在同一個服務器上處理，該請求的上下文信息可以存儲在這臺服務器上，在一個會話週期內重複使用，從而實現會話粘滯
6.3 分佈式緩存集羣的伸縮性設計
和所有服務器都部署相同應用的應用服務器集羣不同，分佈式緩存服務器集羣中不同服務器中緩存的數據各不相同，緩存訪問請求不可以在緩存服務器集羣中的任意一臺處理，必須先找到緩存有需要數據的服務器，然後才能訪問。這個特點會嚴重製約分佈式緩存集羣的伸縮性設計，因爲新上線的緩存服務器沒有緩存任何數據，而已下線的緩存服務器還緩存着網站的許多熱點數據。
分佈式緩存集羣伸縮性設計的最主要目標：必須讓新上線的緩存服務器對整個分佈式緩存集羣影響最小，也就是說新加入緩存服務器後應使整個緩存服務器集羣中已經緩存的數據儘可能還可被訪問到。
6.3.1 Memcached分佈式緩存集羣的訪問模型
應用程序通過Memcached客戶端訪問Memcached服務器集羣，Memcached客戶端主要由一組API、Memcached服務器集羣理由算法、Memcached服務器集羣列表及通信模塊組成。
6.3.2 Memcached分佈式緩存集羣的伸縮性挑戰
由上節可知，在Memcached分佈式緩存系統中，對於服務器集羣的管理，路由算法至關重要，和負載均衡算法一樣，決定着究竟該訪問集羣中的哪臺服務器。
6.3.3 分佈式緩存的一致性Hash算法
目的：使得新加入的服務器不影響大部分緩存數據的正確命中——>一致性Hash算法。
一致性Hash算法通過一個叫做一致性Hash環的數據結構實現KEY到緩存服務器的映射。
6.4 數據存儲服務器集羣的伸縮性設計
6.4.1 關係數據庫集羣的伸縮性設計
- 數據庫主從讀寫分離
- 數據分庫：不同業務數據表部署在不同的數據庫集羣上（限制是：跨庫的表不能進行Join操作）
- 數據表拆分
目前網站在線業務應用中比較成熟的支持數據分片的分佈是關係數據庫產品主要由開源的Ameoba和Cobar。
Cobar是一個分佈式關係數據庫訪問代理，介於應用服務器和數據庫服務器之間。
Cobar的伸縮有兩種：Cobar服務器集羣的伸縮和MySQL服務器集羣的伸縮。
6.4.2 NoSQL數據庫的伸縮性設計
以HBase爲例：其主要依賴其可分裂的HRegion及可伸縮的分佈式文件系統HDFS來實現伸縮性。