一、網(wǎng)站架構(gòu)的伸縮性設(shè)計(jì)

1.1 不同功能進(jìn)行物理分離實(shí)現(xiàn)伸縮

　?。?）縱向分離：將業(yè)務(wù)處理流程上得不同部分分離部署，實(shí)現(xiàn)系統(tǒng)的伸縮性；

　　（2）橫向分離：將不同的業(yè)務(wù)模塊分離部署，實(shí)現(xiàn)系統(tǒng)的伸縮性；

1.2 單一功通過(guò)集群規(guī)模實(shí)現(xiàn)伸縮

　　使用服務(wù)器集群，即將相同服務(wù)部署在多臺(tái)服務(wù)器上構(gòu)成一個(gè)集群整體對(duì)外提供服務(wù)。具體來(lái)說(shuō)，集群伸縮性又分為應(yīng)用服務(wù)器集群伸縮性和數(shù)據(jù)服務(wù)器集群伸縮性。這兩種集群對(duì)于數(shù)據(jù)狀態(tài)管理的不同，技術(shù)實(shí)現(xiàn)也有很大的區(qū)別。

It is said that?當(dāng)一頭牛拉不動(dòng)車的時(shí)候，不要去尋找一頭更強(qiáng)壯的牛，而是用兩頭牛來(lái)拉車。

二、應(yīng)用服務(wù)器集群的伸縮性設(shè)計(jì)

2.1 應(yīng)用服務(wù)器那點(diǎn)必須知道的事兒

（1）應(yīng)用服務(wù)器應(yīng)該被設(shè)計(jì)成無(wú)狀態(tài)的，即應(yīng)用服務(wù)器不存儲(chǔ)請(qǐng)求上下文信息；構(gòu)建集群后，每次用戶的請(qǐng)求都可以發(fā)到集群中任意一臺(tái)服務(wù)器上處理，任何一臺(tái)服務(wù)器的處理結(jié)果都是相同的；

　?。?）HTTP本身是一個(gè)無(wú)狀態(tài)的連接協(xié)議，為了支持客戶端與服務(wù)器之間的交互，我們就需要通過(guò)不同的技術(shù)為交互存儲(chǔ)狀態(tài)，而這些不同的技術(shù)就是Cookie和Session了。

（3）HTTP請(qǐng)求的分發(fā)是應(yīng)用服務(wù)器集群實(shí)現(xiàn)伸縮性的核心問(wèn)題，而負(fù)載均衡服務(wù)器就是HTTP請(qǐng)求的分發(fā)裝置，它是網(wǎng)站必不可少的基礎(chǔ)手段，也被稱為網(wǎng)站的殺手锏之一。

2.2 負(fù)載均衡技術(shù)—網(wǎng)站必不可少的基礎(chǔ)技術(shù)手段

　　負(fù)載均衡的實(shí)現(xiàn)方式多種多樣，從硬件到軟件，從商業(yè)產(chǎn)品到開(kāi)源產(chǎn)品，應(yīng)有盡有。但是，實(shí)現(xiàn)負(fù)載均衡的基礎(chǔ)技術(shù)不外乎以下幾種：

（1）HTTP重定向負(fù)載均衡評(píng)價(jià)：★★

此方案的優(yōu)點(diǎn)是簡(jiǎn)單易行，缺點(diǎn)是：

①瀏覽器需要兩次請(qǐng)求才能完成一次訪問(wèn)，性能較差；

②重定向服務(wù)器自身的處理能力有可能成為瓶頸，整個(gè)集群的伸縮性規(guī)模有限；

③使用HTTP 302重定向有可能使搜索引擎判斷為SEO作弊，降低搜索排名；

（2）DNS域名解析負(fù)載均衡評(píng)價(jià)：★★★

　　此方案要求在DNS服務(wù)器中配置多個(gè)A記錄，例如：

www.mysite.com IN A114.100.80.1

www.mysite.com IN A114.100.80.2

www.mysite.com IN A114.100.80.3

　　此方案的優(yōu)點(diǎn)是將負(fù)載均衡的工作轉(zhuǎn)交給了DNS，省掉了網(wǎng)站管理維護(hù)負(fù)載均衡服務(wù)器的麻煩。而缺點(diǎn)是：

