特點

• 內存+磁盤的持久化保存
• 具有非常豐富的數據類型，尤其擅長數組類數據的高速度處理
• 數據快照
• 自帶的主從復制
• 豐富的數據類型
• 字符串
• 鏈表
• 集合
• 有序集合
• 散列表

  適用場景

• 時間線應用

  得益於鏈表的高速實現

• 對數組形式數據頻繁添加和刪除

  不限於常規數組，包括鏈表，有向集合

  安裝

  centos 上 : yum install redis

  windows 下載安裝，網上教程很多。

  啟動及配置

  我是用windows 時配置文件中有一項

  # On Windows, daemonize and pidfile are not supported.

  # However, you can run redis as a Windows service, and specify a logfile.

  # The logfile will contain the pid.

  說明在windows中不支撐守護進程程（後臺啟動）的方式啟動，但可以註冊為woindows的後服務程序，因為我沒有這個需求，所以沒有去進一步的折騰。

  常用配置

  

  基本配置說明

  n 參考http://blog.csdn.net/willability/article/details/7676384

  windows啟動

  啟動服務端：打開一個cmd窗口使用

  cd命令切換目錄到redis安裝目錄，運行redis-server.exe啟動redis.

  啟動客戶端：打開另一個cmd窗口使用cd命令切換目錄到redis安裝目錄運行redis-cli.exe -h 127.0.0.1 -p 6379，其中的-h和-p是可以省略的，保持默認。

  退出 quit

  常用命令及操作

  set a 1 a 為鍵，1 為值

  set b [1,2,3,4,5] value為列表。

  setex c 5 3 表示5秒過期時間

  get a 取數

  lpush data foo 向鏈表data 左向

  push一個值foo

  zadd sets 1 abc 向有向集體中增加值 第一個參數是位置，第二個參數是值。

  zadd set 2 bcd

  zrange sets 0 -1 第一個參數表示取數開頭的位置，0就從開始取。，第一個參數是取數結尾的位置，-1表示取到最後

  redis記錄點擊數

  INCR visits:635:totals 自增長visits:635:totals

  INCR visits:635:totals

  get visits:635:totals 得到結果是2.

  查看當前系統所有的數據

  可以使用正則表達式的表達式

  keys *

  keys h*llo

  keys h?llo

  key h[ae]llo

  Redis的主從復制

  一、設置配置文件

  把conf文件復制兩份，一份改名為redis.windows-master.conf，裏面以默認配置就行，另一份改名為redis.windows-service.conf，裏面改兩個地方 ，1 ，port 改為6389（因為默認是6379，已經被master占用，）另一個方是：# slaveof <masterip> <masterport> 在這一行的下邊加一行 slaveof 127.0.0.1 6379 (也就是master服務器的地址和端口 )

  二、啟動

  啟動master redis-server.exe redis.windows-master.conf

  啟動slave redis-server.exe redis.windows-slave.conf

  也就是帶上配置文件啟動，這樣啟動的兩個服務器用的是兩個不同的配置文件

  三、驗證

  連接master redis-cli.exe -h 127.0.0.1 -p 6379

  插入數據rpush data value1

  連接slave redis-cli.exe -h 127.0.0.1 -p 6389

  取數 lrange data 0 -1 也能得到數據 ，說明自動實現了主從復制。

  Redis的持久化

  快照（snapshot）

  設置一個觸發條件，當這個觸發條件滿足時，redis 就往硬盤中寫入數據。觸發時間可以是時間，也可時是修改的數量，甚至是手工觸發條件。所保存的文件一般是以rdo作為後綴（文件類型名）。如果你當前進程關閉或宕機了，當你下一次打開redis時，他們把這個數據重新裝回內存。裝載回存是一次完成的。

  快照原理

  Redis借助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，然後在子進程中循環所有的數據，將數據寫成為RDB文件。

  Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性 rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。

  同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。

  我們可以很明顯的看到，RDB有它的不足，就是一旦數據庫出現問題，那麽我們的RDB文件中保存的數據並不是全新的，從上次RDB文件生成到 Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的，我們也推薦這些業務使用RDB的方式進行持久化，因為開啟RDB的代價並不高。

  優點：

  對相同變量只保存最後一次的最終結果

  缺點：

  快照備份不是實時的，所以可能丟失數據

  運行redis時是一次全部寫入到內存，對IO操作的性能影響很大，

  設置配置文件

