大家好，今天給各位分享redis一級(jí)緩存和二級(jí)緩存的一些知識(shí)，其中也會(huì)對(duì)redis面試必會(huì)6題經(jīng)典進(jìn)行解釋，文章篇幅可能偏長(zhǎng)，如果能碰巧解決你現(xiàn)在面臨的問(wèn)題，別忘了關(guān)注本站，現(xiàn)在就馬上開(kāi)始吧！

本地緩存和redis區(qū)別

本地緩存和Redis都是用于存儲(chǔ)數(shù)據(jù)的工具，但它們有區(qū)別：

存儲(chǔ)位置不同：本地緩存存儲(chǔ)在應(yīng)用程序進(jìn)程內(nèi)部的內(nèi)存中，而Redis是一個(gè)獨(dú)立的進(jìn)程，通過(guò)網(wǎng)絡(luò)協(xié)議提供服務(wù)。

存儲(chǔ)策略不同：本地緩存的存儲(chǔ)策略通常是基于LRU算法實(shí)現(xiàn)的，即最近最少使用的數(shù)據(jù)會(huì)被清除；而Redis默認(rèn)使用的是基于虛擬內(nèi)存的方式，即數(shù)據(jù)會(huì)被存儲(chǔ)在內(nèi)存和磁盤中，內(nèi)存不足時(shí)，部分?jǐn)?shù)據(jù)會(huì)被換出到磁盤中。

功能不同：本地緩存通常只能用于單機(jī)應(yīng)用程序的緩存，而Redis可以支持分布式緩存和持久化存儲(chǔ)、消息隊(duì)列等多種功能。

性能不同：由于本地緩存存儲(chǔ)在應(yīng)用程序內(nèi)部，訪問(wèn)速度較快，但由于存儲(chǔ)空間有限，可能會(huì)導(dǎo)致應(yīng)用程序頻繁的訪問(wèn)數(shù)據(jù)庫(kù)；而Redis作為一個(gè)獨(dú)立的進(jìn)程，可以獨(dú)立于應(yīng)用程序，提供更快的數(shù)據(jù)訪問(wèn)速度和更穩(wěn)定的性能。

因此，本地緩存和Redis都有各自的優(yōu)點(diǎn)和適用場(chǎng)景，需要根據(jù)具體的業(yè)務(wù)需求和性能需求綜合考慮。

redis和map有什么區(qū)別

二者主要區(qū)別如下：

1、Redis可以用幾十G內(nèi)存來(lái)做緩存，Map不行，一般JVM也就分幾個(gè)G數(shù)據(jù)就夠大了

2、Redis的緩存可以持久化，Map是內(nèi)存對(duì)象，程序一重啟數(shù)據(jù)就沒(méi)了

3、Redis可以實(shí)現(xiàn)分布式的緩存，Map只能存在創(chuàng)建它的程序里

4、Redis可以處理每秒百萬(wàn)級(jí)的并發(fā)，是專業(yè)的緩存服務(wù)，Map只是一個(gè)普通的對(duì)象

5、Redis緩存有過(guò)期機(jī)制，Map本身無(wú)此功能

6、Redis有豐富的API，Map就簡(jiǎn)單太多了

redis怎么緩存用戶列表，做到可以分頁(yè)展示

普通分頁(yè)

一般分頁(yè)做緩存都是直接查找出來(lái)，按頁(yè)放到緩存里，但是這種緩存方式有很多缺點(diǎn)。

如緩存不能及時(shí)更新，一旦數(shù)據(jù)有變化，所有的之前的分頁(yè)緩存都失效了。

比如像微博這樣的場(chǎng)景，微博下面現(xiàn)在有一個(gè)頂次數(shù)的排序。這個(gè)用傳統(tǒng)的分頁(yè)方式很難應(yīng)對(duì)。

一種思路

最近想到了另一種思路。

數(shù)據(jù)以ID為key緩存到Redis里；

把數(shù)據(jù)ID和排序打分存到Redis的skiplist，即zset里；

當(dāng)查找數(shù)據(jù)時(shí)，先從Redis里的skiplist取出對(duì)應(yīng)的分頁(yè)數(shù)據(jù)，得到ID列表。

用multiget從redis上一次性把ID列表里的所有數(shù)據(jù)都取出來(lái)。如果有缺少某些ID的數(shù)據(jù)，再?gòu)臄?shù)據(jù)庫(kù)里查找，再一塊返回給用戶，并把查出來(lái)的數(shù)據(jù)按ID緩存到Redis里。

在最后一步，可以有一些小技巧：

