【正文】
不對(duì)請(qǐng)求間短暫存在的會(huì)話數(shù)據(jù)作任何緩存。也不在應(yīng)用層緩存共享的業(yè)務(wù)對(duì)象,比如商品和用戶數(shù)據(jù)。我們有意地犧牲 緩存這些數(shù)據(jù)的潛在利益,換取可用性和正確性。在此必須指出,其他網(wǎng)站采取了不同的途徑,作了不同的取舍,也同樣取得了成功。好東西也會(huì)過(guò)猶不及。為緩存分配的內(nèi)存越多,能用來(lái)服務(wù)單個(gè)請(qǐng)求的內(nèi)存就越少。應(yīng)用層常常有內(nèi)存不足的壓力,因此這是非?,F(xiàn)實(shí)的權(quán)衡。更重要的一 點(diǎn),當(dāng)你開始依賴于緩存,那么主要系統(tǒng)就只需要滿足緩存未命中時(shí)的處理要求,自然而然你就會(huì)想到可以削減主要系統(tǒng)。但當(dāng)你這樣做之后,系統(tǒng)就完全離不開緩 存了?,F(xiàn)在主要系統(tǒng)沒辦法直接應(yīng)付全部流量,也就是說(shuō)網(wǎng)站的可用性取決于緩存能否100%正常運(yùn)行——潛在的危局。哪怕是例行的操作,比如重新配置緩存資 源、把緩存移動(dòng)到別的機(jī)器、冷啟動(dòng)緩存服務(wù)器,都有可能引發(fā)嚴(yán)重的問(wèn)題。做得好,緩存系統(tǒng)能讓可伸縮性的曲線向下彎曲,也就是比線性增長(zhǎng)還要好——后續(xù)請(qǐng)求從緩存中取數(shù)據(jù)比從主存儲(chǔ)取數(shù)據(jù)成本低廉。反過(guò)來(lái),緩存做得不好 會(huì)引入相當(dāng)多額外的經(jīng)常耗費(fèi),也會(huì)妨礙到可用性。我還沒見過(guò)哪個(gè)系統(tǒng)沒機(jī)會(huì)讓緩存大展拳腳的,關(guān)鍵是要根據(jù)具體情況找到適當(dāng)緩存策略??偨Y(jié)可伸縮性有時(shí)候被叫做“非功能性需求”,言下之意是它與功能無(wú)關(guān),也就比較不重要。這么說(shuō)簡(jiǎn)直錯(cuò)到了極點(diǎn)。我的觀點(diǎn)是,可伸縮性是功能的先決條件——優(yōu)先級(jí)為0的需求,比一切需求的優(yōu)先級(jí)都高。希望以上最佳實(shí)踐能對(duì)你有用,希望能幫助你從新的角度審視你的系統(tǒng),無(wú)論其規(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)任多個(gè)軟件開發(fā)和架構(gòu)的職位。他經(jīng)常在業(yè)界的會(huì)議上講授可伸縮性和架構(gòu)模式。