原創： 老劉 碼農翻身 原文連結：https://mp.weixin.qq.com/s/HbYfF4iBGgc7VHPFr5qJoA

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的叢集有兩點不同：

1. 這個新的叢集中雖然有兩個機器，但我們可以用某種辦法，讓這個叢集對外只提供一個IP地址， 也就是說使用者看到的好像只有一個機器。
2. 同一時刻，我們只讓一個負載均衡的機器工作， 另外一個原地待命。 如果工作的那個掛掉了，待命的那個就頂上去。
   

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來儲存吧 ！

（完）