比如在缺少一些ID數(shù)據(jù)的情況下，先直接返回給用戶，然后前端再用ajax請(qǐng)求缺少的ID的數(shù)據(jù)，再動(dòng)態(tài)刷新。

還有一些可能用Lua腳本合并操作的優(yōu)化，不過(guò)考慮到Lua腳本比較慢，可能要仔細(xì)測(cè)試。

如果是利用Lua腳本的話，可以在一個(gè)請(qǐng)求里完成下面的操作：

查找某頁(yè)的所有文章，返回已緩存的文章的ID及內(nèi)容，還有不在緩存里的文章的ID列表。

其它的一些東東：

Lua是支持LRU模式的，即像Memcached一樣工作。但是貌似沒(méi)有見(jiàn)到有人這樣用，很是奇怪。

可能是用redis早就準(zhǔn)備好把redis做存儲(chǔ)了，也不擔(dān)心內(nèi)存的容量問(wèn)題。

Redis在實(shí)際應(yīng)用中，是單獨(dú)部署在一個(gè)服務(wù)器中，還是和項(xiàng)目跑在一個(gè)服務(wù)器中，還是跑在數(shù)據(jù)庫(kù)服務(wù)器

看規(guī)模吧！小規(guī)模直接用docker跟服務(wù)一起跑。我們是直接跑k8s上，通過(guò)redis-operator來(lái)管理redis集群，使用sentinel模式！redis集群的運(yùn)維工作基本上由k8s管理，擴(kuò)縮容都是秒級(jí)實(shí)現(xiàn)。容器技術(shù)出來(lái)以后，基本很少用宿主機(jī)跑redis，除了一些老項(xiàng)目以外，新項(xiàng)目都直接容器化了。

redis 本地緩存性能比較

不考慮并發(fā)問(wèn)題，本地緩存自然是最快的。但是如果本地緩存不加鎖，那應(yīng)并發(fā)了咋辦呢？所以，我們以加鎖方式再比較一次。

場(chǎng)景使用，同一數(shù)據(jù)，從數(shù)據(jù)庫(kù)取出來(lái)，放到redis只要一次，而放到本地緩存，則需要n個(gè)集群次

redis可以寫磁盤，持久化，本地緩存不可以或者說(shuō)很麻煩要考慮的東西太多

redis雙刪和最后刪一次區(qū)別

Redis雙刪和最后刪一次都是解決刪除緩存在分布式環(huán)境下可能出現(xiàn)的問(wèn)題，但它們實(shí)現(xiàn)的方式不同。

Redis雙刪

Redis雙刪是一種常見(jiàn)的解決分布式環(huán)境下刪除緩存的方法，其基本思路是在刪除緩存之前，先將緩存設(shè)置為一個(gè)特殊值（如null），然后再刪除。這樣可以避免在刪除時(shí)出現(xiàn)緩存值不一致的情況。

因?yàn)榫彺媸欠植际降模?dāng)一個(gè)緩存節(jié)點(diǎn)刪除緩存時(shí)，其他緩存節(jié)點(diǎn)可能還沒(méi)有更新緩存值，這時(shí)如果直接進(jìn)行刪除，就會(huì)出現(xiàn)緩存值不一致的情況。而通過(guò)先將緩存設(shè)置為一個(gè)特殊值，可以確保所有緩存節(jié)點(diǎn)都已經(jīng)更新緩存值，然后再進(jìn)行刪除，就可以避免緩存值不一致的情況。

最后刪一次

最后刪一次是一種更加簡(jiǎn)單的解決分布式環(huán)境下刪除緩存的方法，其基本思路是在刪除緩存時(shí)，只進(jìn)行一次刪除操作，而不是兩次。

因?yàn)榫彺媸欠植际降模?dāng)一個(gè)緩存節(jié)點(diǎn)刪除緩存時(shí)，其他緩存節(jié)點(diǎn)可能還沒(méi)有更新緩存值，這時(shí)如果直接進(jìn)行刪除，就會(huì)出現(xiàn)緩存值不一致的情況。而通過(guò)只在最后一次需要?jiǎng)h除緩存時(shí)進(jìn)行刪除操作，可以確保所有緩存節(jié)點(diǎn)都已經(jīng)更新緩存值，就可以避免緩存值不一致的情況。

需要注意的是，最后刪一次的方法并不能完全避免緩存值不一致的情況，因?yàn)樵谧詈笠淮蝿h除緩存之前，仍然存在緩存值不一致的可能性。但是，因?yàn)樽詈笠淮蝿h除緩存之前，緩存值已經(jīng)被更新了很多次，所以出現(xiàn)不一致的情況會(huì)大大減少。

好了，本文到此結(jié)束，如果可以幫助到大家，還望關(guān)注本站哦！