要實(shí)現(xiàn)伸縮性架構(gòu)，最重要的是使用集群，只要能做到向集群中加入服務(wù)器的數(shù)量和集群處理能力成正比，網(wǎng)站就能夠無限增強(qiáng)處理能力。

一類是不同的服務(wù)器部署不同的服務(wù)實(shí)現(xiàn)伸縮性，這類問題通過縱向分離（分層后分離）和橫向分離（業(yè)務(wù)分割后分離）實(shí)現(xiàn)；

另一類是集群中多臺(tái)服務(wù)器部署相同的服務(wù)實(shí)現(xiàn)伸縮性，這類問題需要設(shè)計(jì)應(yīng)用服務(wù)器和數(shù)據(jù)服務(wù)器的伸縮性。

一、應(yīng)用服務(wù)器的伸縮性

應(yīng)用服務(wù)器伸縮性的核心是無狀態(tài)和負(fù)載均衡。

負(fù)載均衡服務(wù)器的分類：

a. Http重定向LB：需要兩次請(qǐng)求；

b. DNSLB：DNS有緩存可能導(dǎo)致訪問到下線的服務(wù)器；

c. 反向代理LB：成為所有請(qǐng)求和響應(yīng)的中轉(zhuǎn)站，壓力大；

d. IPLB：通過修改數(shù)據(jù)包的IP地址實(shí)現(xiàn)；

e. 鏈路層LB：修改數(shù)據(jù)的MAC地址；

常用的LB算法有：輪詢、加權(quán)輪詢、隨機(jī)、最少連接、源地址散列

二、緩存集群的伸縮性

1. Memcached模型

Memcached使用Key-Value形式存儲(chǔ)和訪問數(shù)據(jù)，在內(nèi)存中維護(hù)一張巨大的HashTable，使得對(duì)數(shù)據(jù)查詢的時(shí)間復(fù)雜度降低到O(1)，保證了對(duì)數(shù)據(jù)的高性能訪問。內(nèi)存的空間總是有限的，當(dāng)內(nèi)存沒有更多的空間來存儲(chǔ)新數(shù)據(jù)時(shí)，memcached就會(huì)利用LRU算法將不常使用的數(shù)據(jù)淘汰掉。

Memcached本身并不是分布式緩存系統(tǒng)，它的分布式是由訪問它的客戶端實(shí)現(xiàn)的。

常用的路由算法有：

a. 余數(shù)Hash：算法簡單，但一旦有服務(wù)器宕機(jī)或者要新增服務(wù)器就會(huì)導(dǎo)致緩存失效，引起雪崩。

b. 一致性Hash：服務(wù)器的增減不會(huì)引起雪崩效應(yīng)，但當(dāng)服務(wù)器節(jié)點(diǎn)較少時(shí)可能某臺(tái)服務(wù)器壓力過大。

c. 帶虛擬節(jié)點(diǎn)的一致性Hash：每臺(tái)服務(wù)器對(duì)應(yīng)多個(gè)虛擬節(jié)點(diǎn)，避免某臺(tái)服務(wù)器壓力過大，尋址的過程多了一步從虛擬節(jié)點(diǎn)到服務(wù)器的映射。

三、數(shù)據(jù)服務(wù)器的伸縮性

1. 關(guān)系數(shù)據(jù)庫集群的伸縮性

a. 讀寫分離：主server負(fù)責(zé)寫入，并同步到從server，從server負(fù)責(zé)讀取和數(shù)據(jù)分析。

要實(shí)現(xiàn)數(shù)據(jù)庫的復(fù)制，需要開啟Master服務(wù)器端的Binary log。數(shù)據(jù)復(fù)制的過程實(shí)際就是從slave從master獲取binary log，然后再在本地鏡像中執(zhí)行日志中的操作。由于復(fù)制是異步的，因此只能保證最終一致性。

b. 數(shù)據(jù)分庫

對(duì)ID按照表的數(shù)量取模，計(jì)算出數(shù)據(jù)存儲(chǔ)在哪個(gè)數(shù)據(jù)庫里。

