1、性能
1.1 性能測試
測試環境： RHEL 6.3 / HP Gen8 Server/ 2 * Intel Xeon 2.00GHz(6 core) / 64G DDR3 memory / 300G RAID-1 SATA / 1 master(writ AOF), 1 slave(write AOF & RDB)
數據準備： 預加載兩千萬條數據，佔用10G內存。
測試工具：自帶的redis-benchmark，默認只是基於一個很小的數據集進行測試，調整命令行參數如下，就可以開100條線程(默認50)，SET 1千萬次(key在0-1千萬間隨機)，key長21字節，value長256字節的數據。
redis-benchmark -t SET -c 100 -n 10000000 -r 10000000 -d 256
測試結果(QPS)：
（1）SET：4.5萬，
（2）GET：6萬 ，
（3）INCR：6萬，
（4）真實混合場景: 2.5萬SET & 3萬GET
單條客戶端線程時6千TPS，50與100條客戶端線程差別不大，200條時會略多。
Get/Set操作，經過了LAN，延時也只有1毫秒左右，可以反覆放心調用，不用像調用REST接口和訪問數據庫那樣，每多一次外部訪問都心痛。
資源監控:
（1）CPU: 佔了一個處理器的100%，總CPU是4%(因爲總共有2CPU*6核*超線程 = 24個處理器)，可見單線程下單處理器的能力是瓶頸。 AOF rewrite時另一個處理器佔用50-70%。
（2）網卡：15-20 MB/s receive, 3Mb/s send(no slave) or 15-20 MB/s send (with slave) 。當把value長度加到4K時，receive 99MB/s，已經到達千兆網卡的瓶頸，TPS降到2萬。
（3）硬盤：15MB/s(AOF append), 100MB/s(AOF rewrite/AOF load，普通硬盤的瓶頸)
1.2 Redis爲什麼速度快？
（1）純內存操作
數據存放在內存中，內存的響應時間大約是 100納秒 ，這是Redis每秒萬億級別訪問的重要基礎。
（2）單線程操作，避免了頻繁的上下文切換
雖然是採用單線程，但是單線程避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU；雖然作者認爲CPU不是瓶頸，內存與網絡帶寬纔是。但實際測試時並非如此，見上。
（3）採用了非阻塞I/O多路複用機制
多路I/O複用模型是利用 select、poll、epoll 可以同時監察多個流的 I/O 事件的能力，在空閒的時候，會把當前線程阻塞掉，當有一個或多個流有 I/O 事件時，就從阻塞態中喚醒，於是程序就會輪詢一遍所有的流（epoll 是隻輪詢那些真正發出了事件的流），並且只依次順序的處理就緒的流，這種做法就避免了大量的無用操作。這裏“多路”指的是多個網絡連接，“複用”指的是複用同一個線程。加上Redis自身的事件處理模型將epoll中的連接，讀寫，關閉都轉換爲了事件，不在I/O上浪費過多的時間。
（4）純ANSI C編寫。
不依賴第三方類庫，沒有像memcached那樣使用libevent，因爲libevent迎合通用性而造成代碼龐大，所以作者用libevent中兩個文件修改實現了自己的epoll event loop。微軟的兼容Windows補丁也因爲同樣原因被拒了。
快，原因之一是Redis多樣的數據結構，每種結構只做自己愛做的事，當然比數據庫只有Table，MongogoDB只有JSON一種結構快了。
2、I/O複用模型和Reactor 設計模式
詳情請看：使用 libevent 和 libev 提高網絡應用性能——I/O模型演進變化史
Redis內部實現採用epoll+自己實現的簡單的事件框架。 epoll中的讀、寫、關閉、連接都轉化成了事件，然後利用epoll的多路複用特性， 絕不在io上浪費一點時間：
2.1 I/O 多路複用的封裝
I/O 多路複用其實是在單個線程中通過記錄跟蹤每一個sock（I/O流） 的狀態來管理多個I/O流。
因爲 Redis 需要在多個平臺上運行，同時爲了最大化執行的效率與性能，所以會根據編譯平臺的不同選擇不同的 I/O 多路複用函數作爲子模塊，提供給上層統一的接口。
redis的多路複用， 提供了select, epoll, evport, kqueue幾種選擇，在編譯的時候來選擇一種。
select是POSIX提供的， 一般的操作系統都有支撐；
epoll 是LINUX系統內核提供支持的；
evport是Solaris系統內核提供支持的；
kqueue是Mac 系統提供支持的；
#ifdef HAVE_EVPORT
#include "ae_evport.c"
#else
#ifdef HAVE_EPOLL
#include "ae_epoll.c"
#else
#ifdef HAVE_KQUEUE
#include "ae_kqueue.c"
#else
#include "ae_select.c"
#endif
#endif
爲了將所有 IO 複用統一，Redis 爲所有 IO 複用統一了類型名 aeApiState，對於 epoll 而言，類型成員就是調用 epoll_wait所需要的參數
接下來就是一些對epoll接口的封裝了：包括創建 epoll(epoll_create)，註冊事件(epoll_ctl)，刪除事件(epoll_ctl)，阻塞監聽(epoll_wait)等
創建 epoll 就是簡單的爲 aeApiState 申請內存空間，然後將返回的指針保存在事件驅動循環中
註冊事件和刪除事件就是對 epoll_ctl 的封裝，根據操作不同選擇不同的參數
阻塞監聽是對 epoll_wait 的封裝，在返回後將激活的事件保存在事件驅動中
2.2 Reactor 設計模式：事件驅動循環流程
Redis 服務採用 Reactor 的方式來實現文件事件處理器（每一個網絡連接其實都對應一個文件描述符）
當 main 函數初始化工作完成後，就需要進行事件驅動循環，而在循環中，會調用 IO 複用函數進行監聽
在初始化完成後，main 函數調用了 aeMain 函數，傳入的參數就是服務器的事件驅動
Redis 對於時間事件是採用鏈表的形式記錄的，這導致每次尋找最早超時的那個事件都需要遍歷整個鏈表，容易造成性能瓶頸。而 libevent 是採用最小堆記錄時間事件，尋找最早超時事件只需要 O(1) 的複雜度
如上圖，IO多路複用模型使用了Reactor設計模式實現了這一機制。
通過Reactor的方式，可以將用戶線程輪詢IO操作狀態的工作統一交給handle_events事件循環進行處理。
用戶線程註冊事件處理器之後可以繼續執行做其他的工作（異步），而Reactor線程負責調用內核的select/epoll函數檢查socket狀態。當有socket被激活時，則通知相應的用戶線程（或執行用戶線程的回調函數），執行handle_event進行數據讀取、處理的工作。由於select/epoll函數是阻塞的，因此多路IO複用模型也被稱爲異步阻塞IO模型。注意，這裏的所說的阻塞是指select函數執行時線程被阻塞，而不是指socket。一般在使用IO多路複用模型時，socket都是設置爲NONBLOCK的，不過這並不會產生影響，因爲用戶發起IO請求時，數據已經到達了，用戶線程一定不會被阻塞。
redis線程模型：
如圖所示：
簡單來說，就是。我們的redis-client在操作的時候，會產生具有不同事件類型的socket。在服務端，有一段I/0多路複用程序，將其置入隊列之中。然後，IO事件分派器，依次去隊列中取，轉發到不同的事件處理器中。
3、數據結構說明
http://redis.io/topics/data-types
3.1 redis數據類型
3.1.1 Key
（1）key越短越好：Redis是個內存數據庫，Key鍵越短你需要的空間就越少，因此key不能太長，比如1024字節。
舉個例子：在一個32位的Redis服務器上，如果儲存一百萬個鍵，每個值的長度是32-character，那麼在使用6-character長度鍵名時，將會消耗大約96MB的空間，但是如果使用12-character長度的鍵名時，空間消耗則會提升至111MB左右。隨着鍵的增多，15%的額外開銷將產生重大的影響。
（2）key命名要表達清楚意思。建議用”:”分隔域劃分鍵名，用”.”作爲單詞間的連接，如”comment:1234:reply.to”。
使用合適的命名方法會簡化你的數據庫管理，當你通過你的應用程序或者服務做鍵的命名空間時，你就可以在數據遷移、轉換或者刪除時輕鬆的識別。
Redis另一個常見用例是作爲熱數據項作的第二數據存儲，大部分的數據被保存在其他的數據庫中，比如PostgreSQL或MongoDB。在這些用例中，當數據從主存儲移除時，開發者經常會忘記刪除Redis中對應的數據。這種存在跨數據存儲的情況下，通常需要做級聯刪除，這種情況下，可以通過在Redis配置保存特定數據項的所有識別符來實現，從而保證數據在主數據庫被刪除後，系統會調用一個清理程序來刪除所有相關副本和信息。
3.1.2 基本數據類型
（1）String是最簡單的類型，一個key對應一個value，string類型是二進制安全的。Redis的string可以包含任何數據，比如jpg圖片或者序列化的對象(PHP中對象序列化函數serialize)
內部實現，其本質是一個byte數組，字符串的大小被限制在512M以內
struct sdshdr {
long len; //buf數組的長度
long free; //buf數組中剩餘可用字節數
char buf[]; //存儲實際字符串內容
}
所有常用命令的複雜度都是O(1)，普通的Get/Set方法，可以用來做Cache，存Session，爲了簡化架構甚至可以替換掉Memcached。
Incr/IncrBy/IncrByFloat/Decr/DecrBy，可以用來做計數器，做自增序列。key不存在時會創建並貼心的設原值爲0。IncrByFloat專門針對float，沒有對應的decrByFloat版本？用負數啊。
SetNx， 僅當key不存在時才Set。可以用來選舉Master或做分佈式鎖：所有Client不斷嘗試使用SetNx master myName搶注Master，成功的那位不斷使用Expire刷新它的過期時間。如果Master倒掉了key就會失效，剩下的節點又會發生新一輪搶奪。
（2）Hash：
Key-HashMap結構，相比String類型將這整個對象持久化成JSON格式，Hash將對象的各個屬性存入Map裏，可以只讀取/更新對象的某些屬性。這樣有些屬性超長就讓它一邊呆着不動，另外不同的模塊可以只更新自己關心的屬性而不會互相併發覆蓋衝突。
（3）List：
List是一個雙向鏈表，支持雙向的Pop/Push，江湖規矩一般從左端Push，右端Pop——LPush/RPop，而且還有Blocking的版本BLPop/BRPop，客戶端可以阻塞在那直到有消息到來，所有操作都是O(1)的好孩子，可以當Message Queue來用。當多個Client併發阻塞等待，有消息入列時誰先被阻塞誰先被服務。任務隊列系統Resque是其典型應用。
有RPopLPush/ BRPopLPush，彈出來返回給client的同時，把自己又推入另一個list，LLen獲取列表的長度。
（4）Set
Set就是Set，可以將重複的元素隨便放入而Set會自動去重，底層實現也是hash table。
(5)Sorted Set
有序集，元素放入集合時還要提供該元素的分數。
Sorted Set的實現是hash table(element->score, 用於實現ZScore及判斷element是否在集合內)，和skip list(score->element,按score排序)的混合體。 skip list有點像平衡二叉樹那樣，不同範圍的score被分成一層一層，每層是一個按score排序的鏈表。
ZAdd/ZRem是O(log(N))，ZRangeByScore/ZRemRangeByScore是O(log(N)+M)，N是Set大小，M是結果/操作元素的個數。可見，原本可能很大的N被很關鍵的Log了一下，1000萬大小的Set，複雜度也只是幾十不到。當然，如果一次命中很多元素M很大那誰也沒辦法了。
3.1.3 Lua Script
Redis2.6內置的Lua Script支持，可以在Redis的Server端一次過運行大量邏輯，就像存儲過程一樣，避免了海量中間數據在網路上的傳輸。
Lua自稱是在Script語言裏關於快的標準，Redis選擇了它而不是流行的JavaScript。
因爲Redis的單線程架構，整個Script默認是在一個事務裏的。
Script裏涉及的所有Key儘量用變量，從外面傳入，使Redis一開始就知道你要改變哪些key。(but why?)
Eval每次傳輸一整段Script比較費帶寬，可以先用Script Load載入script，返回哈希值。然後用EvalHash執行。因爲就是SHA-1，所以任何時候執行返回的哈希值都是一樣的。
內置的Lua庫裏還很貼心的帶了CJSON，可以處理json字符串。
一段用Redis做Timer的示例代碼，下面的script被定期調用，從以觸發時間爲score的sorted set中取出已到期的Job，放到list中給Client們blocking popup。
— KEYS: [1]job:sleeping, [2]job:ready
— ARGS: [1]currentTime
— Comments: result is the job id
local jobs=redis.call(‘zrangebyscore’, KEYS[1], ‘-inf’, ARGV[1])
local count = table.maxn(jobs)
if count>0 then
— Comments: remove from Sleeping Job sorted set
redis.call(‘zremrangebyscore’, KEYS[1], ‘-inf’, ARGV[1])
— Comments: add to the Ready Job list
— Comments: can optimize to use lpush id1,id2,… for better performance
for i=1,count do
redis.call(‘lpush’, KEYS[2], jobs[i])
end
end
在Redis使用過程中，Lua腳本的支持無疑給開發者提供一個非常友好的開發環境，從而大幅度解放用戶的創造力。如果使用得當，Lua腳本可以給性能和資源消耗帶來非常大的改善。取代將數據傳送給CPU，腳本允許你在最接近數據的地方執行邏輯，從而減少網絡延時和數據的冗餘傳輸。
在Redis中，Lua一個非常經典的用例就是數據過濾或者將數據聚合到應用程序。通過將處理工作流封裝到一個腳本中，你只需要調用它就可以在更短的時間內使用很少的資源來獲取一個更小的答案。
提示：Lua確實非常棒，但是同樣也存在一些問題，比如很難進行錯誤報告和處理。一個明智的方法就是使用Redis的Pub/Sub功能，並且讓腳本通過專用信道來推送日誌消息。然後建立一個訂閱者進程，並進行相應的處理。
3.1.4 使用合適的數據結構
不管是內存使用或者是性能，有的時候數據結構將產生很大的影響，下面是一些可以參考的最佳實踐：
（1） 使用hash取代將數據存儲爲數千（或者數百萬）獨立的字符串。哈希表是非常有效率的，並且可以減少你的內存使用（因爲小Hashes會被編碼成一個非常小的空間）；同時，哈希還更有益於細節抽象和代碼可讀。
（2）合適時候，使用list代替set。如果你不需要使用set特性，List在使用更少內存的情況下可以提供比set更快的速度。
（3）Sorted sets是最昂貴的數據結構，不管是內存消耗還是基本操作的複雜性。如果你只是需要一個查詢記錄的途徑，並不在意排序這樣的屬性，那麼輕建議使用哈希表。
（4）Redis中一個經常被忽視的功能就是bitmaps或者bitsets（V2.2之後）。Bitsets允許你在Redis值上執行多個bit-level操作，比如一些輕量級的分析。
（5）使用bit位級別操作和byte字節級別操作來減少不必要的內存使用
4、數據一致性：事務
用Multi(Start Transaction)、Exec(Commit)、Discard(Rollback)實現。 在事務提交前，不會執行任何指令，只會把它們存到一個隊列裏，不影響其他客戶端的操作。在事務提交時，批量執行所有指令。《Redis設計與實現》中的詳述。
注意，Redis裏的事務，與我們平時的事務概念很不一樣：
它僅僅是保證事務裏的操作會被連續獨佔的執行。因爲是單線程架構，在執行完事務內所有指令前是不可能再去同時執行其他客戶端的請求的。
它沒有隔離級別的概念，因爲事務提交前任何指令都不會被實際執行，也就不存在”事務內的查詢要看到事務裏的更新，在事務外查詢不能看到”這個讓人萬分頭痛的問題。
它不保證原子性——所有指令同時成功或同時失敗，只有決定是否開始執行全部指令的能力，沒有執行到一半進行回滾的能力。在redis裏失敗分兩種，一種是明顯的指令錯誤，比如指令名拼錯，指令參數個數不對，在2.6版中全部指令都不會執行。另一種是隱含的，比如在事務裏，第一句是SET foo bar， 第二句是LLEN foo，對第一句產生的String類型的key執行LLEN會失敗，但這種錯誤只有在指令運行後才能發現，這時候第一句成功，第二句失敗。還有，如果事務執行到一半redis被KILL，已經執行的指令同樣也不會被回滾。
Watch指令，類似樂觀鎖，事務提交時，如果Key的值已被別的客戶端改變，比如某個list已被別的客戶端push/pop過了，整個事務隊列都不會被執行。
5、配置詳解
（1） Redis默認不是以守護進程的方式運行，可以通過該配置項修改，使用yes啓用守護進程
daemonize no
（2） 當Redis以守護進程方式運行時，Redis默認會把pid寫入/var/run/redis.pid文件，可以通過pidfile指定
pidfile /var/run/redis.pid
（3） 指定Redis監聽端口，默認端口爲6379，作者在自己的一篇博文中解釋了爲什麼選用6379作爲默認端口，因爲6379在手機按鍵上MERZ對應的號碼，而MERZ取自意大利歌女Alessia Merz的名字
port 6379
（4）綁定的主機地址
bind 127.0.0.1
（5）當 客戶端閒置多長時間後關閉連接，如果指定爲0，表示關閉該功能
timeout 300
（6）指定日誌記錄級別，Redis總共支持四個級別：debug、verbose、notice、warning，默認爲verbose
loglevel verbose
（7）日誌記錄方式，默認爲標準輸出，如果配置Redis爲守護進程方式運行，而這裏又配置爲日誌記錄方式爲標準輸出，則日誌將會發送給/dev/null
logfile stdout
（8）設置數據庫的數量，默認數據庫爲0，可以使用SELECT <dbid>命令在連接上指定數據庫id
databases 16
（9）指定在多長時間內，有多少次更新操作，就將數據同步到數據文件，可以多個條件配合
save <seconds> <changes>
Redis默認配置文件中提供了三個條件：
save 900 1
save 300 10
save 60 10000
分別表示900秒（15分鐘）內有1個更改，300秒（5分鐘）內有10個更改以及60秒內有10000個更改。
（10） 指定存儲至本地數據庫時是否壓縮數據，默認爲yes，Redis採用LZF壓縮，如果爲了節省CPU時間，可以關閉該選項，但會導致數據庫文件變的巨大
rdbcompression yes
（11）指定本地數據庫文件名，默認值爲dump.rdb
dbfilename dump.rdb
（12） 指定本地數據庫存放目錄
dir ./
（13）設置當本機爲slav服務時，設置master服務的IP地址及端口，在Redis啓動時，它會自動從master進行數據同步
slaveof <masterip> <masterport>
（14） 當master服務設置了密碼保護時，slav服務連接master的密碼
masterauth <master-password>
（15）設置Redis連接密碼，如果配置了連接密碼，客戶端在連接Redis時需要通過AUTH <password>命令提供密碼，默認關閉
requirepass foobared
（16）設置同一時間最大客戶端連接數，默認無限制，Redis可以同時打開的客戶端連接數爲Redis進程可以打開的最大文件描述符數，如果設置 maxclients 0，表示不作限制。當客戶端連接數到達限制時，Redis會關閉新的連接並向客戶端返回max number of clients reached錯誤信息
maxclients 128
（17）指定Redis最大內存限制，Redis在啓動時會把數據加載到內存中，達到最大內存後，Redis會先嚐試清除已到期或即將到期的Key，當此方法處理 後，仍然到達最大內存設置，將無法再進行寫入操作，但仍然可以進行讀取操作。Redis新的vm機制，會把Key存放內存，Value會存放在swap區
maxmemory <bytes>
（18）指定是否在每次更新操作後進行日誌記錄，Redis在默認情況下是異步的把數據寫入磁盤，如果不開啓，可能會在斷電時導致一段時間內的數據丟失。因爲 redis本身同步數據文件是按上面save條件來同步的，所以有的數據會在一段時間內只存在於內存中。默認爲no
appendonly no
（19）指定更新日誌文件名，默認爲appendonly.aof
appendfilename appendonly.aof
（20）指定更新日誌條件，共有3個可選值：
no：表示等操作系統進行數據緩存同步到磁盤（快）
always：表示每次更新操作後手動調用fsync()將數據寫到磁盤（慢，安全）
everysec：表示每秒同步一次（折衷，默認值）
appendfsync everysec
（21）指定是否啓用虛擬內存機制，默認值爲no，簡單的介紹一下，VM機制將數據分頁存放，由Redis將訪問量較少的頁即冷數據swap到磁盤上，訪問多的頁面由磁盤自動換出到內存中（在後面的文章我會仔細分析Redis的VM機制）
vm-enabled no
（22）虛擬內存文件路徑，默認值爲/tmp/redis.swap，不可多個Redis實例共享
vm-swap-file /tmp/redis.swap
（23）將所有大於vm-max-memory的數據存入虛擬內存,無論vm-max-memory設置多小,所有索引數據都是內存存儲的(Redis的索引數據 就是keys),也就是說,當vm-max-memory設置爲0的時候,其實是所有value都存在於磁盤。默認值爲0
vm-max-memory 0
（24）Redis swap文件分成了很多的page，一個對象可以保存在多個page上面，但一個page上不能被多個對象共享，vm-page-size是要根據存儲的 數據大小來設定的，作者建議如果存儲很多小對象，page大小最好設置爲32或者64bytes；如果存儲很大大對象，則可以使用更大的page，如果不 確定，就使用默認值
vm-page-size 32
（25）設置swap文件中的page數量，由於頁表（一種表示頁面空閒或使用的bitmap）是在放在內存中的，，在磁盤上每8個pages將消耗1byte的內存。
vm-pages 134217728
（26）設置訪問swap文件的線程數,最好不要超過機器的核數,如果設置爲0,那麼所有對swap文件的操作都是串行的，可能會造成比較長時間的延遲。默認值爲4
vm-max-threads 4
（27）設置在向客戶端應答時，是否把較小的包合併爲一個包發送，默認爲開啓
glueoutputbuf yes
（28）指定在超過一定的數量或者最大的元素超過某一臨界值時，採用一種特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
（29）指定是否激活重置哈希，默認爲開啓（後面在介紹Redis的哈希算法時具體介紹）
activerehashing yes
（30）指定包含其它的配置文件，可以在同一主機上多個Redis實例之間使用同一份配置文件，而同時各個實例又擁有自己的特定配置文件
include /path/to/local.conf
參考文獻：https://blog.csdn.net/hguisu/article/details/90748695