①目前的DNS是多級(jí)解析，每一級(jí)DNS都可能緩存A記錄，當(dāng)某臺(tái)服務(wù)器下線后，即使修改了DNS的A記錄，要使其生效仍然需要較長(zhǎng)時(shí)間。這段期間，會(huì)導(dǎo)致用戶訪問(wèn)已經(jīng)下線的服務(wù)器造成訪問(wèn)失敗。

　?、贒NS負(fù)載均衡的控制權(quán)在域名服務(wù)商那里，網(wǎng)站無(wú)法對(duì)其做更多改善和管理；

TIPS：事實(shí)上，大型網(wǎng)站總是部分使用DNS域名解析，利用域名解析作為第一級(jí)負(fù)載均很手段，即域名解析得到的一組服務(wù)器不是實(shí)際的Web服務(wù)器，而是同樣提供負(fù)載均衡的內(nèi)部服務(wù)器，這組內(nèi)部服務(wù)器再進(jìn)行負(fù)載均衡，請(qǐng)求分發(fā)到真實(shí)的Web服務(wù)器上。

（3）反向代理負(fù)載均衡評(píng)價(jià)：★★★★

　　Web服務(wù)器不需要使用外部IP地址，而反向代理服務(wù)器則需要配置雙網(wǎng)卡和內(nèi)外部?jī)商譏P地址。

此方案的優(yōu)點(diǎn)是和反向代理服務(wù)器功能集成在一起，部署簡(jiǎn)單。缺點(diǎn)是反向代理服務(wù)器是所有請(qǐng)求和響應(yīng)的中轉(zhuǎn)站，其性能可能會(huì)成為瓶頸。

（4）IP負(fù)載均衡評(píng)價(jià)：★★★★

此方案優(yōu)點(diǎn)在于在內(nèi)核進(jìn)程完成數(shù)據(jù)分發(fā)，較反向代理負(fù)載均衡（在應(yīng)用程序中分發(fā)數(shù)據(jù)）有更好的處理性能。缺點(diǎn)是由于所有請(qǐng)求響應(yīng)都需要經(jīng)過(guò)負(fù)載均衡服務(wù)器，集群的最大響應(yīng)數(shù)據(jù)吞吐量不得不受制于負(fù)載均衡服務(wù)器網(wǎng)卡帶寬。

（5）數(shù)據(jù)鏈路層負(fù)載均衡評(píng)價(jià)：★★★★★

此種方式又稱作三角傳輸模式，負(fù)載均衡數(shù)據(jù)分發(fā)過(guò)程中不修改IP地址，只修改mac地址，由于實(shí)際處理請(qǐng)求的真實(shí)物理IP地址和數(shù)據(jù)請(qǐng)求目的IP地址一致，所以不需要通過(guò)負(fù)載均衡服務(wù)器進(jìn)行地址轉(zhuǎn)換，可將響應(yīng)數(shù)據(jù)包直接返回給用戶瀏覽器，避免負(fù)載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸。這種負(fù)載均衡方式又稱作直接路由方式（DR）。

使用三角傳輸模式的鏈路層負(fù)載均衡是目前大型網(wǎng)站使用最廣泛的一種負(fù)載均衡手段。在Linux平臺(tái)上最好的鏈路層負(fù)載均衡開(kāi)源產(chǎn)品是LVS（Linux Virutal Server）。

2.3 負(fù)載均衡算法—負(fù)載均衡技術(shù)賴以生存的核心

　　前面的方法解決了負(fù)載均衡通過(guò)何種方式實(shí)現(xiàn)，而更為重要的則是如何從Web服務(wù)器列表中計(jì)算得到一臺(tái)Web服務(wù)器的地址，而這正是負(fù)載均衡的核心—算法。這里簡(jiǎn)單介紹一下通常的集中負(fù)載均衡計(jì)算的算法，如果需要深入了解請(qǐng)自行百度。

　?。?）輪詢

　　所有請(qǐng)求被以此分發(fā)到每臺(tái)應(yīng)用服務(wù)器上，即每臺(tái)服務(wù)器需要處理的請(qǐng)求數(shù)目都相同，適合于所有服務(wù)器硬件都相同的場(chǎng)景。

　　（2）加權(quán)輪詢

　　根據(jù)應(yīng)用服務(wù)器的配置性能的情況，在輪詢的基礎(chǔ)上，按照配置的權(quán)重將請(qǐng)求分發(fā)到每個(gè)服務(wù)器，高性能的服務(wù)器能分配更多的請(qǐng)求。

