1. Overview
非常非常的快，有測評說比Memcached還快(當(dāng)大家都是單CPU的時候)，而且是無短板的快，讀寫都一般的快，所有API都差不多快，也沒有MySQL Cluster、MongoDB那樣更新同一條記錄如Counter時慢下去的毛病。
豐富的數(shù)據(jù)結(jié)構(gòu)，超越了一般的Key-Value數(shù)據(jù)庫而被認(rèn)為是一個數(shù)據(jù)結(jié)構(gòu)服務(wù)器。組合各種結(jié)構(gòu)，限制Redis用途的是你自己的想象力，作者自己捉刀寫的用途入門
因?yàn)槭莻€人作品，Redis目前只有2.3萬行代碼，Keep it simple的死硬做法，使得普通公司而不需淘寶那個級別的文藝公司也可以吃透它。Redis宣言就是作者的自白，我最喜歡其中的“代碼像首詩”，”設(shè)計是一場與復(fù)雜性的戰(zhàn)斗“，“Coding是一件艱苦的事情，唯一的辦法是享受它。如果它已不能帶來快樂就停止它。為了防止這一天的出現(xiàn)，我們要盡量避免把Redis往乏味的路上帶。”
讓人又愛又恨的單線程架構(gòu)，使得代碼不用處理平時最讓人頭痛的并發(fā)而大幅簡化，但也帶來CPU的瓶頸，而且單線程被慢操作所阻塞時，其他請求的延時變得不確定。
那Redis不是什么？
Redis 不是Big Data，數(shù)據(jù)都在內(nèi)存中，無法以T為單位。在Redis-Cluster發(fā)布并被穩(wěn)定使用之前，Redis沒有真正的平滑水平擴(kuò)展能力。Redis 不支持Ad-Hoc Query，提供的只是數(shù)據(jù)結(jié)構(gòu)的API，沒有SQL一樣的查詢能力。最普通的key-value類型，說是String，其實(shí)是任意的byte[]，比如圖片，最大512M。 所有常用命令的復(fù)雜度都是O(1)，普通的Get/Set方法，可以用來做Cache，存session，為了簡化架構(gòu)甚至可以替換掉Memcached。
Incr/IncrBy/IncrByFloat/Decr/DecrBy，可以用來做計數(shù)器，做自增序列。key不存在時會創(chuàng)建并貼心的設(shè)原值為0。IncrByFloat專門針對float，沒有對應(yīng)的decrByFloat版本？用負(fù)數(shù)啊。
SetNx， 僅當(dāng)key不存在時才Set。可以用來選舉Master或做分布式鎖：所有Client不斷嘗試使用SetNx master myName搶注Master，成功的那位不斷使用Expire刷新它的過期時間。如果Master倒掉了key就會失效，剩下的節(jié)點(diǎn)又會發(fā)生新一輪搶奪。
其他Set指令：
SetEx， Set + Expire 的簡便寫法，p字頭版本以毫秒為單位。GetSet， 設(shè)置新值，返回舊值。比如一個按小時計算的計數(shù)器，可以用GetSet獲取計數(shù)并重置為0。這種指令在服務(wù)端做起來是舉手之勞，客戶端便方便很多。MGet/MSet/MSetNx， 一次get/set多個key。2.6.12版開始，Set命令已融合了Set/SetNx/SetEx三者，SetNx與SetEx可能會被廢棄。GetBit/SetBit/BitOp,與或非/BitCount， BitMap的玩法，比如統(tǒng)計今天的獨(dú)立訪問用戶數(shù)時，每個注冊用戶都有一個offset，他今天進(jìn)來的話就把他那個位設(shè)為1，用BitCount就可以得出今天的總?cè)藬?shù)。
Append/SetRange/GetRange/StrLen，對文本進(jìn)行擴(kuò)展、替換、截取和求長度，只對特定數(shù)據(jù)格式如字段定長的有用，json就沒什么用。
Key-HashMap結(jié)構(gòu)，相比String類型將這整個對象持久化成JSON格式，Hash將對象的各個屬性存入Map里，可以只讀取/更新對象的某些屬性。這樣有些屬性超長就讓它一邊呆著不動，另外不同的模塊可以只更新自己關(guān)心的屬性而不會互相并發(fā)覆蓋沖突。
另一個用法是土法建索引。比如User對象，除了id有時還要按name來查詢。可以有如下的數(shù)據(jù)記錄:
(String) user:101 -> {“id”:101,”name”:”calvin”…}(String) user:102 -> {“id”:102,”name”:”kevin”…}(Hash) user:index-> “calvin”->101, “kevin” -> 102底層實(shí)現(xiàn)是hash table，一般操作復(fù)雜度是O(1)，要同時操作多個field時就是O(N)，N是field的數(shù)量。
List是一個雙向鏈表，支持雙向的Pop/Push，江湖規(guī)矩一般從左端Push，右端Pop——LPush/RPop，而且還有Blocking的版本BLPop/BRPop，客戶端可以阻塞在那直到有消息到來，所有操作都是O(1)的好孩子，可以當(dāng)Message Queue來用。當(dāng)多個Client并發(fā)阻塞等待，有消息入列時誰先被阻塞誰先被服務(wù)。任務(wù)隊(duì)列系統(tǒng)Resque是其典型應(yīng)用。
還有RPopLPush/ BRPopLPush，彈出來返回給client的同時，把自己又推入另一個list，LLen獲取列表的長度。
還有按值進(jìn)行的操作：LRem(按值刪除元素)、LInsert(插在某個值的元素的前后)，復(fù)雜度是O(N)，N是List長度，因?yàn)長ist的值不唯一，所以要遍歷全部元素，而Set只要O(log(N))。
按下標(biāo)進(jìn)行的操作：下標(biāo)從0開始，隊(duì)列從左到右算，下標(biāo)為負(fù)數(shù)時則從右到左。
LSet ，按下標(biāo)設(shè)置元素值。LIndex，按下標(biāo)返回元素。LRange，不同于POP直接彈走元素，只是返回列表內(nèi)一段下標(biāo)的元素，是分頁的最愛。LTrim，限制List的大小，比如只保留最新的20條消息。復(fù)雜度也是O(N)，其中LSet的N是List長度，LIndex的N是下標(biāo)的值，LRange的N是start的值+列出元素的個數(shù)，因?yàn)槭擎湵矶皇菙?shù)組，所以按下標(biāo)訪問其實(shí)要遍歷鏈表，除非下標(biāo)正好是隊(duì)頭和隊(duì)尾。LTrim的N是移除元素的個數(shù)。
在消息隊(duì)列中，并沒有JMS的ack機(jī)制，如果消費(fèi)者把job給Pop走了又沒處理完就死機(jī)了怎么辦？
解決方法之一是加多一個sorted set，分發(fā)的時候同時發(fā)到list與sorted set，以分發(fā)時間為score，用戶把job做完了之后要用ZREM消掉sorted set里的job，并且定時從sorted set中取出超時沒有完成的任務(wù)，重新放回list。另一個做法是為每個worker多加一個的list，彈出任務(wù)時改用RPopLPush，將job同時放到worker自己的list中，完成時用LREM消掉。如果集群管理(如zookeeper)發(fā)現(xiàn)worker已經(jīng)掛掉，就將worker的list內(nèi)容重新放回主list。Set就是Set，可以將重復(fù)的元素隨便放入而Set會自動去重，底層實(shí)現(xiàn)也是hash table。
SAdd/SRem/SIsMember/SCard/SMove/SMembers，各種標(biāo)準(zhǔn)操作。除了SMembers都是O(1)。SInter/SInterStore/SUnion/SUnionStore/SDiff/SDiffStore，各種集合操作。交集運(yùn)算可以用來顯示在線好友(在線用戶 交集 好友列表)，共同關(guān)注(兩個用戶的關(guān)注列表的交集)。O(N)，并集和差集的N是集合大小之和，交集的N是小的那個集合的大小*2。有序集，元素放入集合時還要提供該元素的分?jǐn)?shù)。
ZRange/ZRevRange，按排名的上下限返回元素，正數(shù)與倒數(shù)。ZRangeByScore/ZRevRangeByScore，按分?jǐn)?shù)的上下限返回元素，正數(shù)與倒數(shù)。ZRemRangeByRank/ZRemRangeByScore，按排名/按分?jǐn)?shù)的上下限刪除元素。ZCount，統(tǒng)計分?jǐn)?shù)上下限之間的元素個數(shù)。ZRank/ZRevRank ，顯示某個元素的正倒序的排名。ZScore/ZIncrby，顯示元素的分?jǐn)?shù)/增加元素的分?jǐn)?shù)。ZAdd(Add)/ZRem(Remove)/ZCard(Count)，ZInsertStore(交集)/ZUnionStore(并集)，Set操作，與正牌Set相比，少了IsMember和差集運(yùn)算。Sorted Set的實(shí)現(xiàn)是hash table(element->score, 用于實(shí)現(xiàn)ZScore及判斷element是否在集合內(nèi))，和skip list(score->element,按score排序)的混合體。 skip list有點(diǎn)像平衡二叉樹那樣，不同范圍的score被分成一層一層，每層是一個按score排序的鏈表。
ZAdd/ZRem是O(log(N))，ZRangeByScore/ZRemRangeByScore是O(log(N)+M)，N是Set大小，M是結(jié)果/操作元素的個數(shù)。可見，原本可能很大的N被很關(guān)鍵的Log了一下，1000萬大小的Set，復(fù)雜度也只是幾十不到。當(dāng)然，如果一次命中很多元素M很大那誰也沒辦法了。
用Multi(Start Transaction)、Exec(Commit)、Discard(Rollback)實(shí)現(xiàn)。 在事務(wù)提交前，不會執(zhí)行任何指令，只會把它們存到一個隊(duì)列里，不影響其他客戶端的操作。在事務(wù)提交時，批量執(zhí)行所有指令。《Redis設(shè)計與實(shí)現(xiàn)》中的詳述。
注意，Redis里的事務(wù)，與我們平時的事務(wù)概念很不一樣：
它僅僅是保證事務(wù)里的操作會被連續(xù)獨(dú)占的執(zhí)行。因?yàn)槭菃尉€程架構(gòu)，在執(zhí)行完事務(wù)內(nèi)所有指令前是不可能再去同時執(zhí)行其他客戶端的請求的。它沒有隔離級別的概念，因?yàn)槭聞?wù)提交前任何指令都不會被實(shí)際執(zhí)行，也就不存在”事務(wù)內(nèi)的查詢要看到事務(wù)里的更新，在事務(wù)外查詢不能看到”這個讓人萬分頭痛的問題。它不保證原子性——所有指令同時成功或同時失敗，只有決定是否開始執(zhí)行全部指令的能力，沒有執(zhí)行到一半進(jìn)行回滾的能力。在redis里失敗分兩種，一種是明顯的指令錯誤，比如指令名拼錯，指令參數(shù)個數(shù)不對，在2.6版中全部指令都不會執(zhí)行。另一種是隱含的，比如在事務(wù)里，第一句是SET foo bar， 第二句是LLEN foo，對第一句產(chǎn)生的String類型的key執(zhí)行LLEN會失敗，但這種錯誤只有在指令運(yùn)行后才能發(fā)現(xiàn)，這時候第一句成功，第二句失敗。還有，如果事務(wù)執(zhí)行到一半redis被KILL，已經(jīng)執(zhí)行的指令同樣也不會被回滾。Watch指令，類似樂觀鎖，事務(wù)提交時，如果Key的值已被別的客戶端改變，比如某個list已被別的客戶端push/pop過了，整個事務(wù)隊(duì)列都不會被執(zhí)行。
Redis2.6內(nèi)置的Lua Script支持，可以在Redis的Server端一次過運(yùn)行大量邏輯，就像存儲過程一樣，避免了海量中間數(shù)據(jù)在網(wǎng)路上的傳輸。
Lua自稱是在Script語言里關(guān)于快的標(biāo)準(zhǔn)，Redis選擇了它而不是流行的javaScript。因?yàn)镽edis的單線程架構(gòu)，整個Script默認(rèn)是在一個事務(wù)里的。Script里涉及的所有Key盡量用變量，從外面?zhèn)魅耄筊edis一開始就知道你要改變哪些key。(but why?)Eval每次傳輸一整段Script比較費(fèi)帶寬，可以先用Script Load載入script，返回哈希值。然后用EvalHash執(zhí)行。因?yàn)榫褪荢HA-1，所以任何時候執(zhí)行返回的哈希值都是一樣的。內(nèi)置的Lua庫里還很貼心的帶了CJSON，可以處理json字符串。一段用Redis做Timer的示例代碼，下面的script被定期調(diào)用，從以觸發(fā)時間為score的sorted set中取出已到期的Job，放到list中給Client們blocking popup。| 12345678910111213141516 | -- 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 |
| 1 |
官方文檔 與 《Redis設(shè)計與實(shí)現(xiàn)》中的詳述，過期數(shù)據(jù)的清除從來不容易，為每一條key設(shè)置一個timer，到點(diǎn)立刻刪除的消耗太大，每秒遍歷所有數(shù)據(jù)消耗也大，Redis使用了一種相對務(wù)實(shí)的做法： 當(dāng)client主動訪問key會先對key進(jìn)行超時判斷，過時的key會立刻刪除。 如果clien永遠(yuǎn)都不再get那條key呢？ 它會在Master的后臺，每秒10次的執(zhí)行如下操作： 隨機(jī)選取100個key校驗(yàn)是否過期，如果有25個以上的key過期了，立刻額外隨機(jī)選取下100個key(不計算在10次之內(nèi))。可見，如果過期的key不多，它最多每秒回收200條左右，如果有超過25%的key過期了，它就會做得更多，但只要key不被主動get，它占用的內(nèi)存什么時候最終被清理掉只有天知道。
數(shù)據(jù)準(zhǔn)備： 預(yù)加載兩千萬條數(shù)據(jù)，占用10G內(nèi)存。
測試工具：自帶的redis-benchmark，默認(rèn)只是基于一個很小的數(shù)據(jù)集進(jìn)行測試，調(diào)整命令行參數(shù)如下，就可以開100條線程(默認(rèn)50)，SET 1千萬次(key在0-1千萬間隨機(jī))，key長21字節(jié)，value長256字節(jié)的數(shù)據(jù)。
| 1 | redis-benchmark-tSET-c100-n10000000-r10000000-d256 |
Redis-Cluster是今年工作重點(diǎn)，支持automatic re-sharding， 采用和Hazelcast類似的算法，總共有N個分區(qū)(eg.N=1024)，每臺Server負(fù)責(zé)若干個分區(qū)。
在客戶端先hash出key 屬于哪個分區(qū)，隨便發(fā)給一臺server，server會告訴它真正哪個Server負(fù)責(zé)這個分區(qū)，緩存下來，下次還有該分區(qū)的請求就直接發(fā)到地兒了。Re-sharding時，會將某些分區(qū)的數(shù)據(jù)移到新的Server上，完成后各Server周知分區(qū)<->Server映射的變化，因?yàn)榉謪^(qū)數(shù)量有限，所以通訊量不大。 在遷移過程中，客戶端緩存的依然是舊的分區(qū)映射信息，原server對于已經(jīng)遷移走的數(shù)據(jù)的get請求，會返回一個臨時轉(zhuǎn)向的應(yīng)答，客戶端先不會更新Cache。等遷移完成了，就會像前面那樣返回一條永久轉(zhuǎn)向信息，客戶端更新Cache，以后就都去新server了。高可用性關(guān)乎系統(tǒng)出錯時到底會丟失多少數(shù)據(jù)，多久不能服務(wù)。要綜合考慮持久化，Master-Slave復(fù)制及Fail-Over配置，以及具體Crash情形，比如Master死了，但Slave沒死。或者只是Redis死了，操作系統(tǒng)沒死等等。
綜上所述，RDB的數(shù)據(jù)不實(shí)時，同時使用兩者時服務(wù)器重啟也只會找AOF文件。那要不要只使用AOF呢？作者建議不要，因?yàn)镽DB更適合用于備份數(shù)據(jù)庫(AOF在不斷變化不好備份)，快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。
因?yàn)镽DB文件只用作后備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規(guī)則。
如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數(shù)據(jù)，啟動腳本較簡單只load自己的AOF文件就可以了。代價一是帶來了持續(xù)的IO，二是AOF rewrite的最后將rewrite過程中產(chǎn)生的新數(shù)據(jù)寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應(yīng)該盡量減少AOF rewrite的頻率，AOF重寫的基礎(chǔ)大小默認(rèn)值64M太小了，可以設(shè)到5G以上。默認(rèn)超過原大小100%大小時重寫可以改到適當(dāng)?shù)臄?shù)值，比如之前的benchmark每個小時會產(chǎn)生40G大小的AOF文件，如果硬盤能撐到半夜系統(tǒng)閑時才用cron調(diào)度bgaofrewrite就好了。
如果不Enable AOF ，僅靠Master-Slave Replication 實(shí)現(xiàn)高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統(tǒng)波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數(shù)據(jù)，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構(gòu)，見Tim的博客
現(xiàn)象描述：當(dāng)AOF rewrite 15G大小的內(nèi)存時，Redis整個死掉的樣子，所有指令甚至包括slave發(fā)到master的ping，redis-cli info都不能被執(zhí)行。
原因分析：
官方文檔，由IO產(chǎn)生的Latency詳細(xì)分析, 已經(jīng)預(yù)言了悲劇的發(fā)生，但一開始沒留意。Redis為求簡單，采用了單請求處理線程結(jié)構(gòu)。打開AOF持久化功能后， Redis處理完每個事件后會調(diào)用write(2)將變化寫入kernel的buffer，如果此時write(2)被阻塞，Redis就不能處理下一個事件。Linux規(guī)定執(zhí)行write(2)時，如果對同一個文件正在執(zhí)行fdatasync(2)將kernel buffer寫入物理磁盤，或者有system wide sync在執(zhí)行，write(2)會被block住，整個Redis被block住。如果系統(tǒng)IO繁忙，比如有別的應(yīng)用在寫盤，或者Redis自己在AOF rewrite或RDB snapshot(雖然此時寫入的是另一個臨時文件，雖然各自都在連續(xù)寫，但兩個文件間的切換使得磁盤磁頭的尋道時間加長），就可能導(dǎo)致fdatasync(2)遲遲未能完成從而block住write(2)，block住整個Redis。為了更清晰的看到fdatasync(2)的執(zhí)行時長，可以使用”strace -p (pid of redis server) -T -e -f trace=fdatasync”，但會影響系統(tǒng)性能。Redis提供了一個自救的方式，當(dāng)發(fā)現(xiàn)文件有在執(zhí)行fdatasync(2)時，就先不調(diào)用write(2)，只存在cache里，免得被block。但如果已經(jīng)超過兩秒都還是這個樣子，則會硬著頭皮執(zhí)行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設(shè)為everysec時丟失數(shù)據(jù)的可能性的最嚴(yán)謹(jǐn)說法是：如果有fdatasync在長時間的執(zhí)行，此時redis意外關(guān)閉會造成文件里不多于兩秒的數(shù)據(jù)丟失。如果fdatasync運(yùn)行正常，redis意外關(guān)閉沒有影響，只有當(dāng)操作系統(tǒng)crash時才會造成少于1秒的數(shù)據(jù)丟失。解決方法：最后發(fā)現(xiàn)，原來是AOF rewrite時一直埋頭的調(diào)用write(2)，由系統(tǒng)自己去觸發(fā)sync。在RedHat Enterprise 6里，默認(rèn)配置vm.dirty_background_ratio=10，也就是占用了10%的可用內(nèi)存才會開始后臺flush，而我的服務(wù)器有64G內(nèi)存。很明顯一次flush太多數(shù)據(jù)會造成阻塞，所以最后果斷設(shè)置了sysctl vm.dirty_bytes=33554432(32M)，問題解決。
然后提了個issue，AOF rewrite時定時也執(zhí)行一下fdatasync嘛， antirez三分鐘后就回復(fù)了，新版中，AOF rewrite時32M就會重寫主動調(diào)用fdatasync。
有時候明明master/slave都活得好好的，突然間就說要重新進(jìn)行全同步了：
1.Slave顯示：# MASTER time out: no data nor PING received…
slave會每隔repl-ping-slave-period(默認(rèn)10秒)ping一次master，如果超過repl-timeout(默認(rèn)60秒)都沒有收到響應(yīng)，就會認(rèn)為Master掛了。如果Master明明沒掛但被阻塞住了也會報這個錯。可以適當(dāng)調(diào)大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.
當(dāng)slave沒掛但被阻塞住了，比如正在loading Master發(fā)過來的RDB， Master的指令不能立刻發(fā)送給slave，就會放在output buffer中(見oll是命令數(shù)量，omem是大小)，在配置文件中有如下配置：client-output-buffer-limit slave 256mb 64mb 60， 這是說負(fù)責(zé)發(fā)數(shù)據(jù)給slave的client，如果buffer超過256m或者連續(xù)60秒超過64m，就會被立刻強(qiáng)行關(guān)閉！！！ Traffic大的話一定要設(shè)大一點(diǎn)。否則就會出現(xiàn)一個很悲劇的循環(huán)，Master傳輸一個大的RDB給Slave，Slave努力的裝載，但還沒裝載完，Master對client的緩存滿了，再來一次。
平時可以在master執(zhí)行 redis-cli client list 找那個cmd=sync，flag=S的client，注意OMem的變化。
Redis-sentinel是2.6版開始加入的另一組獨(dú)立運(yùn)行的節(jié)點(diǎn)，提供自動Fail Over的支持。
官方文檔 與 Redis核心解讀–集群管理工具(Redis-sentinel)antirez 對 Sentinel的反駁，與下篇master地址在sentinel.conf里, sentinel會每10秒一次向master發(fā)送INFO，知道m(xù)aster的slave有哪些。 如果master已經(jīng)變?yōu)閟lave，sentinel會分析INFO的應(yīng)答指向新的master。以前，sentinel重啟時，如果master已經(jīng)切換過了，但sentinel.conf里master的地址并沒有變，很可能有悲劇發(fā)生。另外master重啟后如果沒有切換成slave，也可能有悲劇發(fā)生。新版好像修復(fù)了一點(diǎn)這個問題，待研究。
另外，sentinel會在master上建一個pub/sub channel，名為”sentinel:hello”，通告各種信息，sentinel們也是通過接收pub/sub channel上的+sentinel的信息發(fā)現(xiàn)彼此，因?yàn)槊颗_sentinel每5秒會發(fā)送一次自己的host信息，宣告自己的存在。
覺得Sentinel至少有兩個可提升的地方:
一是如果master 主動shutdown，比如系統(tǒng)升級，有辦法主動通知sentinel提升新的master，減少服務(wù)中斷時間。二是比起redis-server太原始了，要自己丑陋的以nohup sentinel > logfile 2>&1 & 啟動，也不支持shutdown命令，要自己kill pid。基于Sentinel的方案，client需要執(zhí)行語句SENTINEL get-master-addr-by-name mymaster 可獲得當(dāng)前master的地址。 Jedis正在集成sentinel，已經(jīng)支持了sentinel的一些指令，但還沒發(fā)布，但sentinel版的連接池則暫時完全沒有，在公司的項(xiàng)目里我參考網(wǎng)友的項(xiàng)目自己寫了一個。
淘寶的Tedis driver，使用了完全不同的思路，不基于Sentinel，而是多寫隨機(jī)讀， 一開始就同步寫入到所有節(jié)點(diǎn)，讀的話隨便讀一個還活著的節(jié)點(diǎn)就行了。但有些節(jié)點(diǎn)成功有些節(jié)點(diǎn)失敗如何處理? 節(jié)點(diǎn)死掉重新起來后怎么重新同步?什么時候可以重新Ready? 所以不是很敢用。
另外如Ruby寫的redis_failover，也是拋開了Redis Sentinel，基于ZooKeeper的臨時方案。
Redis作者也在博客里抱怨怎么沒有人做Dynamo-style 的client。
約30個配置項(xiàng)，全都有默認(rèn)配置，對redif.conf默認(rèn)配置的修改見附錄1。
綜述： Redis監(jiān)控技巧
Info指令將返回非常豐富的信息。 著重監(jiān)控檢查內(nèi)存使用，是否已接近上限，used_memory是Redis申請的內(nèi)存，used_memory_rss是操作系統(tǒng)分配給Redis的物理內(nèi)存，兩者之間隔著碎片，隔著Swap。 還有重點(diǎn)監(jiān)控 AOF與RDB文件的保存情況，以及master-slave的關(guān)系。Statistic 信息還包括key命中率，所有命令的執(zhí)行次數(shù)，所有client連接數(shù)量等， CONFIG RESETSTAT 可重置為0。
Monitor指令可以顯示Server收到的所有指令，主要用于debug，影響性能，生產(chǎn)環(huán)境慎用。
SlowLog 檢查慢操作(見2.性能)。
官網(wǎng)列出了如下工具，但暫時沒發(fā)現(xiàn)會直接拿來用的：
Redis Live，基于Python的web應(yīng)用，使用Info和Monitor獲得系統(tǒng)情況和指令統(tǒng)計分析。 因?yàn)镸onitor指令影響性能，所以建議用cron定期運(yùn)行，每次偷偷采樣兩分鐘的樣子。phpRedisAdmin，基于php的Web應(yīng)用，目標(biāo)是MysqlAdmin那樣的管理工具，可以管理每一條Key的情況，但它的界面應(yīng)該只適用于Key的數(shù)量不太多的情況，Demo。Redis Faina，基于Python的命令行，Instagram出品，用戶自行獲得Monitor的輸出后發(fā)給它進(jìn)行統(tǒng)計分析。由于Monitor輸出的格式在Redis版本間不一樣，要去github下最新版。Redis-rdb-tools 基于Python的命令行，可以分析RDB文件每條Key對應(yīng)value所占的大小，還可以將RDB dump成普通文本文件然后比較兩個庫是否一致，還可以將RDB輸出成JSON格式，可能是最有用的一個了。Redis Sampler，基于Ruby的命令行，antirez自己寫的，統(tǒng)計數(shù)據(jù)分布情況。各個Driver好像只有Jedis比較活躍，但也5個月沒提交了，也是Java里唯一的Redis官方推薦。
Spring Data Redis的封裝并不太必要，因?yàn)镴edis已足夠簡單，沒有像Spring Data MongoDB對MongoDB java driver的封裝那樣大幅簡化代碼，頂多就是加強(qiáng)了一點(diǎn)點(diǎn)點(diǎn)pipeline和transaction狀態(tài)下的coding，禁止了一些此狀態(tài)下不能用的命令。而所謂屏蔽各種底層driver的差異并不太吸引人，因?yàn)槲揖蜎]打算選其他幾種driver。有興趣的可以翻翻它的JedisConnection代碼。
所以，SpringSide直接在Jedis的基礎(chǔ)上，按Spring的風(fēng)格封裝了一個JedisTemplate，負(fù)責(zé)從池中獲取與歸還Jedis實(shí)例，處理異常。
Jedis基于Apache Commons Pool做的連接池，默認(rèn)MaxActive最大連接數(shù)只有8，必須重新設(shè)置。而且MaxIdle也要相應(yīng)增大，否則所有新建的連接用完即棄，然后會不停的重新連接。
另外Jedis設(shè)定了每30秒對所有連接執(zhí)行一次ping，以發(fā)現(xiàn)失效的連接，這樣每30秒會有一個拿不到連接的高峰。但效果如何需要獨(dú)立分析。比如系統(tǒng)高峰之后可能有一長段時間很閑，而且Redis Server那邊做了Timeout控制會把連接斷掉，這時候做idle checking是有意義的，但30秒一次也太過頻繁了。否則關(guān)掉它更好。
Jedis的blocking pop函數(shù)，應(yīng)用執(zhí)行ExecutorService.shutdownNow()中斷線程時并不能把它中斷，見討論組。兩個解決方法：
不要用不限時的blocking popup，傳多一個超時時間參數(shù)，如5秒。找地方將調(diào)用blocking popup的jedis保存起來，shutdown時主動調(diào)用它的close。Windows版本方便對應(yīng)用的本地開發(fā)調(diào)試，但Redis并沒有提供，好在微軟提供了一個依賴LibUV實(shí)現(xiàn)兼容的補(bǔ)丁，https://github.com/MSOpenTech/redis，但redis作者拒絕合并到master中，微軟只好苦憋的時時人工同步。 目前的穩(wěn)定版是2.6版本，支持Lua腳本。
因?yàn)間ithub現(xiàn)在已經(jīng)沒有Download服務(wù)了，所以編譯好的可執(zhí)行文件藏在這里：
https://github.com/MSOpenTech/redis/tree/2.6/bin/release注：下文中的鏈接都是網(wǎng)站的架構(gòu)描述文檔。
Twitter和新浪微博， 都屬于將Redis各種數(shù)據(jù)結(jié)構(gòu)用得出神入化的那種，如何發(fā)布大V如奧巴馬的消息是它們最頭痛的問題。
Tumblr： 11億美刀賣給Yahoo的圖片日志網(wǎng)站，22 臺Redis server，每臺運(yùn)行8 – 32個實(shí)例，總共100多個Redis實(shí)例在跑。有著Redis has been completely problem free and the community is great的崇高評價。Redis在里面扮演了八爪魚多面手的角色：
Dashboard的海量通知的存儲。Dashboard的二級索引。存儲海量短鏈接的HBase前面的緩存。Gearman Job Queue的存儲。正在替換另外30臺memcached。Instagram ，曾經(jīng)，Redis powers their main feed, activity feed, sessions system, and other services。但可惜目前已遷往Cassandra，說新架構(gòu)只需1/4的硬件費(fèi)用，是的，就是那個導(dǎo)致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只用于創(chuàng)建新需求用到的sorted set，300K QPS的大壓力。日本微信 ，Redis在前負(fù)責(zé)異步Job Queue和O(n)的數(shù)據(jù)，且作為O(n*t)數(shù)據(jù)的cache，HBase在后，負(fù)責(zé)O(n*t)數(shù)據(jù)， n是用戶，t是時間。StackOverflow ，2 Redis servers for distribute caching，好窮好輕量。Github，任務(wù)系統(tǒng)Resque的存儲。Discourge，號稱是為下一個十年打造的論壇系統(tǒng)， We use Redis for our job queue, rate limiting, as a cache and for transient data，剛好和我司的用法一樣。extension modules項(xiàng)目封裝了常用的函數(shù)與場景，showcase example的src/demo/redis目錄里有各場景的benchmark測試。
典型的Spring Template風(fēng)格，和JdbcTemplate，HibernateTemplate一樣，封裝從JedisPool獲取與歸還Connecton的代碼，有帶返回值與無返回值兩種返回接口。同時，對最常用的Jedis調(diào)用，直接封裝了一系列方法。
Scheduler實(shí)現(xiàn)了基于Redis的高并發(fā)單次定時任務(wù)分發(fā)。具體選型見Scheduler章節(jié)。
Master Elector基于redis setNx()與expire()兩個api實(shí)現(xiàn)，與基于Zookeeper，Hazelcast實(shí)現(xiàn)的效果類似。
計有Session，Counter，Scheduler 與 Master Elector四款。
新聞熱點(diǎn)
疑難解答
圖片精選
