REmote DIctionary Server(Redis) 是一個由Salvatore Sanfilippo寫的key-value存儲系統。 Redis是一個開源的使用ANSI C語言編寫、遵守BSD協議、支持網路、可基於記憶體亦可持久化的日誌型、Key-Value資料庫，並提供多種語言的API。 ...
REmote DIctionary Server(Redis) 是一個由Salvatore Sanfilippo寫的key-value存儲系統。
Redis是一個開源的使用ANSI C語言編寫、遵守BSD協議、支持網路、可基於記憶體亦可持久化的日誌型、Key-Value資料庫，並提供多種語言的API。
Redis 與其他 key - value 緩存產品有以下三個特點：
- 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。
【聊聊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文件中了。
【聊聊redis持久化 – 如何選擇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之後才具有。
【聊聊redis的事務處理】
眾所周知，事務是指“一個完整的動作，要麼全部執行，要麼什麼也沒有做”。
在聊redis事務處理之前，要先和大家介紹四個redis指令，即MULTI、EXEC、DISCARD、WATCH。這四個指令構成了redis事務處理的基礎。
1.MULTI用來組裝一個事務；
2.EXEC用來執行一個事務；
3.DISCARD用來取消一個事務；
4.WATCH用來監視一些key，一旦這些key在事務執行之前被改變，則取消事務的執行。
常用命令
redis的常用命令主要分為兩個方面、一個是鍵值相關命令、一個是伺服器相關命令
1、鍵值相關命令
keys * 取出當前所有的key
exists name 查看n是否有name這個key
del name 刪除key name
expire confirm 100 設置confirm這個key100秒過期
ttl confirm 獲取confirm 這個key的有效時長
select 0 選擇到0資料庫 redis預設的資料庫是0~15一共16個資料庫
move confirm 1 將當前資料庫中的key移動到其他的資料庫中，這裡就是把confire這個key從當前資料庫中移動到1中
persist confirm 移除confirm這個key的過期時間
randomkey 隨機返回資料庫裡面的一個key
rename key2 key3 重命名key2 為key3
type key2 返回key的數據類型
2、伺服器相關命令
ping PONG返迴響應是否連接成功
echo 在命令行列印一些內容
select 0~15 編號的資料庫
quit /exit 退出客戶端
dbsize 返回當前資料庫中所有key的數量
info 返回redis的相關信息
config get dir/* 實時傳儲收到的請求
flushdb 刪除當前選擇資料庫中的所有key
flushall 刪除所有資料庫中的資料庫
