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。
它通常被稱為數(shù)據(jù)結(jié)構(gòu)服務(wù)器，因為值（value）可以是：
- 字符串(String)
- 哈希(Map),
- 列表(list)
- 集合(sets)
- 有序集合(sorted sets)等類型。
Redis 優(yōu)勢
- 性能極高 – Redis能讀的速度是110000次/s,寫的速度是81000次/s 。
- 豐富的數(shù)據(jù)類型 – Redis支持二進(jìn)制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數(shù)據(jù)類型操作。
- 原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全并后的原子性執(zhí)行。
- 豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。
Redis的兩種持久化 RDB與AOF
RDB，簡而言之，就是在不同的時間點，將redis存儲的數(shù)據(jù)生成快照并存儲到磁盤等介質(zhì)上；
AOF，則是換了一個角度來實現(xiàn)持久化，那就是將redis執(zhí)行過的所有寫指令記錄下來，在下次redis重新啟動時，只要把這些寫指令從前到后再重復(fù)執(zhí)行一遍，就可以實現(xiàn)數(shù)據(jù)恢復(fù)了。
其實RDB和AOF兩種方式也可以同時使用，在這種情況下，如果redis重啟的話，則會優(yōu)先采用AOF方式來進(jìn)行數(shù)據(jù)恢復(fù)，這是因為AOF方式的數(shù)據(jù)恢復(fù)完整度更高。
如果你沒有數(shù)據(jù)持久化的需求，也完全可以關(guān)閉RDB和AOF方式，這樣的話，redis將變成一個純內(nèi)存數(shù)據(jù)庫，就像memcache一樣。
RDB
RDB方式，是將redis某一時刻的數(shù)據(jù)持久化到磁盤中，是一種快照式的持久化方法。
redis在進(jìn)行數(shù)據(jù)持久化的過程中，會先將數(shù)據(jù)寫入到一個臨時文件中，待持久化過程都結(jié)束了，才會用這個臨時文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時來進(jìn)行備份，因為快照文件總是完整可用的。
對于RDB方式，redis會單獨創(chuàng)建（fork）一個子進(jìn)程來進(jìn)行持久化，而主進(jìn)程是不會進(jìn)行任何IO操作的，這樣就確保了redis極高的性能。
如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù)，且對于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
雖然RDB有不少優(yōu)點，但它的缺點也是不容忽視的。如果你對數(shù)據(jù)的完整性非常敏感，那么RDB方式就不太適合你，因為即使你每5分鐘都持久化一次，當(dāng)redis故障時，仍然會有近5分鐘的數(shù)據(jù)丟失。所以，redis還提供了另一種持久化方式，那就是AOF。
AOF
AOF，英文是Append Only File，即只允許追加不允許改寫的文件。
如前面介紹的，AOF方式是將執(zhí)行過的寫指令記錄下來，在數(shù)據(jù)恢復(fù)時按照從前到后的順序再將指令都執(zhí)行一遍，就這么簡單。
我們通過配置redis.conf中的appendonly yes就可以打開AOF功能。如果有寫操作（如SET等），redis就會被追加到AOF文件的末尾。
默認(rèn)的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），因為在這種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會丟失最近1秒鐘的數(shù)據(jù)。
如果在追加日志時，恰好遇到磁盤空間滿、inode滿或斷電等情況導(dǎo)致日志寫入不完整，也沒有關(guān)系，redis提供了redis-check-aof工具，可以用來進(jìn)行日志修復(fù)。
因為采用了追加方式，如果不做任何處理的話，AOF文件會變得越來越大，為此，redis提供了AOF文件重寫（rewrite）機(jī)制，即當(dāng)AOF文件的大小超過所設(shè)定的閾值時，redis就會啟動AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。舉個例子或許更形象，假如我們調(diào)用了100次INCR指令，在AOF文件中就要存儲100條指令，但這明顯是很低效的，完全可以把這100條指令合并成一條SET指令，這就是重寫機(jī)制的原理。
在進(jìn)行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進(jìn)行修復(fù)
3.用diff -u來看下兩個文件的差異，確認(rèn)問題點
4.重啟redis，加載修復(fù)后的AOF文件
AOF重寫
AOF重寫的內(nèi)部運行原理，我們有必要了解一下。
在重寫即將開始之際，redis會創(chuàng)建（fork）一個“重寫子進(jìn)程”，這個子進(jìn)程會首先讀取現(xiàn)有的AOF文件，并將其包含的指令進(jìn)行分析壓縮并寫入到一個臨時文件中。
與此同時，主工作進(jìn)程會將新接收到的寫指令一邊累積到內(nèi)存緩沖區(qū)中，一邊繼續(xù)寫入到原有的AOF文件中，這樣做是保證原有的AOF文件的可用性，避免在重寫過程中出現(xiàn)意外。
當(dāng)“重寫子進(jìn)程”完成重寫工作后，它會給父進(jìn)程發(fā)一個信號，父進(jìn)程收到信號后就會將內(nèi)存中緩存的寫指令追加到新AOF文件中。
當(dāng)追加結(jié)束后，redis就會用新AOF文件來代替舊AOF文件，之后再有新的寫指令，就都會追加到新的AOF文件中了。
req
Redis 使用方式
- 連接遠(yuǎn)程主機(jī) -h主機(jī)名 -p 端口 -a 密碼
redis-cli.exe -h 192.168.1.118 -p 6379 -a passwd
- 配置密碼連接
在/etc/redis/redis.conf 中找到 #requirepass foobared
修改為 requirepass 密碼
這樣子如果連接時候沒有加-a可以連接但是無法查看數(shù)據(jù)
- 配置遠(yuǎn)程連接
在/etc/redis/redis.conf 中找到 bind 127.0.0.1
改為bind 外網(wǎng)（局域網(wǎng)）地址
- 停止進(jìn)程
ps -ef |grep redis 獲取進(jìn)程號
然后sudo kill id
- 啟動服務(wù)
sudo redis-server /etc/redis/redis.conf
- 打開aof持久化
打開redis的配置文件(/etc/redis/redis.conf)。
找到appendonly。默認(rèn)是appendonly no。改成appendonly yes。
