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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6、Redis有豐富的API，Map就簡單太多了

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

普通分頁

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

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

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

一種思路

最近想到了另一種思路。

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

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

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

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

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

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

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

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

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

其它的一些東東：

Lua是支持LRU模式的，即像Memcached一樣工作。但是貌似沒有見到有人這樣用，很是奇怪。

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

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

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

redis 本地緩存性能比較

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

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

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

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

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

Redis雙刪

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

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

最后刪一次

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

因?yàn)榫彺媸欠植际降模?dāng)一個(gè)緩存節(jié)點(diǎn)刪除緩存時(shí)，其他緩存節(jié)點(diǎn)可能還沒有更新緩存值，這時(shí)如果直接進(jìn)行刪除，就會(huì)出現(xiàn)緩存值不一致的情況。而通過只在最后一次需要?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)注本站哦！