網站的伸縮性是指不需要改變網站的軟硬體設計，僅僅通過改變部署的伺服器數量就可以擴大或者縮小網站的服務處理能力。

大型網站：

• 大量使用者，大量訪問
• 功能龐雜，產品眾多
• 網站需要部署大量的伺服器

大型網站的漸進式演化過程

網站架構的伸縮性設計

1根據功能進行物理分離實現伸縮
單一伺服器處理所有服務
資料庫從應用伺服器分離
快取從應用伺服器分離
靜態資源從應用伺服器分離

• 縱向分離（分層後分離），如 網站具體產品、可複用業務服務、基礎技術服務、資料庫
• 橫向分離，將不同的業務模組分離部署

2單一功能通過叢集實現伸縮
叢集伸縮性可分為應用伺服器叢集伸縮性和資料伺服器叢集伸縮性
資料伺服器叢集伸縮性也可分為快取資料伺服器叢集和儲存資料伺服器叢集

應用伺服器叢集伸縮性設計

應用伺服器應該設計成無狀態的
負載均衡伺服器：HTTP請求分發裝置，可以感知和配置叢集的伺服器數量

1HTTP重定向負載均衡

一臺普通的應用伺服器，唯一的功能是根據使用者請求計算一臺真實的Web伺服器地址，寫入HTTP重定向響應中返回給使用者。
優點：簡單
缺點：
瀏覽器需要兩次請求才能完成一次訪問，效能較差
重定向伺服器自身的處理能力有可能成為瓶頸，叢集伸縮性規模有限
HTTP302響應碼重定向，有可能使搜尋引擎判斷為SEO作弊，降低搜尋排名

2DNS域名解析負載均衡

在DNS伺服器中配置多個A記錄。每次域名解析請求都會根據負載均衡演算法計算一個不同的IP地址返回。
優點：
將負載均衡的工作轉交給DNS，省掉了網站管理維護負載均衡伺服器的麻煩。
同時許多DNS還支援基於地理位置的域名解析，將域名解析成距離使用者最近的一個伺服器地址，加快使用者訪問速度，改善效能。
缺點：
DNS多級解析，每一級都可能快取A記錄，修改A記錄等待生效需要較長時間。
DNS負載均衡的控制權在域名服務商，網站無法對其做更多改善和更強大的管理。
大型網站總是部分使用DNS域名解析，利用它作為第一級負載均衡手段。

3反向代理負載均衡

反向代理伺服器處於Web伺服器前面，可同時提供負載均衡和快取資源的功能。
請求通過反向代理伺服器轉發，響應也通過反向代理伺服器返回。
Web伺服器不直接對外提供訪問，因此不需要使用外部IP地址，而反向代理伺服器則需要配置雙網絡卡和內部外部兩套IP地址。
優點：和反向代理伺服器功能整合在一起，部署簡單
缺點：反向代理伺服器是所有請求和響應的中轉站，其效能可能會成為瓶頸

4IP負載均衡

負載均衡伺服器在作業系統核心程序獲取網路資料包，將資料目的IP修改為一臺真實Web伺服器，而不需要通過使用者程序處理。
IP負載均衡在核心程序完成資料分發，比反向代理負載均衡（在應用程式中分發資料）有更好的處理效能。但是由於所有請求

5資料鏈路層負載均衡

在通訊協議的資料鏈路層修改mac地址進行負載均衡。
三角傳輸模式。
負載均衡資料分發過程中不修改IP地址，只修改mac地址，通過配置真實物理伺服器叢集所有及其虛擬IP和負載均衡伺服器IP地址一致，從而達到不修改資料包的源地址和目的地址就可以進行資料分發的目的。
響應直接返回給使用者瀏覽器，不需要通過負載均衡伺服器。
目前大型網站使用最廣的一種負載均衡手段。

負載均衡演算法：

• 輪詢
• 加權輪詢
• 隨機或者加權隨機
• 最少連線：記錄每個應用伺服器正在處理的連線數，將新的請求分發到最少連線的伺服器上。
• 源地址雜湊：根據請求來源的IP地址進行Hash計算，得到應用伺服器。會話黏滯。

分散式快取叢集的伸縮性設計

主要目標：使叢集中已經快取的資料儘可能還被訪問到。

Memcached分散式快取叢集的訪問模型

路由演算法負責根據應用程式輸入的key計算得到應該將資料寫入哪臺伺服器或者從那臺伺服器讀取。
簡單的Hash演算法在擴容時導致的快取不能命中問題
分散式快取的一致性Hash演算法：Hash環
使用虛擬節點的一致性Hash環
在實踐中，一臺物理伺服器虛擬為150個（經驗值）虛擬伺服器節點。

資料儲存伺服器叢集的伸縮性設計

和快取伺服器叢集的伸縮性設計不同，資料儲存伺服器叢集的伸縮性對資料的永續性和可用性提出了更高的要求。
快取的目的是加速資料讀取的速度並減輕資料儲存伺服器的負載壓力，因此部分快取資料的丟失不影響業務的正常處理，因為資料還可以從資料庫等儲存伺服器上獲取。
而資料儲存伺服器必須保證資料的可靠儲存，任何情況下都必須保證資料的可用性和正確性。

關係資料庫叢集的伸縮性設計

MySQL叢集伸縮性方案

• 資料庫主從讀寫分離：寫操作都在主伺服器上，由主伺服器將資料同步到叢集中其他從伺服器，資料讀操作及資料分析等離線操作在從伺服器上進行。
• 業務分割：不同業務資料表部署在不同的資料庫叢集
• 分片：單表資料很大的

支援資料分片的Cobar
Cobar部署模型（圖）
Cobar系統元件模型（圖）
Cobar叢集伸縮原理（圖）
實踐中，Cobar利用了MySQL的資料同步功能進行資料遷移。以Schema為單位。
無法執行誇庫的JOIN操作，更不能執行跨庫的事務處理。必須從業務上回避分散式關係資料庫的各種缺點：避免事務或利用事務補償機制代替資料庫事務；分解資料訪問邏輯避免JOIN操作等。

NoSQL資料庫的伸縮性設計

業務物件貧血模型與充血模型？
NoSQL，主要指非關係的、分散式的資料庫設計模式。
一般而言，NoSQL資料庫產品都放棄了關係資料庫的兩大重要基礎：以關係代數為基礎的結構化查詢語言（SQL）和事務一致性保證（ACID）。而強化其他一些大型網站更關注的特性：高可用性和可伸縮性。
HBase
HBase架構（圖）
HRegionSever是物理伺服器，每個HRegionSever上可以啟動多個HRegion例項。
HMaster伺服器

高手定律：這個世界只有遇不到的問題，沒有解決不了的問題。