　?。?）隨機(jī)

　　此算法比較簡(jiǎn)單實(shí)用，請(qǐng)求被隨機(jī)分配到各個(gè)應(yīng)用服務(wù)器，因?yàn)楹玫碾S機(jī)數(shù)本身就很均衡。

　?。?）最少連接

　　記錄每個(gè)應(yīng)用服務(wù)器正在處理的連接數(shù)（請(qǐng)求數(shù)），將新到的請(qǐng)求分發(fā)到最少連接的服務(wù)器上，應(yīng)該說(shuō)，這是最符合負(fù)載均衡定義的算法。

（5）源地址散列

根據(jù)請(qǐng)求來(lái)源的IP地址進(jìn)行Hash計(jì)算得到應(yīng)用服務(wù)器，這樣來(lái)自同一個(gè)IP地址的請(qǐng)求總在同一個(gè)服務(wù)器上處理，該請(qǐng)求的上下文信息可以存儲(chǔ)在這臺(tái)服務(wù)器上，在一個(gè)會(huì)話周期內(nèi)重復(fù)使用，從而實(shí)現(xiàn)會(huì)話粘滯。

三、分布式緩存集群的伸縮性設(shè)計(jì)

不同于應(yīng)用服務(wù)器集群的伸縮性設(shè)計(jì)，分布式緩存集群的伸縮性不能使用簡(jiǎn)單的負(fù)載均衡手段來(lái)實(shí)現(xiàn)。因?yàn)椋?b>分布式緩存服務(wù)器集群中緩存的數(shù)據(jù)各不相同，緩存訪問(wèn)請(qǐng)求不可以在緩存服務(wù)器集群中的任意一臺(tái)處理，必須先找到緩存有需要的數(shù)據(jù)的服務(wù)器，然后才能訪問(wèn)。

分布式緩存集群伸縮性設(shè)計(jì)的目標(biāo)：讓新上線的緩存服務(wù)器對(duì)整個(gè)分布式緩存集群影響最小，也就是說(shuō)新加入緩存服務(wù)器后應(yīng)使整個(gè)緩存服務(wù)器集群中已經(jīng)緩存的數(shù)據(jù)盡可能還被訪問(wèn)到。

　　（1）以Memcached為代表的分布式緩存集群的訪問(wèn)模型

　　以上圖片展示了一個(gè)典型的緩存寫(xiě)操作，應(yīng)用程序需要寫(xiě)緩存數(shù)據(jù)<'CHENGDU',DATA>，API將KEY（'CHENGDU'）輸入路由算法模塊，路由算法根據(jù)KEY和Memcached服務(wù)器集群列表計(jì)算得到一臺(tái)服務(wù)器編號(hào)（如Node1），進(jìn)而得到該機(jī)器的IP地址和端口（10.0.0.1:91000）。然后，API調(diào)用通信模塊和編號(hào)為Node1的Memcached服務(wù)器進(jìn)行通信，將數(shù)據(jù)<'CHENGDU',DATA>寫(xiě)入該服務(wù)器，至此便完成了一次分布式緩存的寫(xiě)操作。

　　而讀操作和寫(xiě)操作一樣，使用同樣的路由算法和服務(wù)器列表，只要提供相同的KEY（如上面提到的'CHENGDU'），Memcached客戶端總是訪問(wèn)相通的服務(wù)器（如上面計(jì)算得到的Node1）去讀取數(shù)據(jù)。

　?。?）以Memcached為代表的分布式緩存集群的伸縮性挑戰(zhàn)

簡(jiǎn)單的路由算法（通過(guò)使用余數(shù)Hash）無(wú)法滿足業(yè)務(wù)發(fā)展時(shí)服務(wù)器擴(kuò)容的需要：緩存命中率下降。例如：當(dāng)3臺(tái)服務(wù)器擴(kuò)容至4臺(tái)時(shí)，采用普通的余數(shù)Hash算法會(huì)導(dǎo)致大約75%（3/4）被緩存了的數(shù)據(jù)無(wú)法正確命中，隨著服務(wù)器集群規(guī)模的增大，這個(gè)比例會(huì)線性地上升。那么，可以想象，當(dāng)100臺(tái)服務(wù)器的急群眾加入一臺(tái)服務(wù)器，不能命中的概率大概是99%（N/N+1），這個(gè)結(jié)果顯然是無(wú)法接受的。