c. 拆表

對(duì)ID按照表的數(shù)量取模，計(jì)算出數(shù)據(jù)存儲(chǔ)在哪張表里。

常見的有Corba

2. Nosql集群的伸縮性

HBase的伸縮性依賴其可分裂的HRegion和可伸縮的HDFS實(shí)現(xiàn)。

HBase使用ColumnFamily。Hbase表的創(chuàng)建的時(shí)候就必須指定列族。

Rowkey的概念和mysql中的主鍵是完全一樣的，Rawkey的設(shè)計(jì)。

TimeStamp對(duì)Hbase來說至關(guān)重要，因?yàn)樗菍?shí)現(xiàn)Hbase多版本的關(guān)鍵。在Hbase中使用不同的timestame來標(biāo)識(shí)相同rowkey行對(duì)應(yīng)的不同版本的數(shù)據(jù)。

主要組建包括ZooKeeper、HMaster、HRegionServer、HRegion。

ZooKeeper的主要作用：

a. 分布式鎖：選舉記錄主HMaster；

b. 集群管理：監(jiān)控HRegionServer的狀態(tài)，在HRegionServer故障時(shí)通知HMaster重新分配HRegion；

c. 通過Zoopkeeper存儲(chǔ)元數(shù)據(jù)的統(tǒng)一入口地址。

HRegionServer：分布多個(gè)HRegion。

HMaster的主要作用：

a. 為RegionServer分配Region，當(dāng)收到ZooKeeper的HRegionServer失效的通知時(shí)為HRegion重新分配HRegionServer；

b. 維護(hù)HRegionServer集群的負(fù)載均衡；

c. 當(dāng)RegionSever失效的時(shí)候，協(xié)調(diào)對(duì)應(yīng)Hlog的拆分。

HRegionServer的主要作用：

a. 處理來自客戶端的讀寫請(qǐng)求；

b. 負(fù)責(zé)和底層HDFS的交互，存儲(chǔ)數(shù)據(jù)到HDFS；

c. 負(fù)責(zé)Region變大以后的拆分；

d. 負(fù)責(zé)Storefile的合并工作。

尋址

第1步：Client請(qǐng)求ZK獲取.META.所在的RegionServer的地址。

第2步：Client請(qǐng)求.META.所在的RegionServer獲取訪問數(shù)據(jù)所在的RegionServer地址，client會(huì)將.META.的相關(guān)信息cache下來，以便下一次快速訪問。

第3步：Client請(qǐng)求數(shù)據(jù)所在的RegionServer，獲取所需要的數(shù)據(jù)。

寫操作

上圖可以看出氛圍3步驟：

Hbase的寫入流程如下圖所示：

第1步：Client獲取數(shù)據(jù)寫入的Region所在的RegionServer

第2步：請(qǐng)求寫Hlog

第3步：請(qǐng)求寫MemStore

只有當(dāng)寫Hlog和寫MemStore都成功了才算請(qǐng)求寫入完成。MemStore后續(xù)會(huì)逐漸刷到HDFS中。

HBase的伸縮性：

當(dāng)表的數(shù)據(jù)量越來越大，Region越來越多的時(shí)候，只需要添加RegionServer，此時(shí)RegionServer向ZooKeeper寫入節(jié)點(diǎn)，ZooKeeper通知HMaster為其分配HRegion。

HBase的可用性：

當(dāng)某個(gè)HRegionServer異常時(shí)，ZooKeeper會(huì)監(jiān)測到并通知HMaster，HMaster會(huì)將故障的RegionServer的Region重新分配給其他RegionServer，并通過Hlog將RegionServer的操作還原到新的RegionServer上。

HBase的高性能：

隨著數(shù)據(jù)量增大，Region會(huì)越來越大，當(dāng)Region的大小超過設(shè)定的閾值時(shí)會(huì)分裂，分裂后的Region可能位于同一個(gè)RegionServer，也可能位于不同的RegionServer。這就保證了Region不會(huì)太大以至于影響讀寫性能。