這篇文章總結了常用的redis基礎知識，希望初學者能夠從中受益。

 

一 redis數(shù)據(jù)類型
redis支持5種類型的數(shù)據(jù)類型，它描述如下的:
1. 字符串
Redis字符串是字節(jié)序列。Redis字符串是二進制安全的，這意味著他們有一個已知的長度沒有任何特殊字符終止，所以你可以存儲任何東西，512兆為上限。
2. 哈希
Redis的哈希是鍵值對的集合。 Redis的哈希值是字符串字段和字符串值之間的映射，因此它們被用來表示對象.
3. 列表
Redis的列表是簡單的字符串列表，排序插入順序。您可以添加元素到Redis的列表的頭部或尾部。
列表的最大長度為 232 - 1 元素（4294967295，每個列表中可容納超過4十億的元素）。
4. 集合
Redis的集合是字符串的無序集合。在Redis您可以添加，刪除和測試文件是否存在，在成員O（1）的時間復雜度。
集合中的元素最大數(shù)量為 232 - 1 （4294967295，可容納超過4十億元素）。
5. 有序集合
Redis的有序集合類似于Redis的集合，字符串不重復的集合。不同的是，一個有序集合的每個成員用分數(shù)，以便采取有序set命令，從最小的到最大的成員分數(shù)有關。雖然成員具有唯一性，但分數(shù)可能會重復。

二 Redis 文件說明

 

$ find . -type f -executable

 

./redis-benchmark // 用于進行redis性能測試的工具

 

./redis-check-dump // 用于修復出問題的dump.rdb文件

./redis-cli // redis的客戶端

./redis-server // redis的服務端

./redis-check-aof // 用于修復出問題的AOF文件

./redis-sentinel // 用于集群管理

 

三 Redis 管理

服務啟動：./redis-server ../redis.conf 端口默認為6379

使用客戶端：./redis-cli

通過客戶端來關閉redis服務端 127.0.0.1:6379> shutdown

 一些注意:

1. key不要太長，盡量不要超過1024字節(jié)，這不僅消耗內存，而且會降低查找的效率；
2. key也不要太短，太短的話，key的可讀性會降低；
3. 在一個項目中，key最好使用統(tǒng)一的命名模式，例如user:10000:passwd。
4. 字符串類型的用法就是這么簡單，因為是二進制安全的，所以你完全可以把一個圖片文件的內容作為字符串來存儲。

 

四 redis 持久化

 Redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Append Only File）。

RDB，簡而言之，就是在不同的時間點，將redis存儲的數(shù)據(jù)生成快照并存儲到磁盤等介質上；

AOF，則是換了一個角度來實現(xiàn)持久化，那就是將redis執(zhí)行過的所有寫指令記錄下來.

在下次redis重新啟動時，只要把這些寫指令從前到后再重復執(zhí)行一遍，就可以實現(xiàn)數(shù)據(jù)恢復了。

其實RDB和AOF兩種方式也可以同時使用，在這種情況下，如果redis重啟的話，則會優(yōu)先采用AOF方式來進行數(shù)據(jù)恢復，這是因為AOF方式的數(shù)據(jù)恢復完整度更高。

如果你沒有數(shù)據(jù)持久化的需求，也完全可以關閉RDB和AOF方式，這樣的話，redis將變成一個純內存數(shù)據(jù)庫，就像memcache一樣。

兩種方式是可以同時使用的。

五 redis持久化 – RDB

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

對于RDB方式，redis會單獨創(chuàng)建（fork）一個子進程來進行持久化，而主進程是不會進行任何IO操作的，這樣就確保了redis極高的性能。如果需要進行大規(guī)模數(shù)據(jù)的恢復，且對于數(shù)據(jù)恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

 

六 Redis持久化 - AOF

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

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

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

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

AOF文件會變得越來越大，為此，redis提供了AOF文件重寫（rewrite）機制，即當AOF文件的大小超過所設定的閾值時，redis就會啟動AOF文件的內容壓縮，只保留可以恢復數(shù)據(jù)的最小指令集。

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

AOF的一個好處場景再現(xiàn)，如果有人不小心清了數(shù)據(jù)庫。在AOF文件還沒沒被重寫的情況下， 可以通過停掉Redis修改AOF文件，去掉誤操作的語句。重啟Redis恢復數(shù)據(jù)。