　　那么，能否通過(guò)改進(jìn)路由算法，使得新加入的服務(wù)器不影響大部分緩存數(shù)據(jù)的正確性呢？請(qǐng)看下面的一致性Hash算法。

（3）分布式緩存的一致性Hash算法

說(shuō)明：一致性Hash算法是分布式緩存的核心理論，這里只是簡(jiǎn)單介紹一下，后續(xù)有空我會(huì)單獨(dú)寫(xiě)一篇文章來(lái)詳細(xì)介紹一致性Hash算法，以及用C#實(shí)現(xiàn)一致性Hash算法。

　　一致性Hash算法通過(guò)一個(gè)叫做一致性Hash還的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)KEY到緩存服務(wù)器的Hash映射，如下圖所示：

　　具體算法過(guò)程是：

　?、傧葮?gòu)造一個(gè)長(zhǎng)度為0~2^32（2的32次冪）個(gè)的整數(shù)環(huán)（又稱：一致性Hash環(huán)），根據(jù)節(jié)點(diǎn)名稱的Hash值將緩存服務(wù)器節(jié)點(diǎn)防置在這個(gè)Hash環(huán)中，如上圖中的node1，node2等；

　　②根據(jù)需要緩存的數(shù)據(jù)的KEY值計(jì)算得到其Hash值，如上圖中右半部分的“鍵”，計(jì)算其Hash值后離node2很近；

　?、墼贖ash環(huán)上順時(shí)針查找距離這個(gè)KEY的Hash值最近的緩存服務(wù)器節(jié)點(diǎn)，完成KEY到服務(wù)器的Hash映射查找，如上圖中離右邊這個(gè)鍵的Hash值最近的順時(shí)針?lè)较虻姆?wù)器節(jié)點(diǎn)是node2，因此這個(gè)KEY會(huì)到node2中讀取數(shù)據(jù)；

當(dāng)緩存服務(wù)器集群需要擴(kuò)容的時(shí)候，只需要將新加入的節(jié)點(diǎn)名稱（如node5）的Hash值放入一致性Hash環(huán)中，由于KEY總是順時(shí)針查找距離其最近的節(jié)點(diǎn)，因此新加入的節(jié)點(diǎn)只影響整個(gè)環(huán)中的一部分。如下圖中所示，添加node5后，只影響右邊逆時(shí)針?lè)较虻娜齻€(gè)Key/Value對(duì)數(shù)據(jù)，只占整個(gè)Hash環(huán)中的一小部分。

因此，我們可以與之前的普通余數(shù)Hash作對(duì)比：采用一直性Hash算法時(shí)，當(dāng)3臺(tái)服務(wù)器擴(kuò)容到4臺(tái)時(shí)，可以繼續(xù)命中原有緩存數(shù)據(jù)的概率為75%，遠(yuǎn)高于普通余數(shù)Hash的25%，而且隨著集群規(guī)模越大，繼續(xù)命中原有緩存數(shù)據(jù)的概率也會(huì)隨之增大。當(dāng)100臺(tái)服務(wù)器增加1臺(tái)時(shí)，繼續(xù)命中的概率是99%。雖然，仍有小部分?jǐn)?shù)據(jù)緩存在服務(wù)器中無(wú)法被讀取到，但是這個(gè)比例足夠小，通過(guò)訪問(wèn)數(shù)據(jù)庫(kù)也不會(huì)對(duì)數(shù)據(jù)庫(kù)造成致命的負(fù)載壓力。

四、數(shù)據(jù)存儲(chǔ)服務(wù)器集群的伸縮性設(shè)計(jì)

首先，數(shù)據(jù)存儲(chǔ)服務(wù)器必須保證數(shù)據(jù)的可靠存儲(chǔ)，任何情況下都必須保證數(shù)據(jù)的可用性和正確性。因此，緩存服務(wù)器集群的伸縮性架構(gòu)方案不能直接適用于數(shù)據(jù)庫(kù)等存儲(chǔ)服務(wù)器。

　　（1）關(guān)系數(shù)據(jù)庫(kù)集群的伸縮性設(shè)計(jì)

