Redis面試題匯總
- 使用Redis的好處?
- key-value 形式的內(nèi)存數(shù)據(jù)庫苏揣。
- 數(shù)據(jù)訪問在內(nèi)存中,訪問速度快。
- 存儲(chǔ)的形式類似于HashMap,支持多種數(shù)據(jù)結(jié)構(gòu)(string,set,hash,sorted set,list)启妹。
- 支持事務(wù)(單條操作都是原子性的,但是不像數(shù)據(jù)庫的事務(wù)具有原子性)醉旦。
- 可用于緩存饶米,消息,按key設(shè)置過期時(shí)間车胡,過期后將會(huì)自動(dòng)刪除檬输。
- redis和memcached的共同點(diǎn)
- 都是 key-value 形式的內(nèi)存數(shù)據(jù)庫。
- 都是NoSQL家族的數(shù)據(jù)管理解決方案匈棘。
- 都基于同樣的key-value 數(shù)據(jù)模型丧慈。
- 數(shù)據(jù)放在內(nèi)存中(這也是適用于緩存的原因)。
- redis相比memcached有哪些優(yōu)勢主卫?
- memcached只支持簡單的字符串逃默,redis具有更豐富的類型。
- redis的訪問速度更快队秩。
- redis可以持久化數(shù)據(jù)笑旺。
- redis常見性能問題和解決方案。
- Master最好不要做持久化機(jī)制馍资。如RDB內(nèi)存快照和AOF日志文件筒主。
- 如果數(shù)據(jù)比較重要,某個(gè)Slave開啟AOF備份數(shù)據(jù)鸟蟹,策略設(shè)置為每秒同步一次乌妙。
- 為了主從復(fù)制的速度和連接的穩(wěn)定性,Master和Slave最好在同一個(gè)局域網(wǎng)內(nèi)建钥。
- 盡量避免在壓力很大的主庫上增加從庫藤韵。
- 主從復(fù)制不要用圖狀結(jié)構(gòu),用單向鏈表結(jié)構(gòu)更為穩(wěn)定熊经,即:Master <- Slave1 <- Slave2 <- Slave3… 這樣的結(jié)構(gòu)方便解決單點(diǎn)故障問題泽艘,實(shí)現(xiàn)Slave對Master的替換欲险。如果Master掛了,可以立刻啟用Slave1做Master匹涮,其他不變天试。
- redis的6種數(shù)據(jù)淘汰策略
- voltile-lru:從已設(shè)置過期時(shí)間的數(shù)據(jù)集(server.db[i].expires)中挑選最近最少使用的數(shù)據(jù)淘汰。
- volatile-ttl:從已設(shè)置過期時(shí)間的數(shù)據(jù)集(server.db[i].expires)具有更早過期時(shí)間的key優(yōu)先移除然低。
- volatile-random:從已設(shè)置過期時(shí)間的數(shù)據(jù)集(server.db[i].expires)中任意選擇數(shù)據(jù)淘汰喜每。
- allkeys-lru:從數(shù)據(jù)集(server.db[i].dict)中挑選最近最少使用的數(shù)據(jù)淘汰
- 從數(shù)據(jù)集(server.db[i].dict)中任意選擇數(shù)據(jù)淘汰。
- no-enviction(驅(qū)逐):禁止驅(qū)逐數(shù)據(jù)雳攘。
- Memcache與Redis的區(qū)別都有哪些带兜?
- 存儲(chǔ)方式
Memecache把數(shù)據(jù)全部存在內(nèi)存之中,斷電后會(huì)掛掉吨灭,數(shù)據(jù)不能超過內(nèi)存大小刚照。
Redis有部份存在硬盤上,這樣能保證數(shù)據(jù)的持久性沃于。
- 存儲(chǔ)方式
- 數(shù)據(jù)支持類型
Memecache只支持簡單的數(shù)據(jù)結(jié)構(gòu)(字符串)涩咖。
redis支持相對復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。
- 數(shù)據(jù)支持類型
- 使用底層模型不同繁莹。
它們之間底層實(shí)現(xiàn)方式 以及與客戶端之間通信的應(yīng)用協(xié)議不一樣檩互。
Redis直接自己構(gòu)建了VM 機(jī)制 ,因?yàn)橐话愕南到y(tǒng)調(diào)用系統(tǒng)函數(shù)的話咨演,會(huì)浪費(fèi)一定的時(shí)間去移動(dòng)和請求闸昨。
- 使用底層模型不同繁莹。
- value的大小的限制
redis最大可以達(dá)到1GB,而memcache只有1MB薄风。
- value的大小的限制
- redis 最適合的場景
- 會(huì)話緩存(Session Cache)
- 全頁緩存(FPC)
- 隊(duì)列
- 排行版計(jì)數(shù)器
- 發(fā)布訂閱
高可用分布式集群
一饵较、高可用
高可用(High Availability),是當(dāng)一臺(tái)服務(wù)器停止服務(wù)后遭赂,對于業(yè)務(wù)及用戶毫無影響循诉。 停止服務(wù)的原因可能由于網(wǎng)卡、路由器撇他、機(jī)房茄猫、CPU負(fù)載過高、內(nèi)存溢出困肩、自然災(zāi)害等不可預(yù)期的原因?qū)е禄Γ诤芏鄷r(shí)候也稱單點(diǎn)問題。
- 解決單點(diǎn)問題主要有2種方式:
- 主備方式
通常是一臺(tái)主機(jī)锌畸、一臺(tái)或多臺(tái)備機(jī)勇劣,在正常情況下主機(jī)對外提供服務(wù),并把數(shù)據(jù)同步到備機(jī)潭枣,當(dāng)主機(jī)宕機(jī)后比默,備機(jī)立刻開始服務(wù)幻捏。
Redis HA中使用比較多的是keepalived,它使主機(jī)備機(jī)對外提供同一個(gè)虛擬IP退敦,客戶端通過虛擬IP進(jìn)行數(shù)據(jù)操作粘咖,正常期間主機(jī)一直對外提供服務(wù),宕機(jī)后VIP自動(dòng)漂移到備機(jī)上侈百。
優(yōu)點(diǎn):對客戶端毫無影響,仍然通過VIP操作翰铡。
缺點(diǎn):在絕大多數(shù)時(shí)間內(nèi)備機(jī)是一直沒使用钝域,被浪費(fèi)著的。 - 主從方式
一主多從的辦法锭魔,主從之間進(jìn)行數(shù)據(jù)同步例证。 當(dāng)Master宕機(jī)后,通過選舉算法(Paxos迷捧、Raft)從slave中選舉出新Master繼續(xù)對外提供服務(wù)织咧,主機(jī)恢復(fù)后以slave的身份重新加入。
主從另一個(gè)目的是進(jìn)行讀寫分離漠秋,這是當(dāng)單機(jī)讀寫壓力過高的一種通用型解決方案笙蒙。 其主機(jī)的角色只提供寫操作或少量的讀,把多余讀請求通過負(fù)載均衡算法分流到單個(gè)或多個(gè)slave服務(wù)器上庆锦。
缺點(diǎn)是主機(jī)宕機(jī)后捅位,Slave雖然被選舉成新Master了,但對外提供的IP服務(wù)地址卻發(fā)生變化了搂抒,意味著會(huì)影響到客戶端艇搀。 解決這種情況需要一些額外的工作,在當(dāng)主機(jī)地址發(fā)生變化后及時(shí)通知到客戶端求晶,客戶端收到新地址后焰雕,使用新地址繼續(xù)發(fā)送新請求。
- 數(shù)據(jù)同步
- 同步方式:當(dāng)主機(jī)收到客戶端寫操作后芳杏,以同步方式把數(shù)據(jù)同步到從機(jī)上矩屁,當(dāng)從機(jī)也成功寫入后,主機(jī)才返回給客戶端成功蚜锨,也稱數(shù)據(jù)強(qiáng)一致性档插。 很顯然這種方式性能會(huì)降低不少,當(dāng)從機(jī)很多時(shí)亚再,可以不用每臺(tái)都同步郭膛,主機(jī)同步某一臺(tái)從機(jī)后,從機(jī)再把數(shù)據(jù)分發(fā)同步到其他從機(jī)上氛悬,這樣提高主機(jī)性能分擔(dān)同步壓力则剃。 在redis中是支持這楊配置的耘柱,一臺(tái)master,一臺(tái)slave棍现,同時(shí)這臺(tái)salve又作為其他slave的master调煎。
- 異步方式:主機(jī)接收到寫操作后,直接返回成功己肮,然后在后臺(tái)用異步方式把數(shù)據(jù)同步到從機(jī)上士袄。 這種同步性能比較好,但無法保證數(shù)據(jù)的完整性谎僻,比如在異步同步過程中主機(jī)突然宕機(jī)了娄柳,也稱這種方式為數(shù)據(jù)弱一致性。
- 方案的選擇
keepalived方案配置簡單艘绍、人力成本小赤拒,在數(shù)據(jù)量少、壓力小的情況下推薦使用诱鞠。 如果數(shù)據(jù)量比較大挎挖,不希望過多浪費(fèi)機(jī)器,還希望在宕機(jī)后航夺,做一些自定義的措施蕉朵,比如報(bào)警、記日志敷存、數(shù)據(jù)遷移等操作墓造,推薦使用主從方式,因?yàn)楹椭鲝拇钆涞囊话氵€有個(gè)管理監(jiān)控中心锚烦。
分布式
概念
分布式(distributed), 是當(dāng)業(yè)務(wù)量觅闽、數(shù)據(jù)量增加時(shí),可以通過任意增加減少服務(wù)器數(shù)量來解決問題涮俄。
集群時(shí)代
至少部署兩臺(tái)Redis服務(wù)器構(gòu)成一個(gè)小的集群蛉拙,主要有2個(gè)目的:
- 高可用性:在主機(jī)掛掉后,自動(dòng)故障轉(zhuǎn)移彻亲,使前端服務(wù)對用戶無影響孕锄。
-
讀寫分離:將主機(jī)讀壓力分流到從機(jī)上。
可在客戶端組件上實(shí)現(xiàn)負(fù)載均衡苞尝,根據(jù)不同服務(wù)器的運(yùn)行情況畸肆,分擔(dān)不同比例的讀請求壓力。
image.png
分布式集群時(shí)代
當(dāng)緩存數(shù)據(jù)量不斷增加時(shí)宙址,單機(jī)內(nèi)存不夠使用轴脐,需要把數(shù)據(jù)切分不同部分,分布到多臺(tái)服務(wù)器上。
大規(guī)模分布式集群時(shí)代
當(dāng)數(shù)據(jù)量持續(xù)增加時(shí)大咱,應(yīng)用可根據(jù)不同場景下的業(yè)務(wù)申請對應(yīng)的分布式集群恬涧。 這塊最關(guān)鍵的是緩存治理這塊,其中最重要的部分是加入了代理服務(wù)碴巾。 應(yīng)用通過代理訪問真實(shí)的Redis服務(wù)器進(jìn)行讀寫溯捆。
這樣做的好處是:
避免越來越多的客戶端直接訪問Redis服務(wù)器難以管理,而造成風(fēng)險(xiǎn)厦瓢。
在代理這一層可以做對應(yīng)的安全措施提揍,比如限流、授權(quán)旷痕、分片碳锈。
代理這層無狀態(tài)的,可任意擴(kuò)展節(jié)點(diǎn)欺抗,對于客戶端來說,訪問代理跟訪問單機(jī)Redis一樣强重。
總結(jié)
分布式緩存再向后是云服務(wù)緩存绞呈,對使用端完全屏蔽細(xì)節(jié),各應(yīng)用自行申請大小间景、流量方案即可佃声,如淘寶OCS云服務(wù)緩存。
分布式緩存對應(yīng)需要的實(shí)現(xiàn)組件有:
- 一個(gè)緩存監(jiān)控倘要、遷移圾亏、管理中心。
- 一個(gè)自定義的客戶端組件封拧,上圖中的SmartClient志鹃。
- 一個(gè)無狀態(tài)的代理服務(wù)。
- N臺(tái)服務(wù)器泽西。
參考以及轉(zhuǎn)載的文章
https://blog.csdn.net/yajlv/article/details/73467865
http://www.runoob.com/redis/redis-data-types.html