如果出現(xiàn)AOF文件被寫壞的情況?？砂慈缦虏襟E修復：

  a.備份被寫壞的AOF文件
b.運行redis-check-aof –fix進行修復
c.用diff -u來看下兩個文件的差異，確認問題點
d.重啟redis，加載修復后的AOF文件

 

七 Redis 主從同步

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

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

在主從架構中，從服務器通常被設置為只讀模式，這樣可以避免從服務器的數(shù)據(jù)被誤修改。

但是從服務器仍然可以接受CONFIG等指令，所以還是不應該將從服務器直接暴露到不安全的網(wǎng)絡環(huán)境中。

如果必須如此，那可以考慮給重要指令進行重命名，來避免命令被外人誤執(zhí)行。

重命名指定可以參考另一篇blog

 

八 Redis 同步

從服務器會向主服務器發(fā)出SYNC指令，當主服務器接到此命令后，就會調用BGSAVE指令來創(chuàng)建一個子進程專門進行數(shù)據(jù)持久化工作，也就是將主服務器的數(shù)據(jù)寫入RDB文件中。

在數(shù)據(jù)持久化期間，主服務器將執(zhí)行的寫指令都緩存在內存中。

在BGSAVE指令執(zhí)行完成后，主服務器會將持久化好的RDB文件發(fā)送給從服務器，從服務器接到此文件后會將其存儲到磁盤上，然后再將其讀取到內存中。

這個動作完成后，主服務器會將這段時間緩存的寫指令再以redis協(xié)議的格式發(fā)送給從服務器。

 

九 redis 事務

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

四個redis指令，即MULTI、EXEC、DISCARD、WATCH。這四個指令構成了redis事務處理的基礎。

MULTI用來組裝一個事務；

EXEC用來執(zhí)行一個事務；

DISCARD用來取消一個事務；

WATCH用來監(jiān)視一些key，一旦這些key在事務執(zhí)行之前被改變，則取消事務的執(zhí)行。

例子：

redis> MULTI //標記事務開始

OK

redis> INCR user_id //多條命令按順序入隊

QUEUED

redis> INCR user_id

QUEUED

redis> INCR user_id

QUEUED

redis> PING

QUEUED

redis> EXEC //執(zhí)行

1) (integer) 1

2) (integer) 2

3) (integer) 3

4) PONGQUEUED的字樣，這表示我們在用MULTI組裝事務時，每一個命令都會進入到內存隊列中緩存起來，如果出現(xiàn)QUEUED則表示我們這個命令成功插入了緩存隊列，在將來執(zhí)行EXEC時，這些被QUEUED的命令都會被組裝成一個事務來執(zhí)行.

對于事務的執(zhí)行來說，如果redis開啟了AOF持久化的話，那么一旦事務被成功執(zhí)行，事務中的命令就會通過write命令一次性寫到磁盤中去。

如果在向磁盤中寫的過程中恰好出現(xiàn)斷電、硬件故障等問題，那么就可能出現(xiàn)只有部分命令進行了AOF持久化，這時AOF文件就會出現(xiàn)不完整的情況。這時，我們可以使用redis-check-aof工具來修復這一問題，這個工具會將AOF文件中不完整的信息移除，確保AOF文件完整可用。

兩類錯誤：

調用EXEC之前的錯誤。

有可能是由于語法有誤導致的，也可能時由于內存不足導致的。只要出現(xiàn)某個命令無法成功寫入緩沖隊列的情況，redis都會進行記錄，在客戶端調用EXEC時，redis會拒絕執(zhí)行這一事務。

調用EXEC之后的錯誤。

Redis則采取了完全不同的策略，即redis不會理睬這些錯誤，而是繼續(xù)向下執(zhí)行事務中的其他命令。這是因為，對于應用層面的錯誤，并不是redis自身需要考慮和處理的問題，所以一個事務中如果某一條命令執(zhí)行失敗，并不會影響接下來的其他命令的執(zhí)行。

WATCH本身的作用是“監(jiān)視key是否被改動過”，而且支持同時監(jiān)視多個key，只要還沒真正觸發(fā)事務，WATCH都會盡職盡責的監(jiān)視，一旦發(fā)現(xiàn)某個key被修改了，在執(zhí)行EXEC時就會返回nil，表示事務無法觸發(fā)。

 

 

 

原文來自：博客園/Carlos.Ahui.Fang