　?、偈袌?chǎng)上主要的關(guān)系數(shù)據(jù)庫(kù)都支持?jǐn)?shù)據(jù)復(fù)制功能，使用這個(gè)功能可以對(duì)數(shù)據(jù)庫(kù)進(jìn)行簡(jiǎn)單伸縮。下圖顯示了使用數(shù)據(jù)復(fù)制的MySQL集群伸縮性方案：多臺(tái)MySQL的角色有主從之分，寫(xiě)操作都在主服務(wù)器上，由主服務(wù)器將數(shù)據(jù)同步到集群中其他從服務(wù)器。而讀操作及數(shù)據(jù)分析等離線操作都會(huì)在從服務(wù)器上完成。

②前面提到的業(yè)務(wù)分割模式也可以用在數(shù)據(jù)庫(kù)，不同業(yè)務(wù)數(shù)據(jù)表部署在不同的數(shù)據(jù)庫(kù)集群上，這就是所謂的“數(shù)據(jù)分庫(kù)”；但是其有一個(gè)制約條件：跨庫(kù)的表無(wú)法進(jìn)行Join操作；

③在實(shí)際運(yùn)維中，對(duì)一些單表數(shù)據(jù)仍然很大的表，例如Facebook的用戶數(shù)據(jù)庫(kù)、淘寶的商品數(shù)據(jù)庫(kù)等，還需要進(jìn)行分片，將一張表拆分開(kāi)分別存儲(chǔ)在多個(gè)數(shù)據(jù)庫(kù)中，這就是所謂的“數(shù)據(jù)分片”；

　?。?）NoSQL數(shù)據(jù)庫(kù)的伸縮性設(shè)計(jì)

首先，NoSQL主要指非關(guān)系的、分布式的數(shù)據(jù)庫(kù)設(shè)計(jì)模式。也有許多專家將NoSQL解讀為Not Only SQL，表示NoSQL是關(guān)系數(shù)據(jù)庫(kù)的補(bǔ)充，而不是替代方案。一般而言，NoSQL數(shù)據(jù)庫(kù)產(chǎn)品都放棄了關(guān)系數(shù)據(jù)庫(kù)的兩大重要基礎(chǔ)：①以關(guān)系代數(shù)為基礎(chǔ)的結(jié)構(gòu)化查詢語(yǔ)言（SQL）②事務(wù)的一致性保證（ACID）；與之對(duì)應(yīng)的是強(qiáng)化一些大型網(wǎng)站更關(guān)注的特性：高可用性和可伸縮性；

開(kāi)源社區(qū)的NoSQL產(chǎn)品不盡其數(shù)，其支持的數(shù)據(jù)結(jié)構(gòu)和伸縮性特性也各不相同。目前看來(lái)，應(yīng)用最廣泛的是Apache HBase。HBase的伸縮性主要依賴于其可分裂的HRegion及可伸縮的分布式文件系統(tǒng)HDFS（如果您不知道HDFS又對(duì)HDFS有興趣，可以閱讀我的另一篇博文《不怕故障的海量存儲(chǔ)—HDFS基礎(chǔ)入門》）實(shí)現(xiàn)。

　　上圖是HBase的整體架構(gòu)圖：

①HBase中數(shù)據(jù)以HRegion為單位進(jìn)行管理，也就是說(shuō)應(yīng)用程序如果想要訪問(wèn)一個(gè)數(shù)據(jù)，必須先找到HRegion，然后將數(shù)據(jù)讀寫(xiě)操作提交給HRegion，由HRegion完成存儲(chǔ)層面的數(shù)據(jù)操作。

②每個(gè)HRegion中存儲(chǔ)一段Key區(qū)間（例如：[Key1,Key2)）的數(shù)據(jù)，HRegionServer是物理服務(wù)器，每個(gè)HRegionServer上可以啟動(dòng)多個(gè)HRegion實(shí)例。當(dāng)一個(gè)HRegion中寫(xiě)入的數(shù)據(jù)太多，達(dá)到配置的閥值時(shí)，HRegion會(huì)分裂成兩個(gè)HRegion，并將HRegion在整個(gè)集群中進(jìn)行遷移，以使HRegionServer的負(fù)載均衡。

③所有的HRegion的信息都（例如：存儲(chǔ)的Key值區(qū)間、所在HRegionServer的IP地址和端口號(hào)等）記錄在HMaster服務(wù)器上。同時(shí)為了保證高可用，HBase啟動(dòng)了多個(gè)HMaster，并通過(guò)ZooKeeper（一個(gè)支持分布式一致性的數(shù)據(jù)管理服務(wù)）選舉出一個(gè)主服務(wù)器，通過(guò)這個(gè)主HMaster服務(wù)器獲得Key值所在的HRegionServer，最后請(qǐng)求該HRegionServer上的HRegion實(shí)例，獲得需要的數(shù)據(jù)。其具體的數(shù)據(jù)尋址訪問(wèn)流程如下圖所示：

