點擊上方"java全棧技術"關注,每天學習一個java知識點
1分佈式
小明的公司有3個系統: 系統A、系統B和系統C ,這三個系統所做的業務不同,被部署在3個獨立的機器上運行, 他們之間互相調用(當然是跨域網絡的), 通力合作完成公司的業務流程。
![「每日分享」分佈式和集群](http://p2.ttnews.xyz/loading.gif)
將不同的業務分佈在不同的地方, 這就構成了一個分佈式的系統,現在問題來了, 系統A是整個分佈式系統的“臉面”, 用戶直接訪問,用戶量訪問大的時候要麼是速度巨慢,要麼直接掛掉, 怎麼辦?
由於系統A只有一份, 所以會引起單點失敗。
2集群(Cluster)
小明的公司不差錢,就多買幾臺機器吧, 小明把系統A一下子部署了好幾份(例如下圖的3個服務器),每一份都是系統A的一個實例, 對外提供同樣的服務,這樣能睡個安穩覺了,不怕其中一個壞掉了,我還有另外2個呢。
這3個服務器上的系統就組成了一個集群。
![「每日分享」分佈式和集群](http://p2.ttnews.xyz/loading.gif)
可是對用戶來說,一下子出現這麼系統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來保存吧 !
閱讀更多 java全棧技術 的文章