關於redis的基礎知識及面試可能會考到的知識點

  最近在學習redis和kafka這兩篇博客就分別作一下總結,方便本身之後學習。node

          redis是一個開源的、使用C語言編寫的、支持網絡交互的、可基於內存也可持久化的Key-Value數據庫。面試

【redis數據結構 – 簡介】redis

redis是一種高級的key:value存儲系統,其中value支持五種數據類型:數據庫

1.字符串(strings)
2.字符串列表(lists)
3.字符串集合(sets)
4.有序字符串集合(sorted sets)
5.哈希(hashes)緩存

而關於key,有幾個點要提醒你們:安全

1.key不要太長,儘可能不要超過1024字節,這不只消耗內存,並且會下降查找的效率;
2.key也不要過短,過短的話,key的可讀性會下降;
3.在一個項目中,key最好使用統一的命名模式,例如user:10000:passwd。服務器

聊聊redis持久化 – 兩種方式】網絡

redis提供了兩種持久化的方式,分別是RDB(Redis DataBase)和AOF(Append Only File)。數據結構

RDB,簡而言之,就是在不一樣的時間點,將redis存儲的數據生成快照並存儲到磁盤等介質上;多線程

AOF,則是換了一個角度來實現持久化,那就是將redis執行過的全部寫指令記錄下來,在下次redis從新啓動時,只要把這些寫指令從前到後再重複執行一遍,就能夠實現數據恢復了。

其實RDB和AOF兩種方式也能夠同時使用,在這種狀況下,若是redis重啓的話,則會優先採用AOF方式來進行數據恢復,這是由於AOF方式的數據恢復完整度更高。

若是你沒有數據持久化的需求,也徹底能夠關閉RDB和AOF方式,這樣的話,redis將變成一個純內存數據庫,就像memcache同樣。

【聊聊redis持久化 – RDB】

RDB方式,是將redis某一時刻的數據持久化到磁盤中,是一種快照式的持久化方法。

redis在進行數據持久化的過程當中,會先將數據寫入到一個臨時文件中,待持久化過程都結束了,纔會用這個臨時文件替換上次持久化好的文件。正是這種特性,讓咱們能夠隨時來進行備份,由於快照文件老是完整可用的。

對於RDB方式,redis會單首創建(fork)一個子進程來進行持久化,而主進程是不會進行任何IO操做的,這樣就確保了redis極高的性能。

若是須要進行大規模數據的恢復,且對於數據恢復的完整性不是很是敏感,那RDB方式要比AOF方式更加的高效。

雖然RDB有很多優勢,但它的缺點也是不容忽視的。若是你對數據的完整性很是敏感,那麼RDB方式就不太適合你,由於即便你每5分鐘都持久化一次,當redis故障時,仍然會有近5分鐘的數據丟失。因此,redis還提供了另外一種持久化方式,那就是AOF。

【聊聊redis持久化 – AOF】

AOF,英文是Append Only File,即只容許追加不容許改寫的文件。

如前面介紹的,AOF方式是將執行過的寫指令記錄下來,在數據恢復時按照從前到後的順序再將指令都執行一遍,就這麼簡單。

咱們經過配置redis.conf中的appendonly yes就能夠打開AOF功能。若是有寫操做(如SET等),redis就會被追加到AOF文件的末尾。

默認的AOF持久化策略是每秒鐘fsync一次(fsync是指把緩存中的寫指令記錄到磁盤中),由於在這種狀況下,redis仍然能夠保持很好的處理性能,即便redis故障,也只會丟失最近1秒鐘的數據。

若是在追加日誌時,剛好遇到磁盤空間滿、inode滿或斷電等狀況致使日誌寫入不完整,也沒有關係,redis提供了redis-check-aof工具,能夠用來進行日誌修復。

由於採用了追加方式,若是不作任何處理的話,AOF文件會變得愈來愈大,爲此,redis提供了AOF文件重寫(rewrite)機制,即當AOF文件的大小超過所設定的閾值時,redis就會啓動AOF文件的內容壓縮,只保留能夠恢復數據的最小指令集。舉個例子或許更形象,假如咱們調用了100次INCR指令,在AOF文件中就要存儲100條指令,但這明顯是很低效的,徹底能夠把這100條指令合併成一條SET指令,這就是重寫機制的原理。

在進行AOF重寫時,仍然是採用先寫臨時文件,所有完成後再替換的流程,因此斷電、磁盤滿等問題都不會影響AOF文件的可用性,這點你們能夠放心。

AOF方式的另外一個好處,咱們經過一個「場景再現」來講明。某同窗在操做redis時,不當心執行了FLUSHALL,致使redis內存中的數據所有被清空了,這是很悲劇的事情。不過這也不是世界末日,只要redis配置了AOF持久化方式,且AOF文件尚未被重寫(rewrite),咱們就能夠用最快的速度暫停redis並編輯AOF文件,將最後一行的FLUSHALL命令刪除,而後重啓redis,就能夠恢復redis的全部數據到FLUSHALL以前的狀態了。是否是很神奇,這就是AOF持久化方式的好處之一。可是若是AOF文件已經被重寫了,那就沒法經過這種方法來恢復數據了。

雖然優勢多多,但AOF方式也一樣存在缺陷,好比在一樣數據規模的狀況下,AOF文件要比RDB文件的體積大。並且,AOF方式的恢復速度也要慢於RDB方式。

若是你直接執行BGREWRITEAOF命令,那麼redis會生成一個全新的AOF文件,其中便包括了能夠恢復現有數據的最少的命令集。

若是運氣比較差,AOF文件出現了被寫壞的狀況,也沒必要過度擔心,redis並不會貿然加載這個有問題的AOF文件,而是報錯退出。這時能夠經過如下步驟來修復出錯的文件:

1.備份被寫壞的AOF文件
2.運行redis-check-aof –fix進行修復
3.用diff -u來看下兩個文件的差別,確認問題點
4.重啓redis,加載修復後的AOF文件

【聊聊redis持久化 – AOF重寫】

AOF重寫的內部運行原理,咱們有必要了解一下。

在重寫即將開始之際,redis會建立(fork)一個「重寫子進程」,這個子進程會首先讀取現有的AOF文件,並將其包含的指令進行分析壓縮並寫入到一個臨時文件中。

與此同時,主工做進程會將新接收到的寫指令一邊累積到內存緩衝區中,一邊繼續寫入到原有的AOF文件中,這樣作是保證原有的AOF文件的可用性,避免在重寫過程當中出現意外。

當「重寫子進程」完成重寫工做後,它會給父進程發一個信號,父進程收到信號後就會將內存中緩存的寫指令追加到新AOF文件中。

當追加結束後,redis就會用新AOF文件來代替舊AOF文件,以後再有新的寫指令,就都會追加到新的AOF文件中了。

【聊聊主從 – 用法】

像MySQL同樣,redis是支持主從同步的,並且也支持一主多從以及多級從結構。

主從結構,一是爲了純粹的冗餘備份,二是爲了提高讀性能,好比很消耗性能的SORT就能夠由從服務器來承擔。

redis的主從同步是異步進行的,這意味着主從同步不會影響主邏輯,也不會下降redis的處理性能。

主從架構中,能夠考慮關閉主服務器的數據持久化功能,只讓從服務器進行持久化,這樣能夠提升主服務器的處理性能。

在主從架構中,從服務器一般被設置爲只讀模式,這樣能夠避免從服務器的數據被誤修改。可是從服務器仍然能夠接受CONFIG等指令,因此仍是不該該將從服務器直接暴露到不安全的網絡環境中。若是必須如此,那能夠考慮給重要指令進行重命名,來避免命令被外人誤執行。

Redis爲何這麼快

一、徹底基於內存,絕大部分請求是純粹的內存操做,很是快速。數據存在內存中,相似於HashMap,HashMap的優點就是查找和操做的時間複雜度都是O(1);

二、數據結構簡單,對數據操做也簡單,Redis中的數據結構是專門進行設計的;

三、採用單線程,避免了沒必要要的上下文切換和競爭條件,也不存在多進程或者多線程致使的切換而消耗 CPU,不用去考慮各類鎖的問題,不存在加鎖釋放鎖操做,沒有由於可能出現死鎖而致使的性能消耗;

四、使用多路I/O複用模型,非阻塞IO;

五、使用底層模型不一樣,它們之間底層實現方式以及與客戶端之間通訊的應用協議不同,Redis直接本身構建了VM 機制 ,由於通常的系統調用系統函數的話,會浪費必定的時間去移動和請求;

以上幾點都比較好理解,下邊咱們針對多路 I/O 複用模型進行簡單的探討:

(1)多路 I/O 複用模型

多路I/O複用模型是利用 select、poll、epoll 能夠同時監察多個流的 I/O 事件的能力,在空閒的時候,會把當前線程阻塞掉,當有一個或多個流有 I/O 事件時,就從阻塞態中喚醒,因而程序就會輪詢一遍全部的流(epoll 是隻輪詢那些真正發出了事件的流),而且只依次順序的處理就緒的流,這種作法就避免了大量的無用操做。

這裏「多路」指的是多個網絡鏈接,「複用」指的是複用同一個線程。採用多路 I/O 複用技術可讓單個線程高效的處理多個鏈接請求(儘可能減小網絡 IO 的時間消耗),且 Redis 在內存中操做數據的速度很是快,也就是說內存內的操做不會成爲影響Redis性能的瓶頸,主要由以上幾點造就了 Redis 具備很高的吞吐量。

爲何Redis是單線程的

咱們首先要明白,上邊的種種分析,都是爲了營造一個Redis很快的氛圍!官方FAQ表示,由於Redis是基於內存的操做,CPU不是Redis的瓶頸,Redis的瓶頸最有多是機器內存的大小或者網絡帶寬。既然單線程容易實現,並且CPU不會成爲瓶頸,那就瓜熟蒂落地採用單線程的方案了(畢竟採用多線程會有不少麻煩!)。

 

能夠參考:

看到這裏,你可能會氣哭!本覺得會有什麼重大的技術要點才使得Redis使用單線程就能夠這麼快,沒想到就是一句官方看似糊弄咱們的回答!可是,咱們已經能夠很清楚的解釋了爲何Redis這麼快,而且正是因爲在單線程模式的狀況下已經很快了,就沒有必要在使用多線程了!

可是,咱們使用單線程的方式是沒法發揮多核CPU 性能,不過咱們能夠經過在單機開多個Redis 實例來完善!

擴展

如下也是你應該知道的幾種模型,祝你的面試一臂之力!

一、單進程多線程模型:MySQL、Memcached、Oracle(Windows版本);

二、多進程模型:Oracle(Linux版本);

三、Nginx有兩類進程,一類稱爲Master進程(至關於管理進程),另外一類稱爲Worker進程(實際工做進程)。啓動方式有兩種:

(1)單進程啓動:此時系統中僅有一個進程,該進程既充當Master進程的角色,也充當Worker進程的角色。

(2)多進程啓動:此時系統有且僅有一個Master進程,至少有一個Worker進程工做。

(3)Master進程主要進行一些全局性的初始化工做和管理Worker的工做;事件處理是在Worker中進行的。

相關文章
相關標籤/搜索