速度快,因?yàn)閿?shù)據(jù)存在內(nèi)存中,類似于HashMap,HashMap的優(yōu)勢(shì)就是查找和操作的時(shí)間復(fù)雜度都是O(1)
成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供大廠網(wǎng)站建設(shè)、大廠做網(wǎng)站、大廠網(wǎng)站設(shè)計(jì)、大廠網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、大廠企業(yè)網(wǎng)站模板建站服務(wù),十多年大廠做網(wǎng)站經(jīng)驗(yàn),不只是建網(wǎng)站,更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。支持豐富數(shù)據(jù)類型,支持string,list,set,sorted set,hash
支持事務(wù),操作都是原子性,所謂的原子性就是對(duì)數(shù)據(jù)的更改要么全部執(zhí)行,要么全部不執(zhí)行
豐富的特性:可用于緩存,消息,按key設(shè)置過期時(shí)間,過期后將會(huì)自動(dòng)刪除
memcached所有的值均是簡(jiǎn)單的字符串,redis作為其替代者,支持更為豐富的數(shù)據(jù)類型
redis的速度比memcached快很多
redis可以持久化其數(shù)據(jù)
Master最好不要做任何持久化工作,如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對(duì)Master的替換。如果Master掛了,可以立刻啟用Slave1做Master,其他不變。
Redis最適合所有數(shù)據(jù)in-momory的場(chǎng)景,雖然Redis也提供持久化功能,但實(shí)際更多的是一個(gè)disk-backed的功能,跟傳統(tǒng)意義上的持久化有比較大的差別,那么可能大家就會(huì)有疑問,似乎Redis更像一個(gè)加強(qiáng)版的Memcached,那么何時(shí)使用Memcached,何時(shí)使用Redis呢?
如果簡(jiǎn)單地比較Redis與Memcached的區(qū)別,大多數(shù)都會(huì)得到以下觀點(diǎn):
Redis不僅僅支持簡(jiǎn)單的k/v類型的數(shù)據(jù),同時(shí)還提供list,set,zset,hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。
Redis支持?jǐn)?shù)據(jù)的備份,即master-slave模式的數(shù)據(jù)備份。
Redis支持?jǐn)?shù)據(jù)的持久化,可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中,重啟的時(shí)候可以再次加載進(jìn)行使用。
(1)會(huì)話緩存(Session Cache) 最常用的一種使用Redis的情景是會(huì)話緩存(session cache)。用Redis緩存會(huì)話比其他存儲(chǔ)(如Memcached)的優(yōu)勢(shì)在于:Redis提供持久化。當(dāng)維護(hù)一個(gè)不是嚴(yán)格要求一致性的緩存時(shí),如果用戶的購物車信息全部丟失,大部分人都會(huì)不高興的,現(xiàn)在,他們還會(huì)這樣嗎? 幸運(yùn)的是,隨著 Redis 這些年的改進(jìn),很容易找到怎么恰當(dāng)?shù)氖褂肦edis來緩存會(huì)話的文檔。甚至廣為人知的商業(yè)平臺(tái)Magento也提供Redis的插件。
(2)全頁緩存(FPC) 除基本的會(huì)話token之外,Redis還提供很簡(jiǎn)便的FPC平臺(tái)?;氐揭恢滦詥栴},即使重啟了Redis實(shí)例,因?yàn)橛写疟P的持久化,用戶也不會(huì)看到頁面加載速度的下降,這是一個(gè)極大改進(jìn),類似PHP本地FPC。 再次以Magento為例,Magento提供一個(gè)插件來使用Redis作為全頁緩存后端。 此外,對(duì)WordPress的用戶來說,Pantheon有一個(gè)非常好的插件 wp-redis,這個(gè)插件能幫助你以最快速度加載你曾瀏覽過的頁面。
(3)隊(duì)列 Reids在內(nèi)存存儲(chǔ)引擎領(lǐng)域的一大優(yōu)點(diǎn)是提供 list 和 set 操作,這使得Redis能作為一個(gè)很好的消息隊(duì)列平臺(tái)來使用。Redis作為隊(duì)列使用的操作,就類似于本地程序語言(如Python)對(duì) list 的 push/pop 操作。 如果你快速的在Google中搜索“Redis queues”,你馬上就能找到大量的開源項(xiàng)目,這些項(xiàng)目的目的就是利用Redis創(chuàng)建非常好的后端工具,以滿足各種隊(duì)列需求。例如,Celery有一個(gè)后臺(tái)就是使用Redis作為broker,你可以從這里去查看。
(4)排行榜/計(jì)數(shù)器 Redis在內(nèi)存中對(duì)數(shù)字進(jìn)行遞增或遞減的操作實(shí)現(xiàn)的非常好。集合(Set)和有序集合(Sorted Set)也使得我們?cè)趫?zhí)行這些操作的時(shí)候變的非常簡(jiǎn)單,Redis只是正好提供了這兩種數(shù)據(jù)結(jié)構(gòu)。所以,我們要從排序集合中獲取到排名最靠前的10個(gè)用戶–我們稱之為“user_scores”,我們只需要像下面一樣執(zhí)行即可: 當(dāng)然,這是假定你是根據(jù)你用戶的分?jǐn)?shù)做遞增的排序。如果你想返回用戶及用戶的分?jǐn)?shù),你需要這樣執(zhí)行: ZRANGE user_scores 0 10 WITHSCORES Agora Games就是一個(gè)很好的例子,用Ruby實(shí)現(xiàn)的,它的排行榜就是使用Redis來存儲(chǔ)數(shù)據(jù)的,你可以在這里看到。
(5)發(fā)布/訂閱 最后(但肯定不是最不重要的)是Redis的發(fā)布/訂閱功能。發(fā)布/訂閱的使用場(chǎng)景確實(shí)非常多。我已看見人們?cè)谏缃痪W(wǎng)絡(luò)連接中使用,還可作為基于發(fā)布/訂閱的腳本觸發(fā)器,甚至用Redis的發(fā)布/訂閱功能來建立聊天系統(tǒng)?。ú?,這是真的,你可以去核實(shí))。
Redis提供的所有特性中,我感覺這個(gè)是喜歡的人最少的一個(gè),雖然它為用戶提供如果此多功能。
(1)Redis是單進(jìn)程單線程的 redis利用隊(duì)列技術(shù)將并發(fā)訪問變?yōu)榇性L問,消除了傳統(tǒng)數(shù)據(jù)庫串行控制的開銷
(2)讀寫分離模型 通過增加Slave DB的數(shù)量,讀的性能可以線性增長(zhǎng)。為了避免Master DB的單點(diǎn)故障,集群一般都會(huì)采用兩臺(tái)Master DB做雙機(jī)熱備,所以整個(gè)集群的讀和寫的可用性都非常高。 讀寫分離架構(gòu)的缺陷在于,不管是Master還是Slave,每個(gè)節(jié)點(diǎn)都必須保存完整的數(shù)據(jù),如果在數(shù)據(jù)量很大的情況下,集群的擴(kuò)展能力還是受限于單個(gè)節(jié)點(diǎn)的存儲(chǔ)能力,而且對(duì)于Write-intensive類型的應(yīng)用,讀寫分離架構(gòu)并不適合。
(3)數(shù)據(jù)分片模型 為了解決讀寫分離模型的缺陷,可以將數(shù)據(jù)分片模型應(yīng)用進(jìn)來。 可以將每個(gè)節(jié)點(diǎn)看成都是獨(dú)立的master,然后通過業(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)分片。 結(jié)合上面兩種模型,可以將每個(gè)master設(shè)計(jì)成由一個(gè)master和多個(gè)slave組成的模型。
(4)Redis的回收策略
volatile-lru:從已設(shè)置過期時(shí)間的數(shù)據(jù)集(server.db[i].expires)中挑選最近最少使用的數(shù)據(jù)淘汰
volatile-ttl:從已設(shè)置過期時(shí)間的數(shù)據(jù)集(server.db[i].expires)中挑選將要過期的數(shù)據(jù)淘汰
volatile-random:從已設(shè)置過期時(shí)間的數(shù)據(jù)集(server.db[i].expires)中任意選擇數(shù)據(jù)淘汰
allkeys-lru:從數(shù)據(jù)集(server.db[i].dict)中挑選最近最少使用的數(shù)據(jù)淘汰
allkeys-random:從數(shù)據(jù)集(server.db[i].dict)中任意選擇數(shù)據(jù)淘汰
no-enviction(驅(qū)逐):禁止驅(qū)逐數(shù)據(jù)
注意這里的6種機(jī)制,volatile和allkeys規(guī)定了是對(duì)已設(shè)置過期時(shí)間的數(shù)據(jù)集淘汰數(shù)據(jù)還是從全部數(shù)據(jù)集淘汰數(shù)據(jù),后面的lru、ttl以及random是三種不同的淘汰策略,再加上一種no-enviction永不回收的策略。
使用策略規(guī)則:
如果數(shù)據(jù)呈現(xiàn)冪律分布,也就是一部分?jǐn)?shù)據(jù)訪問頻率高,一部分?jǐn)?shù)據(jù)訪問頻率低,則使用allkeys-lru
如果數(shù)據(jù)呈現(xiàn)平等分布,也就是所有的數(shù)據(jù)訪問頻率都相同,則使用allkeys-random
相關(guān)知識(shí):redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時(shí)候,就會(huì)施行數(shù)據(jù)淘汰策略。redis提供6種數(shù)據(jù)淘汰策略見上面一條
使用keys指令可以掃出指定模式的key列表。
對(duì)方接著追問:如果這個(gè)redis正在給線上的業(yè)務(wù)提供服務(wù),那使用keys指令會(huì)有什么問題?
這個(gè)時(shí)候你要回答redis關(guān)鍵的一個(gè)特性:redis的單線程的。keys指令會(huì)導(dǎo)致線程阻塞一段時(shí)間,線上服務(wù)會(huì)停頓,直到指令執(zhí)行完畢,服務(wù)才能恢復(fù)。這個(gè)時(shí)候可以使用scan指令,scan指令可以無阻塞的提取出指定模式的key列表,但是會(huì)有一定的重復(fù)概率,在客戶端做一次去重就可以了,但是整體所花費(fèi)的時(shí)間會(huì)比直接用keys指令長(zhǎng)。
Master寫內(nèi)存快照,save命令調(diào)度rdbSave函數(shù),會(huì)阻塞主線程的工作,當(dāng)快照比較大時(shí)對(duì)性能影響是非常大的,會(huì)間斷性暫停服務(wù),所以Master最好不要寫內(nèi)存快照。
Master AOF持久化,如果不重寫AOF文件,這個(gè)持久化方式對(duì)性能的影響是最小的,但是AOF文件會(huì)不斷增大,AOF文件過大會(huì)影響Master重啟的恢復(fù)速度。Master最好不要做任何持久化工作,包括內(nèi)存快照和AOF日志文件,特別是不要啟用內(nèi)存快照做持久化,如果數(shù)據(jù)比較關(guān)鍵,某個(gè)Slave開啟AOF備份數(shù)據(jù),策略為每秒同步一次。
Master調(diào)用BGREWRITEAOF重寫AOF文件,AOF在重寫的時(shí)候會(huì)占大量的CPU和內(nèi)存資源,導(dǎo)致服務(wù)load過高,出現(xiàn)短暫服務(wù)暫停現(xiàn)象。
Redis主從復(fù)制的性能問題,為了主從復(fù)制的速度和連接的穩(wěn)定性,Slave和Master最好在同一個(gè)局域網(wǎng)內(nèi)
字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。
如果你是Redis中高級(jí)用戶,還需要加上下面幾種數(shù)據(jù)結(jié)構(gòu)HyperLogLog、Geo、Pub/Sub。
如果你說還玩過Redis Module,像BloomFilter,RedisSearch,Redis-ML,面試官得眼睛就開始發(fā)亮了。
先拿setnx來爭(zhēng)搶鎖,搶到之后,再用expire給鎖加一個(gè)過期時(shí)間防止鎖忘記了釋放。
這時(shí)候?qū)Ψ綍?huì)告訴你說你回答得不錯(cuò),然后接著問如果在setnx之后執(zhí)行expire之前進(jìn)程意外crash或者要重啟維護(hù)了,那會(huì)怎么樣?
這時(shí)候你要給予驚訝的反饋:唉,是喔,這個(gè)鎖就永遠(yuǎn)得不到釋放了。緊接著你需要抓一抓自己得腦袋,故作思考片刻,好像接下來的結(jié)果是你主動(dòng)思考出來的,然后回答:我記得set指令有非常復(fù)雜的參數(shù),這個(gè)應(yīng)該是可以同時(shí)把setnx和expire合成一條指令來用的!對(duì)方這時(shí)會(huì)顯露笑容,心里開始默念:摁,這小子還不錯(cuò)。
一般使用list結(jié)構(gòu)作為隊(duì)列,rpush生產(chǎn)消息,lpop消費(fèi)消息。當(dāng)lpop沒有消息的時(shí)候,要適當(dāng)sleep一會(huì)再重試。
如果對(duì)方追問可不可以不用sleep呢?list還有個(gè)指令叫blpop,在沒有消息的時(shí)候,它會(huì)阻塞住直到消息到來。
如果對(duì)方追問能不能生產(chǎn)一次消費(fèi)多次呢?使用pub/sub主題訂閱者模式,可以實(shí)現(xiàn)1:N的消息隊(duì)列。
如果對(duì)方追問pub/sub有什么缺點(diǎn)?在消費(fèi)者下線的情況下,生產(chǎn)的消息會(huì)丟失,得使用專業(yè)的消息隊(duì)列如rabbitmq等。
如果對(duì)方追問redis如何實(shí)現(xiàn)延時(shí)隊(duì)列?我估計(jì)現(xiàn)在你很想把面試官一棒打死如果你手上有一根棒球棍的話,怎么問的這么詳細(xì)。但是你很克制,然后神態(tài)自若的回答道:使用sortedset,拿時(shí)間戳作為score,消息內(nèi)容作為key調(diào)用zadd來生產(chǎn)消息,消費(fèi)者用zrangebyscore指令獲取N秒之前的數(shù)據(jù)輪詢進(jìn)行處理。
到這里,面試官暗地里已經(jīng)對(duì)你豎起了大拇指。但是他不知道的是此刻你卻豎起了中指,在椅子背后。
如果大量的key過期時(shí)間設(shè)置的過于集中,到過期的那個(gè)時(shí)間點(diǎn),redis可能會(huì)出現(xiàn)短暫的卡頓現(xiàn)象。一般需要在時(shí)間上加一個(gè)隨機(jī)值,使得過期時(shí)間分散一些。
Redis為了達(dá)到最快的讀寫速度將數(shù)據(jù)都讀到內(nèi)存中,并通過異步的方式將數(shù)據(jù)寫入磁盤。所以redis具有快速和數(shù)據(jù)持久化的特征。如果不將數(shù)據(jù)放在內(nèi)存中,磁盤I/O速度為嚴(yán)重影響redis的性能。在內(nèi)存越來越便宜的今天,redis將會(huì)越來越受歡迎。 如果設(shè)置了大使用的內(nèi)存,則數(shù)據(jù)已有記錄數(shù)達(dá)到內(nèi)存限值后不能繼續(xù)插入新值。
bgsave做鏡像全量持久化,aof做增量持久化。因?yàn)閎gsave會(huì)耗費(fèi)較長(zhǎng)時(shí)間,不夠?qū)崟r(shí),在停機(jī)的時(shí)候會(huì)導(dǎo)致大量丟失數(shù)據(jù),所以需要aof來配合使用。在redis實(shí)例重啟時(shí),會(huì)使用bgsave持久化文件重新構(gòu)建內(nèi)存,再使用aof重放近期的操作指令來實(shí)現(xiàn)完整恢復(fù)重啟之前的狀態(tài)。
對(duì)方追問那如果突然機(jī)器掉電會(huì)怎樣?取決于aof日志sync屬性的配置,如果不要求性能,在每條寫指令時(shí)都sync一下磁盤,就不會(huì)丟失數(shù)據(jù)。但是在高性能的要求下每次都sync是不現(xiàn)實(shí)的,一般都使用定時(shí)sync,比如1s1次,這個(gè)時(shí)候最多就會(huì)丟失1s的數(shù)據(jù)。
對(duì)方追問bgsave的原理是什么?你給出兩個(gè)詞匯就可以了,fork和cow。fork是指redis通過創(chuàng)建子進(jìn)程來進(jìn)行bgsave操作,cow指的是copy on write,子進(jìn)程創(chuàng)建后,父子進(jìn)程共享數(shù)據(jù)段,父進(jìn)程繼續(xù)提供讀寫服務(wù),寫臟的頁面數(shù)據(jù)會(huì)逐漸和子進(jìn)程分離開來。
RDB持久化方式能夠在指定的時(shí)間間隔能對(duì)你的數(shù)據(jù)進(jìn)行快照存儲(chǔ)。
AOF持久化方式記錄每次對(duì)服務(wù)器寫的操作,當(dāng)服務(wù)器重啟的時(shí)候會(huì)重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù),AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾。Redis還能對(duì)AOF文件進(jìn)行后臺(tái)重寫,使得AOF文件的體積不至于過大。
如果你只希望你的數(shù)據(jù)在服務(wù)器運(yùn)行的時(shí)候存在,你也可以不使用任何持久化方式。
你也可以同時(shí)開啟兩種持久化方式, 在這種情況下, 當(dāng)redis重啟的時(shí)候會(huì)優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù),因?yàn)樵谕ǔG闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整。
最重要的事情是了解RDB和AOF持久化方式的不同,讓我們以RDB持久化方式開始。
一般來說, 如果想達(dá)到足以媲美PostgreSQL的數(shù)據(jù)安全性, 你應(yīng)該同時(shí)使用兩種持久化功能。如果你非常關(guān)心你的數(shù)據(jù), 但仍然可以承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失,那么你可以只使用RDB持久化。
有很多用戶都只使用AOF持久化,但并不推薦這種方式:因?yàn)槎〞r(shí)生成RDB快照(snapshot)非常便于進(jìn)行數(shù)據(jù)庫備份, 并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比AOF恢復(fù)的速度要快,除此之外, 使用RDB還可以避免之前提到的AOF程序的bug。
可以將多次IO往返的時(shí)間縮減為一次,前提是pipeline執(zhí)行的指令之間沒有因果相關(guān)性。使用redis-benchmark進(jìn)行壓測(cè)的時(shí)候可以發(fā)現(xiàn)影響redis的QPS峰值的一個(gè)重要因素是pipeline批次指令的數(shù)目。
Redis可以使用主從同步,從從同步。第一次同步時(shí),主節(jié)點(diǎn)做一次bgsave,并同時(shí)將后續(xù)修改操作記錄到內(nèi)存buffer,待完成后將rdb文件全量同步到復(fù)制節(jié)點(diǎn),復(fù)制節(jié)點(diǎn)接受完成后將rdb鏡像加載到內(nèi)存。加載完成后,再通知主節(jié)點(diǎn)將期間修改的操作記錄同步到復(fù)制節(jié)點(diǎn)進(jìn)行重放就完成了同步過程。
Redis Sentinal著眼于高可用,在master宕機(jī)時(shí)會(huì)自動(dòng)將slave提升為master,繼續(xù)提供服務(wù)。
Redis Cluster著眼于擴(kuò)展性,在單個(gè)redis內(nèi)存不足時(shí),使用Cluster進(jìn)行分片存儲(chǔ)。
理論上Redis可以處理多達(dá)232的keys,并且在實(shí)際中進(jìn)行了測(cè)試,每個(gè)實(shí)例至少存放了2億5千萬的keys。我們正在測(cè)試一些較大的值。
任何list、set、和sorted set都可以放232個(gè)元素。
換句話說,Redis的存儲(chǔ)極限是系統(tǒng)中的可用內(nèi)存值。
如果Redis被當(dāng)做緩存使用,使用一致性哈希實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)容縮容。
如果Redis被當(dāng)做一個(gè)持久化存儲(chǔ)使用,必須使用固定的keys-to-nodes映射關(guān)系,節(jié)點(diǎn)的數(shù)量一旦確定不能變化。否則的話(即Redis節(jié)點(diǎn)需要?jiǎng)討B(tài)變化的情況),必須使用可以在運(yùn)行時(shí)進(jìn)行數(shù)據(jù)再平衡的一套系統(tǒng),而當(dāng)前只有Redis集群可以做到這樣。
創(chuàng)新互聯(lián)www.cdcxhl.cn,專業(yè)提供香港、美國云服務(wù)器,動(dòng)態(tài)BGP最優(yōu)骨干路由自動(dòng)選擇,持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證, 機(jī)房獨(dú)有T級(jí)流量清洗系統(tǒng)配攻擊溯源,準(zhǔn)確進(jìn)行流量調(diào)度,確保服務(wù)器高可用性。佳節(jié)活動(dòng)現(xiàn)已開啟,新人活動(dòng)云服務(wù)器買多久送多久。
當(dāng)前文章:面試前必須要知道的21道Redis面試題-創(chuàng)新互聯(lián)
文章來源:http://jinyejixie.com/article24/dedcce.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供域名注冊(cè)、App設(shè)計(jì)、定制開發(fā)、企業(yè)網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、面包屑導(dǎo)航
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容