略談服務(wù)端緩存設(shè)計(jì)

liuyix 發(fā)布于2019-08-14 12:44 / 2755人閱讀

摘要：另載于大略談一下，各位輕拍哦服務(wù)端性能優(yōu)化，除了重構(gòu)，最常用的手段就是緩存。本地緩存是應(yīng)用程序在同一內(nèi)的緩存，通常是或。某臺(tái)更新了一條數(shù)據(jù)，就通知緩存把這條更新或丟棄，確保其他能拿到最新結(jié)果。

另載于 http://www.qingjingjie.com/blogs/13

大略談一下，各位輕拍哦！

服務(wù)端性能優(yōu)化，除了重構(gòu)，最常用的手段就是緩存。緩存主要分為本地緩存和分布式緩存兩種。

根據(jù)我們每日千萬(wàn)次訪問(wèn)的經(jīng)驗(yàn)來(lái)看，緩存不是必須的。優(yōu)化充足的情況下，SQL平均耗時(shí)1ms。這是因?yàn)槊辛怂饕⑶颐辛薓ySQL緩沖池(內(nèi)存中)。如果命中索引但不命中緩沖池，且查詢數(shù)據(jù)量不大，磁盤并發(fā)量不高，則大約耗時(shí)10ms(磁盤尋道)。如果這些都不滿足，耗時(shí)就大了。

所以首先要建設(shè)的是索引，一切供查詢的字段能索引就索引。有的字段取值多樣性很小，比如布爾值、枚舉值，就不適合索引(就算命中索引也可能要全盤掃描)，查詢時(shí)要聯(lián)合其他字段過(guò)濾下，才會(huì)快。Replication, Sharding也是好辦法，能用就用上。

本地緩存是應(yīng)用程序在同一JVM內(nèi)的緩存，通常是ConcurrentHashMap或Guava Cache。優(yōu)點(diǎn)是耗時(shí)低得忽略不計(jì)，缺點(diǎn)是占用本地內(nèi)存、多機(jī)會(huì)冗余、數(shù)據(jù)不同步。當(dāng)集群里每個(gè)App Server都有個(gè)緩存，會(huì)有很多數(shù)據(jù)是重復(fù)的，而且某臺(tái)機(jī)器更新了一條數(shù)據(jù)，別的機(jī)器不知道啊，只能等緩存過(guò)期。

同步問(wèn)題可以用消息隊(duì)列來(lái)解決，一臺(tái)有更新，廣播消息給其他機(jī)器，準(zhǔn)實(shí)時(shí)同步。

Guava Cache有expire或refresh兩種過(guò)期方式，expire是過(guò)期就丟棄，refresh是過(guò)期先留著舊值，取到新值再更新。expire會(huì)有點(diǎn)性能波動(dòng)，為了響應(yīng)性可以選擇refresh方式。另外建議設(shè)個(gè)上限，量太多會(huì)影響GC的。

根據(jù)Jim Gray的經(jīng)驗(yàn)數(shù)字，過(guò)期時(shí)間通常以5分鐘為宜(主要還是看你業(yè)務(wù)哦)。

分布式緩存是Memcached/Couchbase, Redis這類，訪問(wèn)要經(jīng)過(guò)網(wǎng)絡(luò)，多少會(huì)有一點(diǎn)點(diǎn)開銷。Memcached或Redis本身就要有集群，否則一旦扛不住并發(fā)，還不如數(shù)據(jù)庫(kù)呢。某臺(tái)App Server更新了一條數(shù)據(jù)，就通知緩存把這條更新或丟棄，確保其他Server能拿到最新結(jié)果。

查詢操作要有超時(shí)設(shè)置。注意耗時(shí)，如果超過(guò)10ms就有點(diǎn)不好了。

緩存服務(wù)用來(lái)存復(fù)雜查詢的結(jié)果倒是極合適的，這時(shí)候比數(shù)據(jù)庫(kù)快得多。

緩存除了加快訪問(wèn)以外，也能提高負(fù)載能力。因?yàn)閿?shù)據(jù)庫(kù)連接是有限的資源——不支持NIO，每個(gè)連接同時(shí)只能服務(wù)一個(gè)線程，有多少連接就有多少并發(fā)。如果有慢查詢占住了連接，系統(tǒng)性能會(huì)急劇下降！緩存就能減輕對(duì)數(shù)據(jù)庫(kù)連接的依賴。

本地緩存和分布式緩存各有千秋，一般建議用一致性更高的分布式緩存，當(dāng)性能需要極端調(diào)優(yōu)時(shí)，使用本地緩存。