1. 分布式

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

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

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

2集群（Cluster）

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

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

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

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

3負載均衡（Load Balancer）

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

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

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

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

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

2.同一時刻，我們只讓一個負載均衡的機器工作， 另外一個原地待命。 如果工作的那個掛掉了，待命的那個就頂上去。

4彈性

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

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

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

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

5失效轉(zhuǎn)移

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

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

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

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

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

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

怎么辦？

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

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

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