1分布式
小明的公司有3個系統： 系統A、系統B和系統C ，這三個系統所做的業務不同，被部署在3個獨立的機器上運行， 他們之間互相調用（當然是跨域網絡的）， 通力合作完成公司的業務流程。
將不同的業務分布在不同的地方， 這就構成了一個分布式的系統，現在問題來了， 系統A是整個分布式系統的“臉面”， 用戶直接訪問，用戶量訪問大的時候要么是速度巨慢，要么直接掛掉， 怎么辦？
由于系統A只有一份， 所以會引起單點失敗。
2集群（Cluster）
小明的公司不差錢，就多買幾臺機器吧， 小明把系統A一下子部署了好幾份（例如下圖的3個服務器），每一份都是系統A的一個實例， 對外提供同樣的服務，這樣能睡個安穩覺了，不怕其中一個壞掉了，我還有另外2個呢。
這3個服務器上的系統就組成了一個集群。
可是對用戶來說，一下子出現這么系統A ，每個系統的IP地址都不一樣， 到底訪問哪一個？
如果所有人都訪問服務器1.1 ，那服務器1.1 會被累死， 剩下的三個閑死，成了浪費錢的擺設。
3負載均衡（Load Balancer）
小明要盡可能的讓3個機器上的系統A 工作均衡一些， 比如有3萬個請求，那就讓3個服務器各處理1萬個（當然，這是理想狀況）， 這叫負載均衡。
很明顯，這個負載均衡的工作最好獨立出來， 放到獨立的服務器上 （例如Ngnix）：
后來小明發現， 這個負載均衡的服務器雖然工作內容很簡單，就是拿到請求，分發請求，但是它還是有可能掛掉啊， 單點失敗還是會出現。
沒辦法，只好把負載均衡也搞成一個集群， 不過和系統A的集群有兩點不同：
- 這個新的集群中雖然有兩個機器，但我們可以用某種辦法，讓這個集群對外只提供一個IP地址， 也就是說用戶看到的好像只有一個機器。
- 同一時刻，我們只讓一個負載均衡的機器工作， 另外一個原地待命。 如果工作的那個掛掉了，待命的那個就頂上去。
4彈性
如果這3個系統A的實例還是滿足不了大量的請求，那就再加服務器！
雙11來了，用戶量是平時的10倍， 小明向領導申請費用又買了幾十臺服務器，一下子把系統A部署了幾十份。 可是雙11過后， 流量一下子降下來了，那幾十個服務器用不上了，也變成了擺設！
被領導批評以后，小明決定嘗試一下云計算， 在云端可以輕松的創建、刪除虛擬的服務器， 那樣就可以輕松地隨著用戶的請求動態的增減服務器了。 雙11來了就創建虛擬服務器，等到雙11過去了就把不用的關掉， 省得浪費錢。
于是小明的系統具備了一定的彈性。
5失效轉移
上面的系統看起來很美好，但是做了一個不切實際的假設： 所有的服務都是無狀態的。 換句話說，假設用戶的兩次請求直接是沒有關聯的。
但是現實是，大部分服務都是有狀態的， 例如購物車。
用戶訪問系統，在服務器1.1上創建了一個購物車，并向其中加入了幾個商品， 然后 服務器1.1 掛掉了， 用戶的后續訪問就找不到服務器1.1了，這時候就要做失效轉移，讓另外幾個服務器去接管、去處理用戶的請求。
可是問題來了，在服務器1.2，1.3上有用戶的購物車嗎？ 如果沒有， 用戶就會抱怨，我剛創建的購物車哪里去了？
還有更嚴重的，假設用戶是在服務器1.1上登錄的， 用戶登錄過的信息保存到了該服務器的session中， 現在這個服務器掛掉了， 用戶的session自然也不見了，當用戶被失效轉移到其他服務器上的時候，其他服務器發現用戶沒有登錄， 就把用戶踢到了登錄界面， 讓用戶再次登錄！
狀態， 狀態，狀態！ 用戶的登錄信息，購物車等都是狀態信息， 處理不好狀態的問題，集群的威力就大打折扣，無法完成真正的失效轉移， 甚至無法使用。
怎么辦？
一種辦法是把狀態信息在集群的各個服務器之間復制，讓集群的各個服務器達成一致， 誰來干這個事情？ 只能是像Websphere, Weblogic這樣的應用服務器了。
還有一種辦法， 就是把狀態信息集中存儲在一個地方， 讓集群的各個服務器都能訪問到：
小明聽說Redis 不錯， 那就用Redis來保存吧 ！
