k8s部署redis有必要嗎？有必要，在redis以及緩存瞬間加速，也可以就布署在k8s上面，可以不基于運(yùn)用的快速部署。實(shí)際有狀態(tài)的服務(wù)來(lái)絕對(duì)的保證服務(wù)的真正。是從configmap來(lái)需要保存redi

k8s部署redis有必要嗎？

有必要，在redis以及緩存瞬間加速，也可以就布署在k8s上面，可以不基于運(yùn)用的快速部署。實(shí)際有狀態(tài)的服務(wù)來(lái)絕對(duì)的保證服務(wù)的真正。是從configmap來(lái)需要保存redis的配置，不使用nodePort來(lái)急速提供服務(wù)。如果只是做緩存，但量不太大，這個(gè)可以不持久度。

spring的ehcachecachemanager有什么用途？

SpringCache是要看你使用的實(shí)現(xiàn)，詳細(xì)在SpringContext中是cacheManagerBean。默認(rèn)內(nèi)置3種基于，EHCache，Redis，ConcurrentHashMap。使用Spring是對(duì)EHCache是可以可以使用一樓的配置，是可以有實(shí)效的。不使用Redis在緩存的時(shí)候也也可以在用實(shí)效的

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

普通地分頁(yè)

一般分頁(yè)做緩存也是然后直接輸入進(jìn)去，按頁(yè)放在緩存里，但這種緩存有很多缺點(diǎn)。

如緩存沒(méi)法一定要及時(shí)可以更新，那樣一來(lái)數(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，即ziplist里；

當(dāng)查看數(shù)據(jù)時(shí)，先從Redis里的skiplist拿出按的分頁(yè)數(shù)據(jù)，換取ID列表。

用multilet's從redis上最少把ID列表里的所有數(shù)據(jù)都取出來(lái)。要是有有了某些ID的數(shù)據(jù)，再?gòu)臄?shù)據(jù)庫(kù)里里查，再那塊前往給用戶，并把查出來(lái)的數(shù)據(jù)按ID緩存到Redis里。

在最后踏上一步，這個(gè)可以有一些小技巧：

諸如在不完全一些ID數(shù)據(jù)的情況下，先然后趕往給用戶，然后再前端再用ajax請(qǐng)求不完整的ID的數(shù)據(jù)，再動(dòng)態(tài)刷新。

還有一些很有可能用Lua腳本合并操作的優(yōu)化，只不過(guò)確定到Lua腳本也很慢，可能會(huì)要翻看測(cè)試3。

假如是用來(lái)Lua腳本的話，可以在一個(gè)請(qǐng)求里能完成下面的操作：

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

其它的一些東東：

Lua是意見(jiàn)LRU模式的，即像Memcached差不多工作。只不過(guò)啊,不過(guò)沒(méi)有看見(jiàn)什么人那樣的話用，很是奇怪。

很有可能是用redis已經(jīng)準(zhǔn)備著好把redis做讀取了，也不懷疑內(nèi)存的容量問(wèn)題。