網(wǎng)站熱點(diǎn)問題思考

發(fā)布：2018-12-26 20:07:56 瀏覽：4355

針對秒殺系統(tǒng)所代表的熱點(diǎn)問題，我們根據(jù)多年的經(jīng)驗(yàn)總結(jié)出一些通用的原則:隔離、動態(tài)分離、分層校驗(yàn)，必須從全鏈路來考慮和優(yōu)化每個(gè)環(huán)節(jié)除了優(yōu)化系統(tǒng)提升性能以外，做好限流和保護(hù)也是必備的功課。

數(shù)據(jù)訪問熱點(diǎn)，比如詳情系統(tǒng)中某些熱點(diǎn)商品的訪問度非常高，即使是Tar緩存這種Cache本身也有瓶頸問題，一旦請求量達(dá)到單機(jī)的極限也會存在熱點(diǎn)保護(hù)問題。有時(shí)候看起來好像很容易解決，比如只需要做好限流，但是一且某個(gè)熱點(diǎn)觸發(fā)了一臺機(jī)器的限流閥值，那么整臺機(jī)器Cache的數(shù)據(jù)都將無效，進(jìn)而間接導(dǎo)致Cache被擊穿，請求都落到應(yīng)用的數(shù)據(jù)庫中，出現(xiàn)雪崩現(xiàn)象。所以這類問題需要與具體的Cache產(chǎn)品結(jié)合才能有比較好的解決方案。

一個(gè)通用的解決思路是:在Cache的client.端做本地的Localcache，當(dāng)發(fā)現(xiàn)熱點(diǎn)數(shù)據(jù)時(shí)直接Cache在client里，而不要請求到Cache的Server。

數(shù)據(jù)更新熱點(diǎn)。數(shù)據(jù)更新問題除了前面介紹的熱點(diǎn)隔離和排隊(duì)處理之外，還有些場景對商品的lastmodifytime字段更新會非常頻繁，在某些場景下這些多條SQL是可以合并的，一定時(shí)間內(nèi)只執(zhí)行最后一條SQL就行了，這樣可以減少對數(shù)據(jù)庫的update操作。另外，熱點(diǎn)商品的自動遷移理論上也可以在數(shù)據(jù)路由層完成，利用前面介紹的熱點(diǎn)實(shí)時(shí)發(fā)現(xiàn)功能，自動從普通庫里把熱點(diǎn)數(shù)據(jù)遷移出來放到單獨(dú)的熱點(diǎn)庫中。

按照某種維度建立的索引產(chǎn)生的熱點(diǎn)數(shù)據(jù)，比如實(shí)時(shí)搜索中按照商品維度關(guān)聯(lián)的評價(jià)數(shù)據(jù)。有些熱點(diǎn)商品的評價(jià)非常多，導(dǎo)致搜索系統(tǒng)在按照商品ID建立評價(jià)數(shù)據(jù)的索引時(shí)，內(nèi)存已經(jīng)存不了了。交易維度關(guān)聯(lián)訂單信息也同樣有這些問題。這類熱點(diǎn)數(shù)據(jù)需要做數(shù)據(jù)的散列，需要再增加一個(gè)維度，重新組織數(shù)據(jù)。

全局基礎(chǔ)設(shè)施優(yōu)化:資源調(diào)度優(yōu)化

全局基礎(chǔ)設(shè)施的優(yōu)化。我們做應(yīng)用層的優(yōu)化一般都比較關(guān)注網(wǎng)站建設(shè)軟件本身的優(yōu)化，但是支撐應(yīng)用運(yùn)行的基礎(chǔ)環(huán)境，往往有更大的優(yōu)化空間?；A(chǔ)設(shè)施包括基礎(chǔ)應(yīng)用容器如JDK、Tomcat、VM，操作系統(tǒng)和文件系統(tǒng)甚至硬件設(shè)備，它們其實(shí)都有優(yōu)本章我們重點(diǎn)闡述資源調(diào)度的優(yōu)化，因?yàn)樗罹咂兆沸浴r(jià)值也更大化的空間，而且由于基礎(chǔ)設(shè)施的優(yōu)化是事關(guān)全局的，所以通用性會更廣、收益會更大。