分布式和集群

**自這裡

1.分布式

小明的公司有3個系統：系統a、系統b和系統c ，這三個系統所做的業務不同，被部署在3個獨立的機器上執行，他們之間互相呼叫（當然是跨域網路的），通力合作完成公司的業務流程。

將不同的業務分布在不同的地方，這就構成了乙個分布式的系統，現在問題來了，系統a是整個分布式系統的「臉面」，使用者直接訪問，使用者量訪問大的時候要麼是速度巨慢，要麼直接掛掉，怎麼辦？

由於系統a只有乙份，所以會引起單點失敗。

2集群（cluster）

2.集群

小明的公司不差錢，就多買幾台機器吧，小明把系統a一下子部署了好幾份，每乙份都是系統a的乙個例項，對外提供同樣的服務，這樣能睡個安穩覺了，不怕其中乙個壞掉了，我還有另外2個呢。

這3個伺服器上的系統就組成了乙個集群。

可是對使用者來說，一下子出現這麼系統a ，每個系統的ip位址都不一樣，到底訪問哪乙個？

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

3負載均衡（load balancer）

3.負載均衡（load balancer）

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

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

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

沒辦法，只好把負載均衡也搞成乙個集群，不過和系統a的集群有兩點不同：

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

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

4彈性

4.彈性

如果這3個系統a的例項還是滿足不了大量的請求，那就再加伺服器！

雙11來了，使用者量是平時的10倍，小明向領導申請費用又買了幾十台伺服器，一下子把系統a部署了幾十份。可是雙11過後，流量一下子降下來了，那幾十個伺服器用不上了，也變成了擺設！

被領導批評以後，小明決定嘗試一下雲計算，在雲端可以輕鬆的建立、刪除虛擬的伺服器，那樣就可以輕鬆地隨著使用者的請求動態的增減伺服器了。雙11來了就建立虛擬伺服器，等到雙11過去了就把不用的關掉，省得浪費錢。

於是小明的系統具備了一定的彈性。

5失效轉移

5.失效轉移

上面的系統看起來很美好，但是做了乙個不切實際的假設：所有的服務都是無狀態的。換句話說，假設使用者的兩次請求直接是沒有關聯的。

但是現實是，大部分服務都是有狀態的，例如購物車。

使用者訪問系統，在伺服器1.1上建立了乙個購物車，並向其中加入了幾個商品，然後伺服器1.1 掛掉了，使用者的後續訪問就找不到伺服器1.1了，這時候就要做失效轉移，讓另外幾個伺服器去接管、去處理使用者的請求。

可是問題來了，在伺服器1.2，1.3上有使用者的購物車嗎？如果沒有，使用者就會抱怨，我剛建立的購物車**去了？

還有更嚴重的，假設使用者是在伺服器1.1上登入的，

使用者登入過的資訊儲存到了該伺服器的session中，現在這個伺服器掛掉了，

使用者的session自然也不見了，當使用者被失效轉移到其他伺服器上的時候，其他伺服器發現使用者沒有登入，就把使用者踢到了登入介面，讓使用者再次登入！

狀態，狀態，狀態！使用者的登入資訊，購物車等都是狀態資訊，處理不好狀態的問題，集群的威力就大打折扣，無法完成真正的失效轉移，甚至無法使用。

怎麼辦？

一種辦法是把狀態資訊在集群的各個伺服器之間複製，讓集群的各個伺服器達成一致，誰來幹這個事情？只能是像websphere, weblogic這樣的應用伺服器了。

還有一種辦法，就是把狀態資訊集中儲存在乙個地方，讓集群的各個伺服器都能訪問到：

小明聽說redis 不錯，那就用redis來儲存吧！

(完)