【正文】
不對請求間短暫存在的會話數(shù)據(jù)作任何緩存。也不在應(yīng)用層緩存共享的業(yè)務(wù)對象,比如商品和用戶數(shù)據(jù)。我們有意地犧牲 緩存這些數(shù)據(jù)的潛在利益,換取可用性和正確性。在此必須指出,其他網(wǎng)站采取了不同的途徑,作了不同的取舍,也同樣取得了成功。好東西也會過猶不及。為緩存分配的內(nèi)存越多,能用來服務(wù)單個請求的內(nèi)存就越少。應(yīng)用層常常有內(nèi)存不足的壓力,因此這是非常現(xiàn)實的權(quán)衡。更重要的一 點,當(dāng)你開始依賴于緩存,那么主要系統(tǒng)就只需要滿足緩存未命中時的處理要求,自然而然你就會想到可以削減主要系統(tǒng)。但當(dāng)你這樣做之后,系統(tǒng)就完全離不開緩 存了?,F(xiàn)在主要系統(tǒng)沒辦法直接應(yīng)付全部流量,也就是說網(wǎng)站的可用性取決于緩存能否100%正常運行——潛在的危局。哪怕是例行的操作,比如重新配置緩存資 源、把緩存移動到別的機(jī)器、冷啟動緩存服務(wù)器,都有可能引發(fā)嚴(yán)重的問題。做得好,緩存系統(tǒng)能讓可伸縮性的曲線向下彎曲,也就是比線性增長還要好——后續(xù)請求從緩存中取數(shù)據(jù)比從主存儲取數(shù)據(jù)成本低廉。反過來,緩存做得不好 會引入相當(dāng)多額外的經(jīng)常耗費,也會妨礙到可用性。我還沒見過哪個系統(tǒng)沒機(jī)會讓緩存大展拳腳的,關(guān)鍵是要根據(jù)具體情況找到適當(dāng)緩存策略??偨Y(jié)可伸縮性有時候被叫做“非功能性需求”,言下之意是它與功能無關(guān),也就比較不重要。這么說簡直錯到了極點。我的觀點是,可伸縮性是功能的先決條件——優(yōu)先級為0的需求,比一切需求的優(yōu)先級都高。希望以上最佳實踐能對你有用,希望能幫助你從新的角度審視你的系統(tǒng),無論其規(guī)模如何。參考 eBay39。s Architectural Principles (video) Werner Vogels on scalability Dan Pritchett on You Scaled Your What? The Coming of the Shard Trading Consistency for Availability in Distributed Architectures Eric Brewer on the CAP Theorem SEDA: An Architecture for WellConditioned, Scalable Internet Services關(guān)于作者Randy Shoup是eBay的杰出架構(gòu)師。從2004年起擔(dān)任eBay搜索基礎(chǔ)設(shè)施的主要架構(gòu)師。在加入eBay之前,他是Tumbleweed Communications公司的總架構(gòu)師,也曾在Oracle和Informatica擔(dān)任多個軟件開發(fā)和架構(gòu)的職位。他經(jīng)常在業(yè)界的會議上講授可伸縮性和架構(gòu)模式。