談一下我的理解，如果有不對(duì)的地方，請(qǐng)留言指正。

Redis自身是可以做數(shù)據(jù)持久化的，很多同學(xué)都會(huì)想Redis應(yīng)該可以替代MySQL，但是我們使用一項(xiàng)技術(shù)、一個(gè)框架的時(shí)候，不是看它能不能，而是要看它適合不適合。

所以大多數(shù)公司的存儲(chǔ)都是MySQL+Redis，MySQL（或者其他關(guān)系型數(shù)據(jù)庫(kù)）作為主存儲(chǔ)，Redis作為輔助存儲(chǔ)，被用作緩存，這樣可以加快訪問(wèn)讀取的速度，提高性能。

Redis被用作緩存，以減少數(shù)據(jù)庫(kù)IO的讀操作，減輕數(shù)據(jù)庫(kù)的壓力，例如：

存儲(chǔ)熱點(diǎn)數(shù)據(jù)：經(jīng)常會(huì)被查詢，但是不經(jīng)常被修改或者刪除的數(shù)據(jù)；

計(jì)數(shù)器：諸如很多論壇用于統(tǒng)計(jì)點(diǎn)擊數(shù)；

分布式鎖及單線程機(jī)制；

最新列表、排行榜：請(qǐng)不要使用select top 10 from xxxx。

很多時(shí)候，程序員習(xí)慣先查詢Redis，查詢不到的話再去查詢數(shù)據(jù)庫(kù)，能查到的話再寫(xiě)入Redis中，認(rèn)為這樣不僅緩解了數(shù)據(jù)庫(kù)的壓力，同時(shí)也能保證數(shù)據(jù)的準(zhǔn)確性。

但是由于緩存不命中就會(huì)查詢數(shù)據(jù)庫(kù)，如果一直查詢不到的話，就導(dǎo)致每次請(qǐng)求都會(huì)查詢數(shù)據(jù)庫(kù)，如果短時(shí)間內(nèi)有大量這樣的請(qǐng)求，那么數(shù)據(jù)庫(kù)可能會(huì)扛不住。

這就是緩存穿透。

其實(shí)應(yīng)對(duì)的方法也很簡(jiǎn)單，查詢不到的數(shù)據(jù)，也緩存到Redis中，并設(shè)置數(shù)據(jù)的過(guò)期時(shí)間。

舉個(gè)不一定恰當(dāng)?shù)睦樱鏡edis中緩存員工信息，提供接口根據(jù)工號(hào)查詢員工信息：

接口入?yún)⒐ぬ?hào)A001。

系統(tǒng)先在Redis中查詢，查詢不到。

系統(tǒng)去數(shù)據(jù)庫(kù)中查詢，也查詢不到。

系統(tǒng)插入Redis，key=A001，value=null，設(shè)置過(guò)期時(shí)間五分鐘。

這樣，五分鐘之內(nèi)再根據(jù)A001查詢，不會(huì)穿透到數(shù)據(jù)庫(kù)。

四分鐘后，數(shù)據(jù)庫(kù)中插入了A001的數(shù)據(jù)。

五分鐘后，Redis中數(shù)據(jù)過(guò)期，下一次請(qǐng)求過(guò)來(lái)，會(huì)查詢數(shù)據(jù)庫(kù)，并把信息加載到Redis中。

希望我的回答，能夠幫助到你！

我會(huì)持續(xù)分享Java程序開(kāi)發(fā)、架構(gòu)設(shè)計(jì)、職業(yè)發(fā)展等方面的知識(shí)和見(jiàn)解，希望能得到你的關(guān)注今日頭條【會(huì)點(diǎn)代碼的大叔】，轉(zhuǎn)載請(qǐng)注明出處。