Redis優缺點

時間 2019-11-17

標籤 redis 優缺點欄目 Redis 简体版

原文原文鏈接

REmote DIctionary Server(Redis) 是一個由Salvatore Sanfilippo寫的key-value存儲系統。node

Redis是一個開源的使用ANSI C語言編寫、遵照BSD協議、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。程序員

Redis 與其餘 key - value 緩存產品有如下三個特色：redis

Redis支持數據的持久化，能夠將內存中的數據保持在磁盤中，重啓的時候能夠再次加載進行使用。
Redis不只僅支持簡單的key-value類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
Redis支持數據的備份，即master-slave模式的數據備份。

Redis 優點

性能極高 – Redis能讀的速度是110000次/s,寫的速度是81000次/s 。
豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操做。
原子 – Redis的全部操做都是原子性的，同時Redis還支持對幾個操做全並後的原子性執行。
豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過時等等特性。

Redis與其餘key-value存儲有什麼不一樣？

Redis有着更爲複雜的數據結構而且提供對他們的原子性操做，這是一個不一樣於其餘數據庫的進化路徑。Redis的數據類型都是基於基本數據結構的同時對程序員透明，無需進行額外的抽象。數據庫
Redis運行在內存中可是能夠持久化到磁盤，因此在對不一樣數據集進行高速讀寫時須要權衡內存，應爲數據量不能大於硬件內存。在內存數據庫方面的另外一個優勢是，相比在磁盤上相同的複雜的數據結構，在內存中操做起來很是簡單，這樣Redis能夠作不少內部複雜性很強的事情。同時，在磁盤格式方面他們是緊湊的以追加的方式產生的，由於他們並不須要進行隨機訪問。緩存

redis持久化

RDB

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

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

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

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

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

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文件，而是報錯退出。這時能夠經過如下步驟來修復出錯的文件：

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

AOF重寫

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

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

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

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

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

如何選擇RDB和AOF

對於咱們應該選擇RDB仍是AOF，官方的建議是兩個同時使用。這樣能夠提供更可靠的持久化方案。

主從

用法

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

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

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

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

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

同步原理

從服務器會向主服務器發出SYNC指令，當主服務器接到此命令後，就會調用BGSAVE指令來建立一個子進程專門進行數據持久化工做，也就是將主服務器的數據寫入RDB文件中。在數據持久化期間，主服務器將執行的寫指令都緩存在內存中。

在BGSAVE指令執行完成後，主服務器會將持久化好的RDB文件發送給從服務器，從服務器接到此文件後會將其存儲到磁盤上，而後再將其讀取到內存中。這個動做完成後，主服務器會將這段時間緩存的寫指令再以redis協議的格式發送給從服務器。

另外，要說的一點是，即便有多個從服務器同時發來SYNC指令，主服務器也只會執行一次BGSAVE，而後把持久化好的RDB文件發給多個下游。在redis2.8版本以前，若是從服務器與主服務器因某些緣由斷開鏈接的話，都會進行一次主從之間的全量的數據同步；而在2.8版本以後，redis支持了效率更高的增量同步策略，這大大下降了鏈接斷開的恢復成本。

主服務器會在內存中維護一個緩衝區，緩衝區中存儲着將要發給從服務器的內容。從服務器在與主服務器出現網絡瞬斷以後，從服務器會嘗試再次與主服務器鏈接，一旦鏈接成功，從服務器就會把「但願同步的主服務器ID」和「但願請求的數據的偏移位置（replication offset）」發送出去。主服務器接收到這樣的同步請求後，首先會驗證主服務器ID是否和本身的ID匹配，其次會檢查「請求的偏移位置」是否存在於本身的緩衝區中，若是二者都知足的話，主服務器就會向從服務器發送增量內容。

增量同步功能，須要服務器端支持全新的PSYNC指令。這個指令，只有在redis-2.8以後才具備。