1. 分布式

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

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

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

2集群（Cluster）

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

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

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

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

3負載均衡（Load Balancer）

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

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

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

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

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

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

4彈性

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

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

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

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

5失效轉移

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

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

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

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

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

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

怎么辦？

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

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

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