• # save ""
• save 900 1 # 900秒內有一次修改就save
• save 300 10 #300秒內有10次修改就save
• save 60 10000 # 60 秒內有10000次修改就save
• rdbcompression yes 表示是否壓縮，默認為yes
• dbfilename dump.rdb 表示備份文件名字
• # Note that you must specify a directory here, not a file name.

  dir ./ 表示日誌文件存放的目錄，註意的是所選的目錄一定要有寫權限

• # requirepass foobared 表示在連接等操作時是否需要口令，默認是關閉的。
• appendonly no 表示是否只使用appendonly，默認是no
• slowlog-log-slower-than 10000 記錄執行時間長於10000毫秒的命令

  動態修改配置參數

• config get * 列出所有配置項
• config set time out 280 動態的把timeout的值設為280 這樣就不用重新啟動

  AOF（Append Only File）僅追加日誌

  記錄全部對數據改寫的命令，如果你當前進程關閉或宕機了，當你下一次打開redis時，redis就會重寫執行這寫日誌文件的命令。

  優點：

  記錄所有數據，所以不會丟失數據。寫入時不是一次性全部寫入，對IO影響較小

  缺點：

  如果同一變量修改多次，那麽會記住所有的修改，這樣就可能執行很多次才能得到最終結果，裝載速度變慢。解決辦法是讓redis在一定條件下合並日誌，這樣就可以把前面無用的日誌過濾掉，但是合並日誌也會消耗大量的性能。

  設置配置文件

  appendonly yes

  特點

• 啟動裝載 AOF優先於RDB

  源碼如下：

  

• RDB性能優於AOF，因為裏面沒有重復
• Redis一次性將數據加載到內存中，一次性預熱

  AOF rewrite

  重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似， 也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日誌還是會寫到原來老的 AOF文件中，同時還會記錄在內存緩沖區中。當重完操作完成後，會將所有緩沖區中的日誌一次性寫入到臨時文件中。然後調用原子性的 rename命令用新的 AOF文件取代老的AOF文件。

  VM （虛擬內存 2.4版之後就已經去掉了）

  在未打開VM的情況下，Redis的數據全部裝入內存，將受限於內存的大小 打開VM後，Redis把全部Key放入內存，熱Value也裝進內存，冷Value放在磁盤的交換文件

  配置

  常見性能問題：

  寫快照產生阻塞

  寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務

  方法是 1、采用主從復制，Master不寫快照，slave去寫

  2、使用bgsave

  AOF引發的問題

  AOF持續寫入，產生阻塞的可能較小

  AOF重寫對性能影響很大，會引發服務暫停響應。但不重寫，AOF太大，影響啟動裝載數據速度

  將no-appendfsync-on-rewrite的配置設為yes可以緩解這個問題，設置為yes表示 rewrite期間對新寫操作不fsync，暫時存在內存中，等rewrite完成後再寫入。最好是不開啟Master的AOF備份功能

  內存瓶頸

  maxmemory <bytes> 設置最大使用內存，當內存達到這個最大值時，redis就會拋棄舊的變量。可以用算法設置拋棄那種變量。

  主從復制阻塞

  Redis主從復制的性能問題，第一次Slave向Master同步的實現是：Slave向Master發出同步請求，Master先dump出rdb 文件，然後將rdb文件全量傳輸給slave，然後Master把緩存的命令轉發給Slave，初次同步完成。第二次以及以後的同步實現是：Master 將變量的快照直接實時依次發送給各個Slave。不管什麽原因導致Slave和Master斷開重連都會重復以上過程。Redis的主從復制是建立在內存 快照的持久化基礎上，只要有Slave就一定會有內存快照發生。雖然Redis宣稱主從復制無阻塞，但由於磁盤io的限制，如果Master快照文件比較 大，那麽dump會耗費比較長的時間，這個過程中Master可能無法響應請求，也就是說服務會中斷，對於關鍵服務，這個後果也是很可怕的。

redis基礎知識