資訊專欄INFORMATION COLUMN
摘要：另載于大略談一下，各位輕拍哦服務(wù)端性能優(yōu)化，除了重構(gòu)，最常用的手段就是緩存。本地緩存是應(yīng)用程序在同一內(nèi)的緩存，通常是或。某臺更新了一條數(shù)據(jù)，就通知緩存把這條更新或丟棄，確保其他能拿到最新結(jié)果。
另載于 http://www.qingjingjie.com/blogs/13
大略談一下，各位輕拍哦！
服務(wù)端性能優(yōu)化，除了重構(gòu)，最常用的手段就是緩存。緩存主要分為本地緩存和分布式緩存兩種。
根據(jù)我們每日千萬次訪問的經(jīng)驗來看，緩存不是必須的。優(yōu)化充足的情況下，SQL平均耗時1ms。這是因為命中了索引，并且命中了MySQL緩沖池(內(nèi)存中)。如果命中索引但不命中緩沖池，且查詢數(shù)據(jù)量不大，磁盤并發(fā)量不高，則大約耗時10ms(磁盤尋道)。如果這些都不滿足，耗時就大了。
所以首先要建設(shè)的是索引，一切供查詢的字段能索引就索引。有的字段取值多樣性很小，比如布爾值、枚舉值，就不適合索引(就算命中索引也可能要全盤掃描)，查詢時要聯(lián)合其他字段過濾下，才會快。Replication, Sharding也是好辦法，能用就用上。
本地緩存是應(yīng)用程序在同一JVM內(nèi)的緩存，通常是ConcurrentHashMap或Guava Cache。優(yōu)點是耗時低得忽略不計，缺點是占用本地內(nèi)存、多機會冗余、數(shù)據(jù)不同步。當集群里每個App Server都有個緩存，會有很多數(shù)據(jù)是重復(fù)的，而且某臺機器更新了一條數(shù)據(jù)，別的機器不知道啊，只能等緩存過期。
同步問題可以用消息隊列來解決，一臺有更新，廣播消息給其他機器，準實時同步。
Guava Cache有expire或refresh兩種過期方式，expire是過期就丟棄，refresh是過期先留著舊值，取到新值再更新。expire會有點性能波動，為了響應(yīng)性可以選擇refresh方式。另外建議設(shè)個上限，量太多會影響GC的。
根據(jù)Jim Gray的經(jīng)驗數(shù)字，過期時間通常以5分鐘為宜(主要還是看你業(yè)務(wù)哦)。
分布式緩存是Memcached/Couchbase, Redis這類，訪問要經(jīng)過網(wǎng)絡(luò)，多少會有一點點開銷。Memcached或Redis本身就要有集群，否則一旦扛不住并發(fā)，還不如數(shù)據(jù)庫呢。某臺App Server更新了一條數(shù)據(jù)，就通知緩存把這條更新或丟棄，確保其他Server能拿到最新結(jié)果。
查詢操作要有超時設(shè)置。注意耗時，如果超過10ms就有點不好了。
緩存服務(wù)用來存復(fù)雜查詢的結(jié)果倒是極合適的，這時候比數(shù)據(jù)庫快得多。
緩存除了加快訪問以外，也能提高負載能力。因為數(shù)據(jù)庫連接是有限的資源——不支持NIO，每個連接同時只能服務(wù)一個線程，有多少連接就有多少并發(fā)。如果有慢查詢占住了連接，系統(tǒng)性能會急劇下降！緩存就能減輕對數(shù)據(jù)庫連接的依賴。
本地緩存和分布式緩存各有千秋，一般建議用一致性更高的分布式緩存，當性能需要極端調(diào)優(yōu)時，使用本地緩存。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/64671.html
摘要：但實際情況是緩存是大型網(wǎng)站的標配。以上分析告訴我們緩存架構(gòu)要滿足冷熱分離的特征不滿足，因為冷數(shù)據(jù)可能擠走熱數(shù)據(jù)。另外，眾所周知，緩存架構(gòu)還要滿足讀寫分離的特征也不滿足，因為寫操作會爭搶讀操作的資源。這種風(fēng)格需要緩存系統(tǒng)的支持。 問題背景 略談服務(wù)端緩存設(shè)計 一文說到緩存不是必須的，因為數(shù)據(jù)庫本身就利用了內(nèi)存。但實際情況是緩存是大型網(wǎng)站的標配。 雖然經(jīng)驗顯示RDBMS最快時只需0~1ms...
摘要：但實際情況是緩存是大型網(wǎng)站的標配。以上分析告訴我們緩存架構(gòu)要滿足冷熱分離的特征不滿足，因為冷數(shù)據(jù)可能擠走熱數(shù)據(jù)。另外，眾所周知，緩存架構(gòu)還要滿足讀寫分離的特征也不滿足，因為寫操作會爭搶讀操作的資源。這種風(fēng)格需要緩存系統(tǒng)的支持。 問題背景 略談服務(wù)端緩存設(shè)計 一文說到緩存不是必須的，因為數(shù)據(jù)庫本身就利用了內(nèi)存。但實際情況是緩存是大型網(wǎng)站的標配。 雖然經(jīng)驗顯示RDBMS最快時只需0~1ms...
摘要：但實際情況是緩存是大型網(wǎng)站的標配。以上分析告訴我們緩存架構(gòu)要滿足冷熱分離的特征不滿足，因為冷數(shù)據(jù)可能擠走熱數(shù)據(jù)。另外，眾所周知，緩存架構(gòu)還要滿足讀寫分離的特征也不滿足，因為寫操作會爭搶讀操作的資源。這種風(fēng)格需要緩存系統(tǒng)的支持。 問題背景 略談服務(wù)端緩存設(shè)計 一文說到緩存不是必須的，因為數(shù)據(jù)庫本身就利用了內(nèi)存。但實際情況是緩存是大型網(wǎng)站的標配。 雖然經(jīng)驗顯示RDBMS最快時只需0~1ms...
摘要：關(guān)于緩存熱點重建原文說到在緩存失效的瞬間，有大量線程來重建緩存，造成后端負載加大，甚至可能會讓應(yīng)用崩潰，并給出互斥鎖和永遠不過期兩種候選方案。即使繞過互斥鎖，也不會產(chǎn)生什么不好的后果，因為更新緩存是一個冪等操作。 向大家推薦這篇文章——Redis架構(gòu)之防雪崩設(shè)計：網(wǎng)站不宕機背后的兵法 （另外推薦我去年的短文作為餐前點心——略談服務(wù)端緩存設(shè)計） 《Redis架構(gòu)之防雪崩設(shè)計》這篇文章（下...
閱讀 877·2021-11-12 10:36
閱讀 3477·2021-09-08 10:44
閱讀 2804·2019-08-30 11:08
閱讀 1464·2019-08-29 16:12
閱讀 2738·2019-08-29 12:24
閱讀 979·2019-08-26 10:14
閱讀 760·2019-08-23 18:32
閱讀 1242·2019-08-23 17:52
