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

Redis是一個開源的使用ANSI C語言編寫、遵守BSD協(xié)議、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API。

Redis 與其他 key - value 緩存產(chǎn)品有以下三個特點：

• Redis支持數(shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時候可以再次加載進行使用。
• Redis不僅僅支持簡單的key-value類型的數(shù)據(jù)，同時還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲。
• Redis支持數(shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。

  Redis 優(yōu)勢

  • 性能極高?– Redis能讀的速度是110000次/s,寫的速度是81000次/s 。
  • 豐富的數(shù)據(jù)類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數(shù)據(jù)類型操作。
  • 原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全并后的原子性執(zhí)行。
  • 豐富的特性?– Redis還支持 publish/subscribe, 通知, key 過期等等特性。

  ---

  Redis與其他key-value存儲有什么不同？

  • Redis有著更為復(fù)雜的數(shù)據(jù)結(jié)構(gòu)并且提供對他們的原子性操作，這是一個不同于其他數(shù)據(jù)庫的進化路徑。Redis的數(shù)據(jù)類型都是基于基本數(shù)據(jù)結(jié)構(gòu)的同時對程序員透明，無需進行額外的抽象。

  • Redis運行在內(nèi)存中但是可以持久化到磁盤，所以在對不同數(shù)據(jù)集進行高速讀寫時需要權(quán)衡內(nèi)存，應(yīng)為數(shù)據(jù)量不能大于硬件內(nèi)存。在內(nèi)存數(shù)據(jù)庫方面的另一個優(yōu)點是，相比在磁盤上相同的復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，在內(nèi)存中操作起來非常簡單，這樣Redis可以做很多內(nèi)部復(fù)雜性很強的事情。同時，在磁盤格式方面他們是緊湊的以追加的方式產(chǎn)生的，因為他們并不需要進行隨機訪問。?
    

【聊聊redis持久化 – RDB】

RDB方式，是將redis某一時刻的數(shù)據(jù)持久化到磁盤中，是一種快照式的持久化方法。

redis在進行數(shù)據(jù)持久化的過程中，會先將數(shù)據(jù)寫入到一個臨時文件中，待持久化過程都結(jié)束了，才會用這個臨時文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時來進行備份，因為快照文件總是完整可用的。

對于RDB方式，redis會單獨創(chuàng)建（fork）一個子進程來進行持久化，而主進程是不會進行任何IO操作的，這樣就確保了redis極高的性能。

如果需要進行大規(guī)模數(shù)據(jù)的恢復(fù)，且對于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

雖然RDB有不少優(yōu)點，但它的缺點也是不容忽視的。如果你對數(shù)據(jù)的完整性非常敏感，那么RDB方式就不太適合你，因為即使你每5分鐘都持久化一次，當redis故障時，仍然會有近5分鐘的數(shù)據(jù)丟失。所以，redis還提供了另一種持久化方式，那就是AOF。

【聊聊redis持久化 – AOF】

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

如前面介紹的，AOF方式是將執(zhí)行過的寫指令記錄下來，在數(shù)據(jù)恢復(fù)時按照從前到后的順序再將指令都執(zhí)行一遍，就這么簡單。

我們通過配置redis.conf中的appendonly yes就可以打開AOF功能。如果有寫操作（如SET等），redis就會被追加到AOF文件的末尾。

默認的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），因為在這種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會丟失最近1秒鐘的數(shù)據(jù)。

如果在追加日志時，恰好遇到磁盤空間滿、inode滿或斷電等情況導(dǎo)致日志寫入不完整，也沒有關(guān)系，redis提供了redis-check-aof工具，可以用來進行日志修復(fù)。

因為采用了追加方式，如果不做任何處理的話，AOF文件會變得越來越大，為此，redis提供了AOF文件重寫（rewrite）機制，即當AOF文件的大小超過所設(shè)定的閾值時，redis就會啟動AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。舉個例子或許更形象，假如我們調(diào)用了100次INCR指令，在AOF文件中就要存儲100條指令，但這明顯是很低效的，完全可以把這100條指令合并成一條SET指令，這就是重寫機制的原理。

在進行AOF重寫時，仍然是采用先寫臨時文件，全部完成后再替換的流程，所以斷電、磁盤滿等問題都不會影響AOF文件的可用性，這點大家可以放心。

AOF方式的另一個好處，我們通過一個“場景再現(xiàn)”來說明。某同學(xué)在操作redis時，不小心執(zhí)行了FLUSHALL，導(dǎo)致redis內(nèi)存中的數(shù)據(jù)全部被清空了，這是很悲劇的事情。不過這也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件還沒有被重寫（rewrite），我們就可以用最快的速度暫停redis并編輯AOF文件，將最后一行的FLUSHALL命令刪除，然后重啟redis，就可以恢復(fù)redis的所有數(shù)據(jù)到FLUSHALL之前的狀態(tài)了。是不是很神奇，這就是AOF持久化方式的好處之一。但是如果AOF文件已經(jīng)被重寫了，那就無法通過這種方法來恢復(fù)數(shù)據(jù)了。

雖然優(yōu)點多多，但AOF方式也同樣存在缺陷，比如在同樣數(shù)據(jù)規(guī)模的情況下，AOF文件要比RDB文件的體積大。而且，AOF方式的恢復(fù)速度也要慢于RDB方式。

如果你直接執(zhí)行BGREWRITEAOF命令，那么redis會生成一個全新的AOF文件，其中便包括了可以恢復(fù)現(xiàn)有數(shù)據(jù)的最少的命令集。

如果運氣比較差，AOF文件出現(xiàn)了被寫壞的情況，也不必過分擔(dān)憂，redis并不會貿(mào)然加載這個有問題的AOF文件，而是報錯退出。這時可以通過以下步驟來修復(fù)出錯的文件：

1.備份被寫壞的AOF文件
2.運行redis-check-aof –fix進行修復(fù)
3.用diff -u來看下兩個文件的差異，確認問題點
4.重啟redis，加載修復(fù)后的AOF文件

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

AOF重寫的內(nèi)部運行原理，我們有必要了解一下。

在重寫即將開始之際，redis會創(chuàng)建（fork）一個“重寫子進程”，這個子進程會首先讀取現(xiàn)有的AOF文件，并將其包含的指令進行分析壓縮并寫入到一個臨時文件中。

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

當“重寫子進程”完成重寫工作后，它會給父進程發(fā)一個信號，父進程收到信號后就會將內(nèi)存中緩存的寫指令追加到新AOF文件中。

當追加結(jié)束后，redis就會用新AOF文件來代替舊AOF文件，之后再有新的寫指令，就都會追加到新的AOF文件中了。

【聊聊redis持久化 – 如何選擇RDB和AOF】

對于我們應(yīng)該選擇RDB還是AOF，官方的建議是兩個同時使用。這樣可以提供更可靠的持久化方案。

【聊聊主從 – 用法】

像MySQL一樣，redis是支持主從同步的，而且也支持一主多從以及多級從結(jié)構(gòu)。

主從結(jié)構(gòu)，一是為了純粹的冗余備份，二是為了提升讀性能，比如很消耗性能的SORT就可以由從服務(wù)器來承擔(dān)。

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

主從架構(gòu)中，可以考慮關(guān)閉主服務(wù)器的數(shù)據(jù)持久化功能，只讓從服務(wù)器進行持久化，這樣可以提高主服務(wù)器的處理性能。

在主從架構(gòu)中，從服務(wù)器通常被設(shè)置為只讀模式，這樣可以避免從服務(wù)器的數(shù)據(jù)被誤修改。但是從服務(wù)器仍然可以接受CONFIG等指令，所以還是不應(yīng)該將從服務(wù)器直接暴露到不安全的網(wǎng)絡(luò)環(huán)境中。如果必須如此，那可以考慮給重要指令進行重命名，來避免命令被外人誤執(zhí)行。

【聊聊主從 – 同步原理】

從服務(wù)器會向主服務(wù)器發(fā)出SYNC指令，當主服務(wù)器接到此命令后，就會調(diào)用BGSAVE指令來創(chuàng)建一個子進程專門進行數(shù)據(jù)持久化工作，也就是將主服務(wù)器的數(shù)據(jù)寫入RDB文件中。在數(shù)據(jù)持久化期間，主服務(wù)器將執(zhí)行的寫指令都緩存在內(nèi)存中。

在BGSAVE指令執(zhí)行完成后，主服務(wù)器會將持久化好的RDB文件發(fā)送給從服務(wù)器，從服務(wù)器接到此文件后會將其存儲到磁盤上，然后再將其讀取到內(nèi)存中。這個動作完成后，主服務(wù)器會將這段時間緩存的寫指令再以redis協(xié)議的格式發(fā)送給從服務(wù)器。

另外，要說的一點是，即使有多個從服務(wù)器同時發(fā)來SYNC指令，主服務(wù)器也只會執(zhí)行一次BGSAVE，然后把持久化好的RDB文件發(fā)給多個下游。在redis2.8版本之前，如果從服務(wù)器與主服務(wù)器因某些原因斷開連接的話，都會進行一次主從之間的全量的數(shù)據(jù)同步；而在2.8版本之后，redis支持了效率更高的增量同步策略，這大大降低了連接斷開的恢復(fù)成本。

主服務(wù)器會在內(nèi)存中維護一個緩沖區(qū)，緩沖區(qū)中存儲著將要發(fā)給從服務(wù)器的內(nèi)容。從服務(wù)器在與主服務(wù)器出現(xiàn)網(wǎng)絡(luò)瞬斷之后，從服務(wù)器會嘗試再次與主服務(wù)器連接，一旦連接成功，從服務(wù)器就會把“希望同步的主服務(wù)器ID”和“希望請求的數(shù)據(jù)的偏移位置（replication offset）”發(fā)送出去。主服務(wù)器接收到這樣的同步請求后，首先會驗證主服務(wù)器ID是否和自己的ID匹配，其次會檢查“請求的偏移位置”是否存在于自己的緩沖區(qū)中，如果兩者都滿足的話，主服務(wù)器就會向從服務(wù)器發(fā)送增量內(nèi)容。

增量同步功能，需要服務(wù)器端支持全新的PSYNC指令。這個指令，只有在redis-2.8之后才具有。

【聊聊redis的事務(wù)處理】

眾所周知，事務(wù)是指“一個完整的動作，要么全部執(zhí)行，要么什么也沒有做”。

在聊redis事務(wù)處理之前，要先和大家介紹四個redis指令，即MULTI、EXEC、DISCARD、WATCH。這四個指令構(gòu)成了redis事務(wù)處理的基礎(chǔ)。

1.MULTI用來組裝一個事務(wù)；
2.EXEC用來執(zhí)行一個事務(wù)；
3.DISCARD用來取消一個事務(wù)；
4.WATCH用來監(jiān)視一些key，一旦這些key在事務(wù)執(zhí)行之前被改變，則取消事務(wù)的執(zhí)行。

常用命令

redis的常用命令主要分為兩個方面、一個是鍵值相關(guān)命令、一個是服務(wù)器相關(guān)命令

1、鍵值相關(guān)命令

??????keys * 取出當前所有的key

??????exists name 查看n是否有name這個key

??????del name 刪除key name

????? expire confirm 100 設(shè)置confirm這個key100秒過期

??????ttl confirm 獲取confirm 這個key的有效時長

????? select 0 選擇到0數(shù)據(jù)庫 redis默認的數(shù)據(jù)庫是0~15一共16個數(shù)據(jù)庫

??????move confirm 1 將當前數(shù)據(jù)庫中的key移動到其他的數(shù)據(jù)庫中，這里就是把confire這個key從當前數(shù)據(jù)庫中移動到1中

????? persist confirm 移除confirm這個key的過期時間

????? randomkey 隨機返回數(shù)據(jù)庫里面的一個key

????? rename key2 key3 重命名key2 為key3

????? type key2 返回key的數(shù)據(jù)類型

2、服務(wù)器相關(guān)命令

????? ping PONG返回響應(yīng)是否連接成功

????? echo 在命令行打印一些內(nèi)容

????? select 0~15 編號的數(shù)據(jù)庫

??????quit? /exit 退出客戶端

????? dbsize 返回當前數(shù)據(jù)庫中所有key的數(shù)量

????? info 返回redis的相關(guān)信息

????? config get dir/* 實時傳儲收到的請求

??????flushdb 刪除當前選擇數(shù)據(jù)庫中的所有key

????? flushall 刪除所有數(shù)據(jù)庫中的數(shù)據(jù)庫

轉(zhuǎn)載于:https://www.cnblogs.com/canfengfeixue/p/8042913.html

總結(jié)

以上是生活随笔為你收集整理的Redis 优缺点的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。