非常感謝 http://www.cnblogs.com/wuxl360/p/5817190.html

1. Overview

1.1 資料

1.2 優缺點

非常非常的快，有測評說比Memcached還快(當大家都是單CPU的時候)，而且是無短板的快，讀寫都一般的快，所有API都差不多快，也沒有MySQL Cluster、MongoDB那樣更新同一條記錄如Counter時慢下去的毛病。

豐富的數據結構，超越了一般的Key-Value數據庫而被認為是一個數據結構服務器。組合各種結構，限制Redis用途的是你自己的想象力，作者自己捉刀寫的用途入門。

因為是個人作品，Redis2.6版只有2.3萬行代碼，Keep it simple的死硬做法，使得普通公司而不需淘寶那個級別的文藝公司也可以吃透它。 Redis宣言就是作者的自白，我最喜歡其中的“代碼像首詩”，”設計是一場與復雜性的戰斗“，“Coding是一件艱苦的事情，唯一的辦法是享受它。如果它已不能帶來快樂就停止它。為了防止這一天的出現，我們要盡量避免把Redis往乏味的路上帶。”

讓人又愛又恨的單線程架構，使得代碼不用處理平時最讓人頭痛的并發而大幅簡化，也不用老是擔心作者的并發有沒有寫對，但也帶來單CPU的瓶頸，而且單線程被慢操作所阻塞時，其他請求的延時變得不確定。

那Redis不是什么？

1.3 Feature速覽

1.4 八卦

2. 數據結構

2.1 Key

2.2 String

最普通的key-value類型，說是String，其實是任意的byte[]，比如圖片，最大512M。 所有常用命令的復雜度都是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就會失效，剩下的節點又會發生新一輪搶 奪。

其他Set指令：

GetBit/SetBit/BitOp,與或非/BitCount， BitMap的玩法，比如統計今天的獨立訪問用戶數時，每個注冊用戶都有一個offset，他今天進來的話就把他那個位設為1，用BitCount就可以得出今天的總人數。

Append/SetRange/GetRange/StrLen，對文本進行擴展、替換、截取和求長度，只對特定數據格式如字段定長的有用，json就沒什么用。

2.3 Hash

Key-HashMap結構，相比String類型將這整個對象持久化成JSON格式，Hash將對象的各個屬性存入Map里，可以只讀取/更新對象的某些屬性。這樣有些屬性超長就讓它一邊呆著不動，另外不同的模塊可以只更新自己關心的屬性而不會互相并發覆蓋沖突。

另一個用法是土法建索引。比如User對象，除了id有時還要按name來查詢。可以有如下的數據記錄:

底層實現是hash table，一般操作復雜度是O(1)，要同時操作多個field時就是O(N)，N是field的數量。

2.4 List

List是一個雙向鏈表，支持雙向的Pop/Push，江湖規矩一般從左端Push，右端Pop——LPush/RPop，而且還有Blocking的版本BLPop/BRPop，客戶端可以阻塞在那直到有消息到來，所有操作都是O(1)的好孩子，可以當Message Queue來用。當多個Client并發阻塞等待，有消息入列時誰先被阻塞誰先被服務。任務隊列系統Resque是其典型應用。

還有RPopLPush/ BRPopLPush，彈出來返回給client的同時，把自己又推入另一個list，LLen獲取列表的長度。

還有按值進行的操作：LRem(按值刪除元素)、LInsert(插在某個值的元素的前后)，復雜度是O(N)，N是List長度，因為List的值不唯一，所以要遍歷全部元素，而Set只要O(log(N))。

按下標進行的操作：下標從0開始，隊列從左到右算，下標為負數時則從右到左。

復雜度也是O(N)，其中LSet的N是List長度，LIndex的N是下標的值，LRange的N是start的值+列出元素的個數，因為是鏈表而不是數組，所以按下標訪問其實要遍歷鏈表，除非下標正好是隊頭和隊尾。LTrim的N是移除元素的個數。

在消息隊列中，并沒有JMS的ack機制，如果消費者把job給Pop走了又沒處理完就死機了怎么辦？

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.7 事務

用Multi(Start Transaction)、Exec(Commit)、Discard(Rollback)實現。 在事務提交前，不會執行任何指令，只會把它們存到一個隊列里，不影響其他客戶端的操作。在事務提交時，批量執行所有指令。《Redis設計與實現》中的詳述。

注意，Redis里的事務，與我們平時的事務概念很不一樣：

Watch指令，類似樂觀鎖，事務提交時，如果Key的值已被別的客戶端改變，比如某個list已被別的客戶端push/pop過了，整個事務隊列都不會被執行。

2.8 Lua Script

Redis2.6內置的Lua Script支持，可以在Redis的Server端一次過運行大量邏輯，就像存儲過程一樣，避免了海量中間數據在網路上的傳輸。

