建站
咨詢
售后
建站咨詢
新聞中心
分布式 以下是分布式和集群，希望對大家有所幫助。
從網(wǎng)站建設(shè)到定制行業(yè)解決方案，為提供成都網(wǎng)站設(shè)計、網(wǎng)站制作服務(wù)體系，各種行業(yè)企業(yè)客戶提供網(wǎng)站建設(shè)解決方案，助力業(yè)務(wù)快速發(fā)展。創(chuàng)新互聯(lián)建站將不斷加快創(chuàng)新步伐，提供優(yōu)質(zhì)的建站服務(wù)。
1.分布式
小明的公司有3個系統(tǒng)： 系統(tǒng)A、系統(tǒng)B和系統(tǒng)C ，這三個系統(tǒng)所做的業(yè)務(wù)不同，被部署在3個獨(dú)立的機(jī)器上運(yùn)行， 他們之間互相調(diào)用(當(dāng)然是跨域網(wǎng)絡(luò)的)， 通力合作完成公司的業(yè)務(wù)流程。
將不同的業(yè)務(wù)分布在不同的地方， 這就構(gòu)成了一個分布式的系統(tǒng)，現(xiàn)在問題來了， 系統(tǒng)A是整個分布式系統(tǒng)的“臉面”， 用戶直接訪問，用戶量訪問大的時候要么是速度巨慢，要么直接掛掉， 怎么辦?
由于系統(tǒng)A只有一份， 所以會引起單點(diǎn)失敗。
2.集群(Cluster)
小明的公司不差錢，就多買幾臺機(jī)器吧， 小明把系統(tǒng)A一下子部署了好幾份(例如下圖的3個服務(wù)器)，每一份都是系統(tǒng)A的一個實例， 對外提供同樣的服務(wù)，這樣能睡個安穩(wěn)覺了，不怕其中一個壞掉了，我還有另外2個呢。
這3個服務(wù)器上的系統(tǒng)就組成了一個集群。
可是對用戶來說，一下子出現(xiàn)這么系統(tǒng)A ，每個系統(tǒng)的IP地址都不一樣， 到底訪問哪一個?
如果所有人都訪問服務(wù)器1.1 ，那服務(wù)器1.1 會被累死， 剩下的三個閑死，成了浪費(fèi)錢的擺設(shè)。
3.負(fù)載均衡(Load Balancer)
小明要盡可能的讓3個機(jī)器上的系統(tǒng)A 工作均衡一些， 比如有3萬個請求，那就讓3個服務(wù)器各處理1萬個(當(dāng)然，這是理想狀況)， 這叫負(fù)載均衡。
很明顯，這個負(fù)載均衡的工作最好獨(dú)立出來， 放到獨(dú)立的服務(wù)器上 (例如Ngnix)：
后來小明發(fā)現(xiàn)， 這個負(fù)載均衡的服務(wù)器雖然工作內(nèi)容很簡單，就是拿到請求，分發(fā)請求，但是它還是有可能掛掉啊， 單點(diǎn)失敗還是會出現(xiàn)。
沒辦法，只好把負(fù)載均衡也搞成一個集群， 不過和系統(tǒng)A的集群有兩點(diǎn)不同：
1. 這個新的集群中雖然有兩個機(jī)器，但我們可以用某種辦法，讓這個集群對外只提供一個IP地址， 也就是說用戶看到的好像只有一個機(jī)器。
2. 同一時刻，我們只讓一個負(fù)載均衡的機(jī)器工作， 另外一個原地待命。 如果工作的那個掛掉了，待命的那個就頂上去。
4.彈性
如果這3個系統(tǒng)A的實例還是滿足不了大量的請求，那就再加服務(wù)器!
雙11來了，用戶量是平時的10倍， 小明向領(lǐng)導(dǎo)申請費(fèi)用又買了幾十臺服務(wù)器，一下子把系統(tǒng)A部署了幾十份。 可是雙11過后， 流量一下子降下來了，那幾十個服務(wù)器用不上了，也變成了擺設(shè)!
被領(lǐng)導(dǎo)批評以后，小明決定嘗試一下云計算， 在云端可以輕松的創(chuàng)建、刪除虛擬的服務(wù)器， 那樣就可以輕松地隨著用戶的請求動態(tài)的增減服務(wù)器了。 雙11來了就創(chuàng)建虛擬服務(wù)器，等到雙11過去了就把不用的關(guān)掉， 省得浪費(fèi)錢。
于是小明的系統(tǒng)具備了一定的彈性。
5.失效轉(zhuǎn)移
上面的系統(tǒng)看起來很美好，但是做了一個不切實際的假設(shè)： 所有的服務(wù)都是無狀態(tài)的。 換句話說，假設(shè)用戶的兩次請求直接是沒有關(guān)聯(lián)的。
但是現(xiàn)實是，大部分服務(wù)都是有狀態(tài)的， 例如購物車。
用戶訪問系統(tǒng)，在服務(wù)器1.1上創(chuàng)建了一個購物車，并向其中加入了幾個商品， 然后 服務(wù)器1.1 掛掉了， 用戶的后續(xù)訪問就找不到服務(wù)器1.1了，這時候就要做失效轉(zhuǎn)移，讓另外幾個服務(wù)器去接管、去處理用戶的請求。
可是問題來了，在服務(wù)器1.2，1.3上有用戶的購物車嗎? 如果沒有， 用戶就會抱怨，我剛創(chuàng)建的購物車哪里去了?
還有更嚴(yán)重的，假設(shè)用戶是在服務(wù)器1.1上登錄的， 用戶登錄過的信息保存到了該服務(wù)器的session中， 現(xiàn)在這個服務(wù)器掛掉了， 用戶的session自然也不見了，當(dāng)用戶被失效轉(zhuǎn)移到其他服務(wù)器上的時候，其他服務(wù)器發(fā)現(xiàn)用戶沒有登錄， 就把用戶踢到了登錄界面， 讓用戶再次登錄!
狀態(tài)， 狀態(tài)，狀態(tài)! 用戶的登錄信息，購物車等都是狀態(tài)信息， 處理不好狀態(tài)的問題，集群的威力就大打折扣，無法完成真正的失效轉(zhuǎn)移， 甚至無法使用。
怎么辦?
一種辦法是把狀態(tài)信息在集群的各個服務(wù)器之間復(fù)制，讓集群的各個服務(wù)器達(dá)成一致， 誰來干這個事情? 只能是像Websphere, Weblogic這樣的應(yīng)用服務(wù)器了。
還有一種辦法， 就是把狀態(tài)信息集中存儲在一個地方， 讓集群的各個服務(wù)器都能訪問到：
小明聽說Redis 不錯， 那就用Redis來保存吧 !
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號coderising獲取授權(quán)】
網(wǎng)站欄目：小白科普：分布式和集群
標(biāo)題網(wǎng)址：http://www.5511xx.com/article/cceejdj.html