五、學(xué)習(xí)小結(jié)

　　在本章的學(xué)習(xí)中，我們了解到要實(shí)現(xiàn)網(wǎng)站的可伸縮性，關(guān)鍵技術(shù)就在于如何構(gòu)建“良好”的服務(wù)器集群。要達(dá)到良好的目標(biāo)，就要求每次擴(kuò)容和減少服務(wù)器時(shí)，對(duì)整個(gè)網(wǎng)站的影響是最小的，甚至無(wú)影響的。伸縮性是復(fù)雜的，沒(méi)有通用的、完美的解決方案和產(chǎn)品。一個(gè)具有良好伸縮性的網(wǎng)站，其設(shè)計(jì)總是走在業(yè)務(wù)發(fā)展的前面，在業(yè)務(wù)需要處理更多訪問(wèn)和處理之前，就已經(jīng)做好了充分的準(zhǔn)備，當(dāng)業(yè)務(wù)需要時(shí)，只需要增加服務(wù)器并簡(jiǎn)單部署就可以了，技術(shù)團(tuán)隊(duì)便可輕松應(yīng)對(duì)了。

　　在本篇的介紹中，有些核心的內(nèi)容比如一致性Hash算法只是進(jìn)行了簡(jiǎn)單的介紹，并沒(méi)有深入的分析，這個(gè)源于我目前對(duì)其的理解還只是皮毛。等待我深入學(xué)習(xí)之后，我會(huì)抽空寫(xiě)一篇單獨(dú)介紹一致性Hash算法的博文，并使用C#進(jìn)行一個(gè)粗略的實(shí)現(xiàn)，有興趣的朋友敬請(qǐng)期待吧。

另外，前面幾篇博文中有些園友提出介紹一些實(shí)踐性質(zhì)的東西，我在這里表示抱歉，因?yàn)楸緯?shū)只是單純地講解理論，而且也沒(méi)有深入地去講解這些理論，只是單純地?cái)U(kuò)展知識(shí)面，管中窺豹，一覽大型網(wǎng)站的技術(shù)體系。而我本人也還是一個(gè)即將求職和畢業(yè)的學(xué)生，在理論和實(shí)踐上都缺乏相應(yīng)的經(jīng)驗(yàn)，但我會(huì)在精讀完本書(shū)后去做一些相應(yīng)場(chǎng)景的具體實(shí)踐，比如使用Memcached或Redis構(gòu)建分布式緩存集群，使用Mono在Linux下搭建ASP.NET MVC應(yīng)用環(huán)境，使用高性能的Nginx或Jexus服務(wù)器構(gòu)建反向代理負(fù)載均衡服務(wù)器環(huán)境，使用發(fā)布訂閱模式實(shí)現(xiàn)MS SQL的讀寫(xiě)分離實(shí)踐等等，如果園友有興趣的話，也可以自行找資料去做相關(guān)實(shí)踐。如果覺(jué)得喜歡我的博文，那我只能說(shuō)敬請(qǐng)期待了（現(xiàn)在時(shí)間寶貴啊，馬上要找工作了，還得復(fù)習(xí)復(fù)習(xí)，再過(guò)段時(shí)間畢業(yè)論文的鴨梨又要來(lái)了，我勒個(gè)去），么么嗒。

參考文獻(xiàn)

　?。?）李智慧，《大型網(wǎng)站技術(shù)架構(gòu)-核心原理與案例分析》，http://item.jd.com/11322972.html

　?。?）老徐的私房菜，《HTTP無(wú)狀態(tài)協(xié)議和Session原理》，http://laoxu.blog.51cto.com/4120547/1219699

　?。?）百度百科，《一致性Hash算法》，http://baike.baidu.com/view/1588037.htm

　?。?）charlee，《Memcached完全剖析》，http://kb.cnblogs.com/page/42731/

　　（5）bluishglc，《數(shù)據(jù)庫(kù)Sharding的基本思想和切分策略》，http://blog.csdn.net/bluishglc/article/details/6161475

本章思維導(dǎo)圖