關(guān)于分布式環(huán)境下的幾個問題
1.根據(jù)系統(tǒng)標準時間判斷,如果分布式環(huán)境下各機器時間不同步怎么辦。同時發(fā)起的兩次請求,可能一個活動開始 另一個提示沒開始 2.如果判斷邏輯都放到后端,遇到有刷子,后端處理這些請求扛不住了咋整,可能活動沒開始,服務器已經(jīng)掛掉了、 3.負載均衡問題,比如根據(jù)地域在nginx哈希,怎樣能較好的保證各機器秒殺成功的盡量分布均勻呢。 以上幾個問題,老師方便做進一步的講解不,謝啦
1.根據(jù)系統(tǒng)標準時間判斷,如果分布式環(huán)境下各機器時間不同步怎么辦。同時發(fā)起的兩次請求,可能一個活動開始 另一個提示沒開始 2.如果判斷邏輯都放到后端,遇到有刷子,后端處理這些請求扛不住了咋整,可能活動沒開始,服務器已經(jīng)掛掉了、 3.負載均衡問題,比如根據(jù)地域在nginx哈希,怎樣能較好的保證各機器秒殺成功的盡量分布均勻呢。 以上幾個問題,老師方便做進一步的講解不,謝啦
2016-05-22
舉報
2016-05-22
第1個問題:后端服務器需要做NTP時間同步,如每5分鐘與NTP服務同步保證時間誤差在微妙級以下。時間同步在業(yè)務需要或者活性檢查場景很常見(如hbase的RegionServer),這塊課程里沒有說明這里補充一下。
第2個問題:秒殺開啟判斷在前端和后端都有,后端的判斷比較簡單取秒殺單做判斷,這塊的IO請求是DB主鍵查詢很快,單DB就可以抗住幾萬QPS,后面也會加入redis緩存為DB減負。
第3個問題:負載均衡包括nginx入口端和后端upstream服務,在入口端一般采用智能DNS解析請求就近進入nginx服務器。后端upstgream不建議采用一致性hash,防止請求不均勻。后端服務無狀態(tài)可以簡單使用輪訓機制。nginx負載均衡本身過于簡單,可以使用openresty自己實現(xiàn)或者nginx之后單獨架設負載均衡服務如Netflix的Zuul等。
對于流量爆增的造成后端不可用情況,這門課程并沒有做動態(tài)降級和彈性伸縮架構(gòu)上的處理,后面受慕課邀請會做一個獨立的實戰(zhàn)課,講解分布式架構(gòu),彈性容錯,微服務相關(guān)的內(nèi)容,到時會加入這方面的內(nèi)容。
2017-11-04
非常感謝,后面的課程請開通收費
2016-07-04
好期待后面分布式的知識