一、性能
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字節的數據。
1
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，普通硬盤的瓶頸)，
2 為什么快
主要是以下幾點點
一)、純內存操作
數據存放在內存中，內存的響應時間大約是 100納秒 ，這是Redis每秒萬億級別訪問的重要基礎。
二)、單線程操作，避免了頻繁的上下文切換
雖然是采用單線程，但是單線程避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU；雖然作者認為CPU不是瓶頸，內存與網絡帶寬才是。但實際測試時并非如此，見上。
三)、采用了非阻塞I/O多路復用機制
多路I/O復用模型是利用 select、poll、epoll 可以同時監察多個流的 I/O 事件的能力，在空閑的時候，會把當前線程阻塞掉，當有一個或多個流有 I/O 事件時，就從阻塞態中喚醒，于是程序就會輪詢一遍所有的流（epoll 是只輪詢那些真正發出了事件的流），并且只依次順序的處理就緒的流，這種做法就避免了大量的無用操作。這里“多路”指的是多個網絡連接，“復用”指的是復用同一個線程。加上Redis自身的事件處理模型將epoll中的連接，讀寫，關閉都轉換為了事件，不在I/O上浪費過多的時間。
四)、純ANSI C編寫。
不依賴第三方類庫，沒有像memcached那樣使用libevent，因為libevent迎合通用性而造成代碼龐大，所以作者用libevent中兩個文件修改實現了自己的epoll event loop。微軟的兼容windows補丁也因為同樣原因被拒了。
快，原因之一是Redis多樣的數據結構，每種結構只做自己愛做的事，當然比數據庫只有Table，MongogoDB只有JSON一種結構快了。
二、I/O復用模型和Reactor 設計模式
Redis內部實現采用epoll+自己實現的簡單的事件框架。epoll中的讀、寫、關閉、連接都轉化成了事件，然后利用epoll的多路復用特性， 絕不在io上浪費一點時間：
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 系統提供支持的；
# ifdefHAVE_EVPORT
# include"ae_evport.c"
# else
# ifdefHAVE_EPOLL
# include"ae_epoll.c"
# else
# ifdefHAVE_KQUEUE
# include"ae_kqueue.c"
# else
# include"ae_select.c"
# endif
# 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 的封裝，在返回后將激活的事件保存在事件驅動中
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
2.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”。
2.2 String
String是最簡單的類型，一個key對應一個value，string類型是二進制安全的。Redis的string可以包含任何數據，比如jpg圖片或者序列化的對象(php中對象序列化函數serialize)
內部實現，其本質是一個byte數組，字符串的大小被限制在512M以內
structsdshdr{
longlen; //buf數組的長度
longfree; //buf數組中剩余可用字節數
charbuf[]; //存儲實際字符串內容
}
所有常用命令的復雜度都是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.3 Hash
Key-HashMap結構，相比String類型將這整個對象持久化成JSON格式，Hash將對象的各個屬性存入Map里，可以只讀取/更新對象的某些屬性。這樣有些屬性超長就讓它一邊呆著不動，另外不同的模塊可以只更新自己關心的屬性而不會互相并發覆蓋沖突。
2.4 List
List是一個雙向鏈表，支持雙向的Pop/Push，江湖規矩一般從左端Push，右端Pop——LPush/RPop，而且還有Blocking的版本BLPop/BRPop，客戶端可以阻塞在那直到有消息到來，所有操作都是O(1)的好孩子，可以當Message Queue來用。當多個Client并發阻塞等待，有消息入列時誰先被阻塞誰先被服務。任務隊列系統Resque是其典型應用。
有RPopLPush/ BRPopLPush，彈出來返回給client的同時，把自己又推入另一個list，LLen獲取列表的長度。
2.5 Set
Set就是Set，可以將重復的元素隨便放入而Set會自動去重，底層實現也是hash table。
2.6 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很大那誰也沒辦法了。
2.8 Lua
Redis2.6內置的Lua 支持，可以在Redis的Server端一次過運行大量邏輯，就像存儲過程一樣，避免了海量中間數據在網路上的傳輸。
Lua自稱是在語言里關于快的標準，Redis選擇了它而不是流行的JAVA。
因為Redis的單線程架構，整個默認是在一個事務里的。
里涉及的所有Key盡量用變量，從外面傳入，使Redis一開始就知道你要改變哪些key。(but why?)
Eval每次傳輸一整段比較費帶寬，可以先用 Load載入，返回哈希值。然后用EvalHash執行。因為就是SHA-1，所以任何時候執行返回的哈希值都是一樣的。
內置的Lua庫里還很貼心的帶了CJSON，可以處理json字符串。
一段用Redis做Timer的示例代碼，下面的被定期調用，從以觸發時間為score的sorted set中取出已到期的Job，放到list中給Client們blocking popup。
— KEYS: [ 1]job:sleeping, [ 2]job:ready
— ARGS: [ 1]currentTime
— Comments: result isthe job id
local jobs=redis. call(‘zrangebyscore’, KEYS[ 1], ‘-inf’, ARGV[ 1])
local count = table.maxn(jobs)
ifcount> 0then
— Comments: remove fromSleeping Job sorted set
redis. call(‘zremrangebyscore’, KEYS[ 1], ‘-inf’, ARGV[ 1])
— Comments: add tothe Ready Job list
— Comments: can optimize touse lpush id1,id2,… forbetter performance
fori= 1,count do
redis. call(‘lpush’, KEYS[ 2], jobs[i])
end
end
在Redis使用過程中，Lua腳本的支持無疑給開發者提供一個非常友好的開發環境，從而大幅度解放用戶的創造力。如果使用得當，Lua腳本可以給性能和資源消耗帶來非常大的改善。取代將數據傳送給CPU，腳本允許你在最接近數據的地方執行邏輯，從而減少網絡延時和數據的冗余傳輸。
在Redis中，Lua一個非常經典的用例就是數據過濾或者將數據聚合到應用程序。通過將處理工作流封裝到一個腳本中，你只需要調用它就可以在更短的時間內使用很少的資源來獲取一個更小的答案。
2.9使用合適的數據結構
不管是內存使用或者是性能，有的時候數據結構將產生很大的影響，下面是一些可以參考的最佳實踐：
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的內存。
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://dwz.cn/JZ3IuIGl