-- KEYS: [1]job:sleeping, [2]job:ready-- ARGS: [1]currentTime-- Comments: result is the  job idlocal 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])  endend
2.9 過期數據清除
官方文檔 與 《Redis設計與實現》中的詳述，過期數據的清除從來不容易，為每一條key設置一個timer，到點立刻刪除的消耗太大，每秒遍歷所有數據消耗也大，Redis使用了一種相對務實的做法：
當client主動訪問key會先對key進行超時判斷，過時的key會立刻刪除。
如果clien永遠都不再get那條key呢？ 它會在Master的后臺，每秒10次的執行如下操作： 隨機選取100個key校驗是否過期，如果有25個以上的key過期了，立刻額外隨機選取下100個key(不計算在10次之內)。可見，如果過期的 key不多，它最多每秒回收200條左右，如果有超過25%的key過期了，它就會做得更多，但只要key不被主動get，它占用的內存什么時候最終被清 理掉只有天知道。
3. 性能
3.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 測試結果(TPS)： 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%(因為總共有2CPU6核超線程 = 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，普通硬盤的瓶頸)，
3.2 為什么快
純ANSI C編寫。不依賴第三方類庫，沒有像memcached那樣使用libevent，因為libevent迎合通用性而造成代碼龐大，所以作者用libevent中兩個文件修改實現了自己的epoll event loop。微軟的兼容Windows補丁也因為同樣原因被拒了。快，原因之一是Redis多樣的數據結構，每種結構只做自己愛做的事，當然比數據庫只有Table，MongogoDB只有JSON一種結構快了。可惜單線程架構，雖然作者認為CPU不是瓶頸，內存與網絡帶寬才是。但實際測試時并非如此，見上。
3.3 性能調優
官方文檔關于各種產生Latency的原因的詳細分析, 中文版正視網絡往返時間：1.MSet/LPush/ZAdd等都支持一次輸入多個Key。2.PipeLining模式 可以一次輸入多個指令。在Jedis的實現里，所有指令先在本地的buffer中存著，直到調用sync。3.更快的是Lua Script模式，還可以包含邏輯，直接在服務端又get又set的，見2.8 Lua Script。發現執行緩慢的命令，可配置執行超過多少時間的指令算是緩慢指令(默認10毫秒，不含IO時間)，可以用slowlog get 指令查看(默認只保留最后的128條)。單線程的模型下，一個請求占掉10毫秒是件大事情，注意設置和顯示的單位為微秒。CPU永遠是瓶頸，但top看到單個CPU 100%時，就是垂直擴展的時候了。持久化對性能的影響很大，見5.1持久化。要熟悉各指令的復雜度，不過只要不是O(N)一個超大集合，都不用太擔心。
4. 容量
4.1 最大內存
所有的數據都必須在內存中，原來2.0版的VM策略(將Value放到磁盤，Key仍然放在內存)，2.4版后嫌麻煩又不支持了。一定要設置最大內存，否則物理內存用爆了就會大量使用Swap，寫RDB文件時的速度慢得你想死。多留一倍內存是最安全的。重寫AOF文件和RDB文件的進程(即使不做持久化，復制到Slave的時候也要寫RDB)會fork出一條新進程來， 采用了操作系統的Copy-On-Write策略(子進程與父進程共享Page。如果父進程的Page-每頁4K有修改，父進程自己創建那個Page的副 本，不會影響到子進程，父愛如山)。留意Console打出來的報告，如"RDB: 1215 MB of memory used by copy-on-write"。在系統極度繁忙時，如果父進程的所有Page在子進程寫RDB過程中都被修改過了，就需要兩倍內存。按照Redis啟動時的提醒，設置 vm.overcommit_memory = 1 ，使得fork()一條10G的進程時，因為COW策略而不一定需要有10G的free memory。其他需要考慮的內存包括：1.AOF rewrite過程中對新寫入命令的緩存(rewrite結束后會merge到新的aof文件)，留意"Background AOF buffer size: 80 MB"的字樣。2.負責與Slave同步的Client的緩存，默認設置master需要為每個slave預留不高于256M的緩存(見5.1持久化)。當最大內存到達時，按照配置的Policy進行處理， 默認策略為volatile-lru，對設置了expire time的key進行LRU清除(不是按實際expire time)。如果沒有數據設置了expire time或者policy為noeviction，則直接報錯，但此時系統仍支持get之類的讀操作。 另外還有幾種policy，比如volatile-ttl按最接近expire time的，allkeys-lru對所有key都做LRU。見Redis的文檔：Redis as an LRU cache
4.2 內存占用
測試表明，string類型需要90字節的額外代價，就是說key 1個字節，value 1個字節時，還是需要占用92字節的長度，而上面的benchmark的記錄就占用了367個字節。其他類型可根據文檔自行計算或實際測試一下。使用jemalloc分配內存，刪除數據后，內存并不會乖乖還給操作系統而是被Redis截留下來重用到新的數據上，直到Redis重啟。因此進程實際占用內存是看INFO里返回的used_memory_peak_human。Redis內部用了ziplist/intset這樣的壓縮結構來減少hash/list/set/zset的存儲，默認當集合的元素少于512個且最長那個值不超過64字節時使用，可配置。用make 32bit可以編譯出32位的版本，每個指針占用的內存更小，但只支持最大4GB內存。
4.4 水平分區，Sharding，Partition
Redis文檔：Partitioning其實，大內存加上垂直分區也夠了，不一定非要沙丁一把。Jedis支持在客戶端做分區，局限是不能動態re-sharding， 有分區的master倒了，不能減少分區必須用slave頂上。要增加分區的話，呃.....antire在博客里提到了Twemproxy，一個Twitter寫的Proxy，但它在發現節點倒掉后，只會重新計算一致性哈希環，把數據存到別的master去，而不是集成Sentinel指向新由slave升級的master，像Memcached一樣的做法也只適合做Cache的場景。
Redis-Cluster在3.0版發布，支持自動re-sharding，Redis文檔：集群教程
采用和Hazelcast類似的算法，總共有N個分區(eg.N=1024)，每臺Server負責若干個分區，而且在Server間共享此信息，而不是像Memcached那樣每臺Server直接在一致性哈希環上占一塊地方。在客戶端先用一致性哈希出key 屬于哪個分區，隨便發給一臺server，server會告訴它真正哪個Server負責這個分區，客戶端緩存下來，下次還有該分區的請求就直接發到地兒了。Re-sharding時，會將某些分區的數據移到新的Server上，完成后各Server周知分區<->Server映射的變 化，因為分區數量有限，所以通訊量不大。 在遷移過程中，客戶端緩存的依然是舊的分區映射信息，原server對于已經遷移走的數據的get請求，會返回一個臨時轉向的應答，客戶端先不會更新 Cache。等遷移完成了，就會像前面那樣返回一條永久轉向信息，客戶端更新Cache，以后就都去新server了。目前問題：1. 事務和Lua腳本如果涉及到不同分區的Key如何解決，2. 創建Cluster Node的命令是Ruby寫的，要有Ruby才能跑。
5. 高可用性
高可用性關乎系統出錯時到底會丟失多少數據，多久不能服務。要綜合考慮持久化，Master-Slave復制及Fail-Over配置，以及具體Crash情形，比如Master死了，但Slave沒死。或者只是Redis死了，操作系統沒死等等。
5.1 持久化
綜述： 解密Redis持久化(中文概括版), 英文原版，《Redis設計與實現》： RDB 與 AOF。很多人開始會想象兩者是互相結合的，即dump出一個snapshot到RDB文件，然后在此基礎上記錄變化日志到AOF文件。實際上兩者毫無關系，完全獨立運行，因為作者認為簡單才不會出錯。如果使用了AOF，重啟時只會從AOF文件載入數據，不會再管RDB文件。正確關閉服務器：redis-cli shutdown 或者 kill，都會graceful shutdown，保證寫RDB文件以及將AOF文件fsync到磁盤，不會丟失數據。 如果是粗暴的Ctrl+C，或者kill -9 就可能丟失。
5.1.1 RDB文件
RDB是整個內存的壓縮過的Snapshot，RDB的數據結構，可以配置復合的快照觸發條件，默認是1分鐘內改了1萬次，或5分鐘內改了10次，或15分鐘內改了1次。RDB寫入時，會連內存一起Fork出一個新進程，遍歷新進程內存中的數據寫文件，這樣就解決了些Snapshot過程中又有新的寫入請求進來的問題。 Fork的細節見4.1最大內存。RDB會先寫到臨時文件，完了再Rename成，這樣外部程序對RDB文件的備份和傳輸過程是安全的。而且即使寫新快照的過程中Server被強制關掉了，舊的RDB文件還在。可配置是否進行壓縮，壓縮方法是字符串的LZF算法，以及將string形式的數字變回int形式存儲。動態所有停止RDB保存規則的方法：redis-cli config set save ""
5.1.2 AOF文件
操作日志，記錄所有有效的寫操作，等于mysql的binlog，格式就是明文的Redis協議的純文本文件。一般配置成每秒調用一次fdatasync將kernel的文件緩存刷到磁盤。當操作系統非正常關機時，文件可能會丟失不超過2秒的數據(更嚴謹 的定義見后)。 如果設為fsync always，性能只剩幾百TPS，不用考慮。如果設為no，靠操作系統自己的sync，linux系統一般30秒一次。AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件，最后再rename，)， 遍歷新進程的內存中數據，每條記錄有一條的Set語句。默認配置是當AOF文件大小是上次rewrite后大小的一倍，且文件大于64M時觸發。Redis協議，如set mykey hello， 將持久化成*3 $3 set $5 mykey $5 hello， 第一個數字代表這條語句有多少元，其他的數字代表后面字符串的長度。這樣的設計，使得即使在寫文件過程中突然關機導致文件不完整，也能自我修復，執行 redis-check-aof即可。
綜上所述，RDB的數據不實時，同時使用兩者時服務器重啟也只會找AOF文件。那要不要只使用AOF呢？作者建議不要，因為RDB更適合用于備份數據庫(AOF在不斷變化不好備份)，快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。
5.1.3 讀寫性能
AOF重寫和RDB寫入都是在fork出新進程后，遍歷新進程的內存順序寫的，既不阻塞主進程繼續處理客戶端請求，順序寫的速度也比隨機寫快。測試把剛才benchmark的11G數據寫成一個1.3的RDB文件，或者等大的AOF文件rewrite，需要80秒，在redis-cli info中可查看。啟動時載入一個AOF或RDB文件的速度與上面寫入時相同，在log中可查看。Fork一個使用了大量內存的進程也要時間，大約10ms per GB的樣子，但Xen在EC2上是讓人郁悶的239ms (KVM和VMWare貌似沒有這個毛病)，各種系統的對比，Info指令里的latest_fork_usec顯示上次花費的時間。在bgrewriteaof過程中，所有新來的寫入請求依然會被寫入舊的AOF文件，同時放到buffer中，當rewrite完成后，會在主線 程把這部分內容合并到臨時文件中之后才rename成新的AOF文件，所以rewrite過程中會不斷打印"Background AOF buffer size: 80 MB， Background AOF buffer size: 180 MB"，計算系統容量時要留意這部分的內存消耗。注意，這個合并的過程是阻塞的，如果你產生了280MB的buffer，在100MB/s的傳統硬盤 上，Redis就要阻塞2.8秒！！！NFS或者Amazon上的EBS都不推薦，因為它們也要消耗帶寬。bgsave和bgaofrewrite不會被同時執行，如果bgsave正在執行，bgaofrewrite會自動延后。2.4版以后，寫入AOF時的fdatasync由另一條線程來執行，不會再阻塞主線程。2.4版以后，lpush/zadd可以輸入一次多個值了，使得AOF重寫時可以將舊版本中的多個lpush/zadd指令合成一個，每64個key串一串。
5.1.4 性能調整
因為RDB文件只用作后備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。
如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啟動腳本較簡單只load自己的AOF文件就可以了。代價一是帶來了持續的IO，二是AOF rewrite的最后將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上。默認超過原大小100%大小時重寫可以改到適當的數值，比如之前的 benchmark每個小時會產生40G大小的AOF文件，如果硬盤能撐到半夜系統閑時才用cron調度bgaofrewrite就好了。
如果不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數據，啟 動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構，見Tim的博客
5.1.5 Trouble Shooting —— Enable AOF可能導致整個Redis被Block住，在2.6.12版之前
現象描述：當AOF rewrite 15G大小的內存時，Redis整個死掉的樣子，所有指令甚至包括slave發到master的ping，redis-cli info都不能被執行。
原因分析：
官方文檔，由IO產生的Latency詳細分析, 已經預言了悲劇的發生，但一開始沒留意。Redis為求簡單，采用了單請求處理線程結構。打開AOF持久化功能后， Redis處理完每個事件后會調用write(2)將變化寫入kernel的buffer，如果此時write(2)被阻塞，Redis就不能處理下一個事件。Linux規定執行write(2)時，如果對同一個文件正在執行fdatasync(2)將kernel buffer寫入物理磁盤，或者有system wide sync在執行，write(2)會被block住，整個Redis被block住。如果系統IO繁忙，比如有別的應用在寫盤，或者Redis自己在AOF rewrite或RDB snapshot(雖然此時寫入的是另一個臨時文件，雖然各自都在連續寫，但兩個文件間的切換使得磁盤磁頭的尋道時間加長），就可能導致 fdatasync(2)遲遲未能完成從而block住write(2)，block住整個Redis。為了更清晰的看到fdatasync(2)的執行時長，可以使用"strace -p (pid of redis server) -T -e -f trace=fdatasync"，但會影響系統性能。Redis提供了一個自救的方式，當發現文件有在執行fdatasync(2)時，就先不調用write(2)，只存在cache里，免得被 block。但如果已經超過兩秒都還是這個樣子，則會硬著頭皮執行write(2)，即使redis會被block住。此時那句要命的log會打 印：“Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.” 之后用redis-cli INFO可以看到aof_delayed_fsync的值被加1。因此，對于fsync設為everysec時丟失數據的可能性的最嚴謹說法是：如果有fdatasync在長時間的執行，此時redis意外關閉 會造成文件里不多于兩秒的數據丟失。如果fdatasync運行正常，redis意外關閉沒有影響，只有當操作系統crash時才會造成少于1秒的數據丟 失。
解決方法：最后發現，原來是AOF rewrite時一直埋頭的調用write(2)，由系統自己去觸發sync。在RedHat Enterprise 6里，默認配置vm.dirty_background_ratio=10，也就是占用了10%的可用內存才會開始后臺flush，而我的服務器有64G 內存。很明顯一次flush太多數據會造成阻塞，所以最后果斷設置了sysctl vm.dirty_bytes=33554432(32M)，問題解決。
然后提了個issue，AOF rewrite時定時也執行一下fdatasync嘛， antirez三分鐘后就回復了，新版中，AOF rewrite時32M就會重寫主動調用fdatasync。
5.2 Master-Slave復制
5.2.1 概述
slave可以在配置文件、啟動命令行參數、以及redis-cli執行SlaveOf指令來設置自己是奴隸。測試表明同步延時非常小，指令一旦執行完畢就會立刻寫AOF文件和向Slave轉發，除非Slave自己被阻塞住了。比較蠢的是，即使在配置文件里設了slavof，slave啟動時依然會先從數據文件載入一堆沒用的數據，再去執行slaveof。"Slaveof no one"，立馬變身master。2.8版本將支持PSYNC部分同步，master會撥出一小段內存來存放要發給slave的指令，如果slave短暫的斷開了，重連時會從內存中讀取需要補讀的指令，這樣就不需要斷開兩秒也搞一次全同步了。但如果斷開時間較長，已經超過了內存中保存的數據，就還是要全同步。Slave也可以接收Read-Only的請求。
5.2.2 slaveof執行過程，完全重用已有功能，非常經濟
先執行一次全同步 -- 請求master BgSave出自己的一個RDB Snapshot文件發給slave，slave接收完畢后，清除掉自己的舊數據，然后將RDB載入內存。再進行增量同步 -- master作為一個普通的client連入slave，將所有寫操作轉發給slave，沒有特殊的同步協議。
5.2.3 Trouble Shooting again
有時候明明master/slave都活得好好的，突然間就說要重新進行全同步了：
1.Slave顯示：# MASTER time out: no data nor PING received...
slave會每隔repl-ping-slave-period(默認10秒)ping一次master，如果超過repl-timeout(默認 60秒)都沒有收到響應，就會認為Master掛了。如果Master明明沒掛但被阻塞住了也會報這個錯。可以適當調大repl-timeout。
2.Master顯示：# Client addr=10.175.162.123:44670 flags=S oll=104654 omem=2147487792 events=rw cmd=sync scheduled to be closed ASAP for overcoming of output buffer limits.
當slave沒掛但被阻塞住了，比如正在loading Master發過來的RDB， Master的指令不能立刻發送給slave，就會放在output buffer中(見oll是命令數量，omem是大小)，在配置文件中有如下配置：client-output-buffer-limit slave 256mb 64mb 60， 這是說負責發數據給slave的client，如果buffer超過256m或者連續60秒超過64m，就會被立刻強行關閉！！！ Traffic大的話一定要設大一點。否則就會出現一個很悲劇的循環，Master傳輸一個大的RDB給Slave，Slave努力的裝載，但還沒裝載 完，Master對client的緩存滿了，再來一次。
平時可以在master執行 redis-cli client list 找那個cmd=sync，flag=S的client，注意OMem的變化。
5.3 Fail-Over
Redis-sentinel是2.6版開始加入的另一組獨立運行的節點，提供自動Fail Over的支持。
官方文檔 與 Redis核心解讀–集群管理工具(Redis-sentinel)antirez 對 Sentinel的反駁，與下篇
5.3.1 主要執行過程
Sentinel每秒鐘對所有master，slave和其他sentinel執行Ping，redis-server節點要應答+PONG或-LOADING或-MASTERDOWN.如果某一臺Sentinel沒有在30秒內(可配置得短一些哦)收到上述正確應答，它就會認為master處于sdown狀態(主觀Down)它向其他sentinel詢問是否也認為該master倒了（SENTINEL is-master-down-by-addr ）， 如果quonum臺(默認是2)sentinel在5秒鐘內都這樣認為，就會認為master真是odown了(客觀Down)。此時會選出一臺sentinel作為Leader執行fail-over, Leader會從slave中選出一個提升為master(執行slaveof no one)，然后讓其他slave指向它(執行slaveof new master)。
5.3.2 master/slave 及 其他sentinel的發現
master地址在sentinel.conf里, sentinel會每10秒一次向master發送INFO，知道master的slave有哪些。 如果master已經變為slave，sentinel會分析INFO的應答指向新的master。以前，sentinel重啟時，如果master已經 切換過了，但sentinel.conf里master的地址并沒有變，很可能有悲劇發生。另外master重啟后如果沒有切換成slave，也可能有悲 劇發生。新版好像修復了一點這個問題，待研究。
另外，sentinel會在master上建一個pub/sub channel，名為"sentinel:hello"，通告各種信息，sentinel們也是通過接收pub/sub channel上的+sentinel的信息發現彼此，因為每臺sentinel每5秒會發送一次自己的host信息，宣告自己的存在。
5.3.3 自定義reconfig腳本
sentinel在failover時還會執行配置文件里指定的用戶自定義reconfig腳本，做用戶自己想做的事情，比如讓master變為slave并指向新的master。腳本的將會在命令行按順序傳入如下參數： <master-name> <role(leader/observer)> <state(上述三種情況)> <from-ip> <from-port> <to-ip> <to-port>腳本返回0是正常，如果返回1會被重新執行，如果返回2或以上不會。 如果超過60秒沒返回會被強制終止。
覺得Sentinel至少有兩個可提升的地方:
一是如果master 主動shutdown，比如系統升級，有辦法主動通知sentinel提升新的master，減少服務中斷時間。二是比起redis-server太原始了，要自己丑陋的以nohup sentinel > logfile 2>&1 & 啟動，也不支持shutdown命令，要自己kill pid。
5.4 Client的高可用性
基于Sentinel的方案，client需要執行語句SENTINEL get-master-addr-by-name mymaster 可獲得當前master的地址。 Jedis正在集成sentinel，已經支持了sentinel的一些指令，但還沒發布，但sentinel版的連接池則暫時完全沒有，在公司的項目里我參考網友的項目自己寫了一個。
淘寶的Tedis driver，使用了完全不同的思路，不基于Sentinel，而是多寫隨機讀， 一開始就同步寫入到所有節點，讀的話隨便讀一個還活著的節點就行了。但有些節點成功有些節點失敗如何處理? 節點死掉重新起來后怎么重新同步?什么時候可以重新Ready? 所以不是很敢用。
另外如Ruby寫的redis_failover，也是拋開了Redis Sentinel，基于ZooKeeper的臨時方案。
Redis作者也在博客里抱怨怎么沒有人做Dynamo-style 的client。
5.5 Geographic Replication
依然用Master Slave復制，支持Active-Standby模式的Geographic Replication，主要用于容災數據恢復，或者在site1倒掉時，啟動備用系統指向備庫。3Scale想出了諸如用壓縮的SSH隧道降低傳輸量等方法，可以設置遠端的Slave的優先級為0，則site2上的slave永遠不會被選舉成master，master只會在site1的slave中產生。
6. 運維
6.1 安裝
安裝包制作：沒有現成，需要自己編譯，自己寫rpm包的腳本，可參考utils中的install_server.sh與redis_init_script。但RHEL下設定script runlevel的方式不一樣，redis_init_script中要增加一句 "# chkconfig: 345 90 10" ，而install_server.sh可以刪掉后面的那句“chkconfig --level 345 reis"云服務：Redis Cloud，在Amazon、Heroku、Windows Azure、App Frog上提供云服務，供同樣部署在這些云上的應用使用。其他的云服務有GarantiaData，已被redis-cloud收購。另外還有Redis To Go, OpenRedis, RedisGreen。CopperEgg統計自己的用戶在AWS上的數據庫部署：mysqld占了50%半壁江山, redis占了18%排第二, mongodb也有11%, cassandra是3%，Oracle只有可憐的2%。Chef Recipes：brianbianco/redisio，活躍，同步更新版本。
6.2 部署模型
Redis只能使用單線程，為了提高CPU利用率，有提議在同一臺服務器上啟動多個Redis實例，但這會帶來嚴重的IO爭用，除非Redis不需要持久化，或者有某種方式保證多個實例不會在同一個時間重寫AOF。一組sentinel能同時監控多個Master。有提議說環形的slave結構，即master只連一個slave，然后slave再連slave，此部署有兩個前提，一是有大量的只讀需求需要在slave完成，二是對slave傳遞時的數據不一致性不敏感。
6.3 配置
約30個配置項，全都有默認配置，對redif.conf默認配置的修改見附錄1。
6.3.1 三條路
可以配置文件中編寫。可以在啟動時的命令行配置，redis-server --port 7777 --slaveof 127.0.0.1 8888。云時代大規模部署，把配置文件滿街傳顯然不是好的做法， 可以用redis-cli執行Config Set指令， 修改所有的參數，達到維護人員最愛的不重啟服務而修改參數的效果，而且新里還可以執行 Config Rewrite 將改動寫回到文件中，原配置文件里有的項會就地更改，新的項而且不是默認值的，寫在文件最后。如果寫入過程中crash，所有修改都不會發生。
6.3.2 安全保護
在配置文件里設置密碼：requirepass foobar。禁止某些危險命令，比如殘暴的FlushDB，將它rename成""：rename-command FLUSHDB ""。
6.4 監控與維護
綜述： Redis監控技巧
6.4.1 監控指令
Info指 令將返回非常豐富的信息。 著重監控檢查內存使用，是否已接近上限，used_memory是Redis申請的內存，used_memory_rss是操作系統分配給Redis的物 理內存，兩者之間隔著碎片，隔著Swap。 還有重點監控 AOF與RDB文件的保存情況，以及master-slave的關系。Statistic 信息還包括key命中率，所有命令的執行次數，所有client連接數量等， CONFIG RESETSTAT 可重置為0。
Monitor指令可以顯示Server收到的所有指令，主要用于debug，影響性能，生產環境慎用。
SlowLog 檢查慢操作(見2.性能)。
6.4.2 Trouble Shooting支持
日志可以動態的設置成verbose/debug模式，但不見得有更多有用的log可看,verbose還會很煩的每5秒打印當前的key情況和client情況。指令為config set loglevel verbose。最愛Redis的地方是代碼只有2.3萬行，而且編碼優美，而且huangz同學還在原來的注釋上再加上了中文注釋——Redis 2.6源碼中文注釋版 ，所以雖然是C寫的代碼，雖然有十年沒看過C代碼，但這幾天trouble shooting毫無難度，一看就懂。Trobule shotting的經歷證明antirez處理issue的速度非常快(如果你的issue言之有物的話)，比Weblogic之類的商業支持還好。
6.4.3 持久化文件維護
如果AOF文件在寫入過程中crash，可以用redis-check-aof修復，見5.1.2如果AOF rewrite和 RDB snapshot的過程中crash，會留下無用的臨時文件，需要定期掃描刪除。
6.4.4 三方工具
官網列出了如下工具，但暫時沒發現會直接拿來用的：
Redis Live，基于Python的web應用，使用Info和Monitor獲得系統情況和指令統計分析。 因為Monitor指令影響性能，所以建議用cron定期運行，每次偷偷采樣兩分鐘的樣子。phpRedisAdmin，基于php的Web應用，目標是MysqlAdmin那樣的管理工具，可以管理每一條Key的情況，但它的界面應該只適用于Key的數量不太多的情況，Demo。Redis Faina，基于Python的命令行，Instagram出品，用戶自行獲得Monitor的輸出后發給它進行統計分析。由于Monitor輸出的格式在Redis版本間不一樣，要去github下最新版。Redis-rdb-tools 基于Python的命令行，可以分析RDB文件每條Key對應value所占的大小，還可以將RDB dump成普通文本文件然后比較兩個庫是否一致，還可以將RDB輸出成JSON格式，可能是最有用的一個了。Redis Sampler，基于Ruby的命令行，antirez自己寫的，統計數據分布情況。
7. Java Driver
7.1 Driver選擇
各個Driver好像只有Jedis比較活躍，但也5個月沒提交了，也是Java里唯一的Redis官方推薦。
Spring Data Redis的 封裝并不太必要，因為Jedis已足夠簡單，沒有像Spring Data MongoDB對MongoDB java driver的封裝那樣大幅簡化代碼，頂多就是加強了一點點點pipeline和transaction狀態下的coding，禁止了一些此狀態下不能用 的命令。而所謂屏蔽各種底層driver的差異并不太吸引人，因為我就沒打算選其他幾種driver。有興趣的可以翻翻它的JedisConnection代碼。
所以，SpringSide直接在Jedis的基礎上，按Spring的風格封裝了一個JedisTemplate，負責從池中獲取與歸還Jedis實例，處理異常。
7.2 Jedis的細節
Jedis基于Apache Commons Pool做的連接池，默認MaxActive最大連接數只有8，必須重新設置。而且MaxIdle也要相應增大，否則所有新建的連接用完即棄，然后會不停的重新連接。
另外Jedis設定了每30秒對所有連接執行一次ping，以發現失效的連接，這樣每30秒會有一個拿不到連接的高峰。但效果如何需要獨立分析。比 如系統高峰之后可能有一長段時間很閑，而且Redis Server那邊做了Timeout控制會把連接斷掉，這時候做idle checking是有意義的，但30秒一次也太過頻繁了。否則關掉它更好。
Jedis的blocking pop函數，應用執行ExecutorService.shutdownNow()中斷線程時并不能把它中斷，見討論組。兩個解決方法：
不要用不限時的blocking popup，傳多一個超時時間參數，如5秒。找地方將調用blocking popup的jedis保存起來，shutdown時主動調用它的close。
7.3 Redis對Client端連接的處理
Redis默認最大連接數是一萬。Redis默認不對Client做Timeout處理，可以用timeout 項配置，但即使配了也不會非常精確。
8. Windows的版本
Windows版本方便對應用的本地開發調試，但Redis并沒有提供，好在微軟提供了一個依賴LibUV實現兼容的補丁，https://github.com/MSOpenTech/redis ，但redis作者拒絕合并到master中，微軟只好苦憋的時時人工同步。 目前的穩定版是2.6版本，支持Lua腳本。
因為github現在已經沒有Download服務了，所以編譯好的可執行文件藏在這里：
https://github.com/MSOpenTech/redis/tree/2.6/bin/releasehttps://github.com/MSOpenTech/redis/tree/2.8/bin/release
9. 單元測試、集成測試
NoSQL Unit 是使用了Redis的項目的福音，它提供三個功能： 1. 嵌入式的Jedis實例，用于單元測試。在springside-extension的JedisTemplateTest里使用了它。 1. ManagedRedis，可控制已安裝在機器上的redis，可用集成測試。將在下個迭代試用。 1. 將數據定義在json文件里，可以在測試時裝載數據或校驗redis中的數據。
但嵌入式的Redis，不能模仿Lua腳本。而ManagedRedis也不支持Windows上的Redis。
10. 成功案例
注：下文中的鏈接都是網站的架構描述文檔。
Twitter和新浪微博， 都屬于將Redis各種數據結構用得出神入化的那種，如何發布大V如奧巴馬的消息是它們最頭痛的問題。
Tumblr： 11億美刀賣給Yahoo的圖片日志網站，22 臺Redis server，每臺運行8 - 32個實例，總共100多個Redis實例在跑。有著Redis has been completely problem free and the community is great的崇高評價。Redis在里面扮演了八爪魚多面手的角色：
Dashboard的海量通知的存儲。Dashboard的二級索引。存儲海量短鏈接的HBase前面的緩存。Gearman Job Queue的存儲。正在替換另外30臺memcached。
Instagram ，曾經，Redis powers their main feed, activity feed, sessions system, and other services。但可惜目前已遷往Cassandra，說新架構只需1/4的硬件費用，是的，就是那個導致Digg CTO辭職的Canssandra。
Flickr , 依然是asynchronous task system and rudimentary queueing system。之前Task system放在mysql innodb，根本，撐不住。
The Others：
Pinterest，混合使用MySQL、Membase與Redis作為存儲。Youporn.com，100%的Redis，MySQL只用于創建新需求用到的sorted set，300K QPS的大壓力。日本微信 ，Redis在前負責異步Job Queue和O(n)的數據，且作為O(nt)數據的cache，HBase在后，負責O(nt)數據， n是用戶，t是時間。StackOverflow ，2 Redis servers for distribute caching，好窮好輕量。Github，任務系統Resque的存儲。Digg，用來做頁面計數器之類的。Discourge，號稱是為下一個十年打造的論壇系統， We use Redis for our job queue, rate limiting, as a cache and for transient data，剛好和我司的用法一樣。情色網站 YouPorn，使用 Redis 進行數據存儲，Redis 服務器每秒處理30萬個頁面請求，每小時會記錄8-15GB數據。
11. In SpringSide
extension modules項目封裝了常用的函數與場景，showcase example的src/demo/redis目錄里有各場景的benchmark測試。
11.1 Jedis Template
典型的Spring Template風格，和JdbcTemplate，HibernateTemplate一樣，封裝從JedisPool獲取與歸還Connecton的 代碼，有帶返回值與無返回值兩種返回接口。同時，對最常用的Jedis調用，直接封裝了一系列方法。
11.2 Scheduler與Master Elector
Scheduler實現了基于Redis的高并發單次定時任務分發。具體選型見Scheduler章節。
Master Elector基于redis setNx()與expire()兩個api實現，與基于Zookeeper，Hazelcast實現的效果類似。
11.3 Showcase中的Demo
計有Session，Counter，Scheduler 與 Master Elector四款。
12. What is new in Redis 2.8
全新的Sentinel實現，Setinel會在自己配置文件持久化誰是最新master，也會讓每臺redis-server持久化新的 mater，重新起來的節點如果錯誤的把自己當成maser，sentinel也會發出slaveof的指令糾正它，原來要自行實現的腳本都可以去掉了。CONFIG REWRITE將命令行CONFIG SET動態改變的配置寫回到配置文件。SCAN命令，分頁匹配遍歷所有的Key。EVALSHA ，用sha1執行的Lua腳本可被直接Replicate，不需要翻譯成完整的Lua腳本再replicate，節約了Replicate的帶寬。提升了Expired keys的收集算法，在CPU繁忙時也不會累積大量超時的Key??說了很久的半同步，Slave短時間斷開后不需要做全同步。支持IPv6，并可綁定多個IP地址。進程名會帶上端口號和是否子進程的標識，ps時能分得清一臺機器上的多個redis，或者是fork出來的bgrewrite/bgrewriteaof字進程了。
其他用不上的new feature：
PUBSUB 收取keyspace 更新信息.Masters can stop accepting writes if not enough slaves with a given maximum latency are connected. 默認為0.
附錄
附錄1： 對redis.conf默認配置的修改
Master上
maxmemory，設置為可用內存的一半.logfile stdout -> /var/log/redis/redis.log ，指定日志文件dir ./ -> /var/lib/redis，指定持久化文件及臨時文件目錄.(可選)daemonize no -> yes ，啟動daemonize模式，注意如果用daemon工具啟動redis-server時設回false。appendonly no->yes，打開AOF文件.auto-aof-rewrite-percentage 100, 綜合考慮硬盤大小，可接受重啟加載延時等盡量的大，減少AOF rewrite頻率.auto-aof-rewrite-min-size 64mb，同上，起碼設為5G. *(可選)注釋掉RDB的所有觸發規則，在Master不保存RDB文件。client-output-buffer-limit slave 256mb 64mb 60. 考慮Traffic及Slave同步是RDB加載所需時間，正確設置避免buffer撐爆client被關掉后又要重新進行全同步。安全配置，可選。
Slave上
設置RDB保存頻率，因為RDB只作為Backup工具，設置為30分鐘保存一次就夠了save 1800 1。repl-timeout 60, 適當加大比如120，避免master實際還沒倒掉就認為master倒了。(可選)slaveof 設置master地址，也可動態設定。
附錄2：版本變更歷史
3.1版 20 2014-3-24 增加Redis 2.8內容3.0.1版-3.0.3版 2013-8-1-2014-1-24，在微博發布后反應良好，持續修改。3.0版 2013-6-29，在公司Workshop后修訂，提高wiki的可讀性而不只是簡單的記錄知識點。
附錄3：其他參考資料
Redis的幾個認識誤區 by Tim yang。