1. 分布式

小明的公司有3個(gè)系統(tǒng)： 系統(tǒng)A、系統(tǒng)B和系統(tǒng)C ，這三個(gè)系統(tǒng)所做的業(yè)務(wù)不同，被部署在3個(gè)獨(dú)立的機(jī)器上運(yùn)行， 他們之間互相調(diào)用（當(dāng)然是跨域網(wǎng)絡(luò)的）， 通力合作完成公司的業(yè)務(wù)流程。

將不同的業(yè)務(wù)分布在不同的地方， 這就構(gòu)成了一個(gè)分布式的系統(tǒng)，現(xiàn)在問題來了， 系統(tǒng)A是整個(gè)分布式系統(tǒng)的“臉面”， 用戶直接訪問，用戶量訪問大的時(shí)候要么是速度巨慢，要么直接掛掉， 怎么辦？

由于系統(tǒng)A只有一份， 所以會(huì)引起單點(diǎn)失敗。

2集群（Cluster）

小明的公司不差錢，就多買幾臺(tái)機(jī)器吧， 小明把系統(tǒng)A一下子部署了好幾份（例如下圖的3個(gè)服務(wù)器），每一份都是系統(tǒng)A的一個(gè)實(shí)例， 對(duì)外提供同樣的服務(wù)，這樣能睡個(gè)安穩(wěn)覺了，不怕其中一個(gè)壞掉了，我還有另外2個(gè)呢。

這3個(gè)服務(wù)器上的系統(tǒng)就組成了一個(gè)集群。

可是對(duì)用戶來說，一下子出現(xiàn)這么系統(tǒng)A ，每個(gè)系統(tǒng)的IP地址都不一樣， 到底訪問哪一個(gè)？

如果所有人都訪問服務(wù)器1.1 ，那服務(wù)器1.1 會(huì)被累死， 剩下的三個(gè)閑死，成了浪費(fèi)錢的擺設(shè)。

3負(fù)載均衡（Load Balancer）

小明要盡可能的讓3個(gè)機(jī)器上的系統(tǒng)A 工作均衡一些， 比如有3萬個(gè)請(qǐng)求，那就讓3個(gè)服務(wù)器各處理1萬個(gè)（當(dāng)然，這是理想狀況）， 這叫負(fù)載均衡。

很明顯，這個(gè)負(fù)載均衡的工作最好獨(dú)立出來， 放到獨(dú)立的服務(wù)器上 （例如Ngnix）：

后來小明發(fā)現(xiàn)， 這個(gè)負(fù)載均衡的服務(wù)器雖然工作內(nèi)容很簡單，就是拿到請(qǐng)求，分發(fā)請(qǐng)求，但是它還是有可能掛掉啊，單點(diǎn)失敗還是會(huì)出現(xiàn)。

沒辦法，只好把負(fù)載均衡也搞成一個(gè)集群， 不過和系統(tǒng)A的集群有兩點(diǎn)不同：

1. 這個(gè)新的集群中雖然有兩個(gè)機(jī)器，但我們可以用某種辦法，讓這個(gè)集群對(duì)外只提供一個(gè)IP地址， 也就是說用戶看到的好像只有一個(gè)機(jī)器。

2.同一時(shí)刻，我們只讓一個(gè)負(fù)載均衡的機(jī)器工作， 另外一個(gè)原地待命。 如果工作的那個(gè)掛掉了，待命的那個(gè)就頂上去。

4彈性

如果這3個(gè)系統(tǒng)A的實(shí)例還是滿足不了大量的請(qǐng)求，那就再加服務(wù)器！

雙11來了，用戶量是平時(shí)的10倍， 小明向領(lǐng)導(dǎo)申請(qǐng)費(fèi)用又買了幾十臺(tái)服務(wù)器，一下子把系統(tǒng)A部署了幾十份。 可是雙11過后， 流量一下子降下來了，那幾十個(gè)服務(wù)器用不上了，也變成了擺設(shè)！

被領(lǐng)導(dǎo)批評(píng)以后，小明決定嘗試一下云計(jì)算， 在云端可以輕松的創(chuàng)建、刪除虛擬的服務(wù)器， 那樣就可以輕松地隨著用戶的請(qǐng)求動(dòng)態(tài)的增減服務(wù)器了。 雙11來了就創(chuàng)建虛擬服務(wù)器，等到雙11過去了就把不用的關(guān)掉， 省得浪費(fèi)錢。

于是小明的系統(tǒng)具備了一定的彈性。

5失效轉(zhuǎn)移

上面的系統(tǒng)看起來很美好，但是做了一個(gè)不切實(shí)際的假設(shè)： 所有的服務(wù)都是無狀態(tài)的。 換句話說，假設(shè)用戶的兩次請(qǐng)求直接是沒有關(guān)聯(lián)的。

但是現(xiàn)實(shí)是，大部分服務(wù)都是有狀態(tài)的， 例如購物車。

用戶訪問系統(tǒng)，在服務(wù)器1.1上創(chuàng)建了一個(gè)購物車，并向其中加入了幾個(gè)商品， 然后 服務(wù)器1.1 掛掉了， 用戶的后續(xù)訪問就找不到服務(wù)器1.1了，這時(shí)候就要做失效轉(zhuǎn)移，讓另外幾個(gè)服務(wù)器去接管、去處理用戶的請(qǐng)求。

可是問題來了，在服務(wù)器1.2，1.3上有用戶的購物車嗎？ 如果沒有， 用戶就會(huì)抱怨，我剛創(chuàng)建的購物車哪里去了？

還有更嚴(yán)重的，假設(shè)用戶是在服務(wù)器1.1上登錄的， 用戶登錄過的信息保存到了該服務(wù)器的session中， 現(xiàn)在這個(gè)服務(wù)器掛掉了， 用戶的session自然也不見了，當(dāng)用戶被失效轉(zhuǎn)移到其他服務(wù)器上的時(shí)候，其他服務(wù)器發(fā)現(xiàn)用戶沒有登錄， 就把用戶踢到了登錄界面， 讓用戶再次登錄！

狀態(tài)， 狀態(tài)，狀態(tài)！ 用戶的登錄信息，購物車等都是狀態(tài)信息， 處理不好狀態(tài)的問題，集群的威力就大打折扣，無法完成真正的失效轉(zhuǎn)移， 甚至無法使用。

怎么辦？

一種辦法是把狀態(tài)信息在集群的各個(gè)服務(wù)器之間復(fù)制，讓集群的各個(gè)服務(wù)器達(dá)成一致， 誰來干這個(gè)事情？ 只能是像Websphere, Weblogic這樣的應(yīng)用服務(wù)器了。

還有一種辦法， 就是把狀態(tài)信息集中存儲(chǔ)在一個(gè)地方， 讓集群的各個(gè)服務(wù)器都能訪問到：

小明聽說Redis 不錯(cuò)， 那就用Redis來保存吧 ！