馬上要從有道離職。除了MSRA實習(xí)外人生第一份正式工作即將結(jié)束，在這個隆重的時刻自然是需要寫點東西紀(jì)念一番。感性的文字不著急寫，作為一個搞技術(shù)的，當(dāng)然還是先寫點技術(shù)文章爭取對同行有所幫助。所以第一篇呢，湊個熱鬧，redis3.0正式版剛發(fā)布，就先說說redis cluster吧。

我在有道引入redis cluster是14年8月，到現(xiàn)在已經(jīng)8個月了。在當(dāng)時那個時間點，有道至少是詞典在緩存這塊的基礎(chǔ)設(shè)施搭建還是比較薄弱的，翻譯用memcache，簡單的客戶端寫死配置來分片；詞典的各種服務(wù)如果需要緩存基本上是單獨搭一個redis實例，因為公司機器比較弱，大內(nèi)存機器太少，所以通常是幾個服務(wù)用一個實例，沒有主從，純單點。于是N個服務(wù)有M個redis實例，每個示例數(shù)據(jù)量、qps完全無法維護，基本上是某個服務(wù)的某個開發(fā)記得哪個redis的host和port，就在自己維護的服務(wù)上用哪個的節(jié)奏。

當(dāng)然因為我們也不把redis當(dāng)數(shù)據(jù)庫，只當(dāng)做一個單純的緩存，所以掛了的結(jié)果就是redis超時之后請求全落在下層存儲上。感謝redis還是足夠穩(wěn)定，也感謝貴司的挫機器掛了這么多也沒在redis所在機器上掛過，至少我印象中redis單點掛掉這種事情還沒發(fā)生，即使后來因為個人風(fēng)格問題有的人寫的服務(wù)是一旦redis掛了徹底不能用，也暫時沒出過這個問題。倒是惠惠前段時間（那邊暫時沒用任何redis的集群方案）因為redis占用內(nèi)存滿了然后掛過……

然后是那年7月底，redis的3.0出了beta8，后來證明是最后一個beta，微博上有些號就發(fā)了類似新聞的東西，大概介紹了下3.0開始支持cluster。因為詞典實際上除了主查詢服務(wù)和翻譯的訪問量非常大之外（而詞典不用獨立的緩存服務(wù)，翻譯用memcache），其他服務(wù)的訪問量和緩存的數(shù)據(jù)量基本上單機（即使是有道那些稍微挫了點的機器）的redis全都能搞定。我對cluster感興趣的主要原因其實是為了把散亂的緩存資源整合到一起，大家所有服務(wù)公用一個redis集群，實現(xiàn)資源利用的最大化。于是簡單看了下redis cluster的設(shè)計：P2P，gossip，smart client。前兩者因為跟Cassandra一樣，對我來說比較親切，而不像一些人對去中心化的結(jié)構(gòu)總是抱有懷疑的態(tài)度。至于smart client，就意味著客戶端連接redis的driver必須額外開發(fā)支持redis cluster的協(xié)議才能用，而這也是我認(rèn)為當(dāng)前甚至中短期內(nèi)redis cluster最大的問題。當(dāng)然這也意味著他理論上的延遲會比其他proxy的方案低（畢竟不需要多一次請求和數(shù)據(jù)的轉(zhuǎn)發(fā)）。

然后我就搭了個測試用的redis集群，redis cluster的設(shè)計在這塊有點奇葩，跟集群相關(guān)的操作需要一個外部的ruby腳本來協(xié)助（當(dāng)然可能是為了讓主程序的代碼足夠簡潔？），然后那個腳本還只支持填實例的ip不支持host，還不告訴你不支持讓你用host之后各種莫名其妙（不知道后來改進沒）。不過反正也不是很經(jīng)常用到，也無所謂了。還是那個原因——機器比較少——于是所有節(jié)點都是master，沒slave。做了各種測試，壓力測試遇到個問題是max和.99的響應(yīng)時間高的莫名其妙，然后后來發(fā)現(xiàn)是因為默認(rèn)開了bgsave，在fork的時候會導(dǎo)致停止響應(yīng)，關(guān)掉bgsave開aof就搞定了。然后試了下讓其中1個實例掛掉，發(fā)現(xiàn)整個redis cluster都不可用了，即使是有active的節(jié)點所服務(wù)的slot也不能讀寫，而且這是故意這么干的，這設(shè)計簡直腦殘。但我權(quán)衡了下利弊，無視了這個腦殘設(shè)計，決定還是找個訪問量即使是全落在mysql也能抗住的線上服務(wù)先試試……（當(dāng)然好在后來10月份rc1發(fā)布的時候添加了一個“cluster-require-full-coverage no”的配置允許某些slot沒有active節(jié)點的時候其余slot還能用。）于是從當(dāng)時是全公司最牛逼的一批機器（64G內(nèi)存、E5620的CPU……）里找了兩臺比較閑的（還有其他低load的服務(wù)在跑），各搭了8個實例，一共16個，搭出了準(zhǔn)備給一套線上用的集群……我很好奇這是不是全球用戶量超過千萬的公司中第一批甚至第一個用于生產(chǎn)環(huán)境的redis cluster……

cluster搭好了，上層應(yīng)用該遷移了。幸虧我們是個java公司，jedis可能是各種語言的redis driver里第一個能用來連cluster的（官方出了個ruby的當(dāng)例子不算），沒準(zhǔn)至今還是唯一一個，但實際使用的時候發(fā)現(xiàn)非常坑爹——很多功能支持不全。比如JedisCluster作為接口類，各種byte[]相關(guān)的接口不支持只能String；比如無論你的timeout設(shè)成多少，JedisCluster請求的時候timeout永遠是2000ms（這個在今年3月出的2.7.0才改對）。雖然說框架寫好之后基于單機版本把JedisCluster改成自己想要的功能不算很難也不麻煩（我們在遷移的時候也確實這么做了），但終究是有工作量的，對技術(shù)能力弱一些的公司，完全就不現(xiàn)實了。更別說其他語言根本沒法用了。總之就是一頓改jedis后，在一段時間內(nèi)冒著一旦某個實例掛掉整個集群都不可用的風(fēng)險（反正就兩臺機器，之前的單機也一樣是單點一直也沒啥事，所以非常淡定……），各種服務(wù)陸續(xù)切換上來了。然后翻譯看我們這邊基本靠譜就也在好像是9月或者10月也遷移過來了。也因為我們只當(dāng)他是緩存，所以基本不存在數(shù)據(jù)遷移的問題，緩存預(yù)熱的時候稍微控制下就可以抗住。然后我們就準(zhǔn)備過上幸福的生活了……

但是，突然有一天，翻譯的服務(wù)掛了，無任何響應(yīng)。

打個jstack看，最底下醒目的deadlock。一看，jedis干的。然后看代碼，發(fā)現(xiàn)維護集群meta信息的類里一堆synchronized方法和一堆非synchronized方法中間共用了一個讀寫鎖，一個線程把WriteLock鎖住后若干行會試圖執(zhí)行一個synchronized方法，另一個線程執(zhí)行別的synchronized方法時會在某行試圖獲取ReadLock，然后就喜聞樂見的死鎖了，這簡直太……了。更……的是其實那個類里所有的synchronized都是多余的，而最新的代碼里我發(fā)現(xiàn)他們已經(jīng)把synchronized去掉了，理由是為了提升性能。于是開issue跟他們說了下舊的代碼會死鎖，建議他們盡快把最新代碼發(fā)布新版，然后有人說雖然這是bug，但只要timeout別設(shè)成無窮，死鎖的代碼會自動超時釋放的，可我們明明把timeout設(shè)的很短好不好……總之懶得理論這些事情了，改了bug之后死鎖問題沒了，但翻譯被嚇尿了，切回memcache，也因為事多人少，直到現(xiàn)在也沒功夫重新?lián)Q回redis……

后來就沒遇到過問題了。于是開始總結(jié)吧。

首先先說前提：twemproxy作為老牌的redis集群方案，他確實在特定歷史階段實現(xiàn)了他的價值，但他肯定是不如現(xiàn)在的codis，具體codis哪好可以看很多文章介紹。

然后是官方cluster的優(yōu)點，其實真的只有一個，就是沒有proxy轉(zhuǎn)發(fā)之后極限性能好，但絕大多數(shù)場景真的不重要。非說第二個優(yōu)點就是他是官方的，只要redis還在維護，redis cluster被棄坑的概率就比較低，項目會持續(xù)有人維護，而第三方的方案理論上確實開發(fā)者棄坑的概率會比redis官方要大。不過只要第三方的方案真正成熟到一定程度，就算棄坑不更新大家也還是可以用。就像redis如果截止2.8.x就不開發(fā)了，大家照樣會用一樣。

至于缺點，就非常嚴(yán)重了。

第一個缺點就是嚴(yán)格依賴客戶端driver的成熟度，redis單機方案之所以火很大程度是因為一整套方案都成熟穩(wěn)定，目前各個語言的redis單機client基本非常成熟。而redis cluster的client功能不完備或者功能完備但有bug都不能忍，自己開發(fā)維護cluster client的代價又太高，大多數(shù)團隊也不能忍，更何況可能一樣有bug。如果把redis cluster設(shè)計成類似Cassandra，請求集群中任何一個節(jié)點都可以負(fù)責(zé)轉(zhuǎn)發(fā)請求，client會好寫一些，甚至可能支持用單機driver來請求cluster實現(xiàn)平滑升級，但多一次轉(zhuǎn)發(fā)之后相對于proxy的方案就完全沒有性能優(yōu)勢了。這個缺點在當(dāng)前很嚴(yán)重，業(yè)務(wù)等不起，幾個月后可能java不是問題、一兩年后可能其他主流語言也不是問題，但還是那句話，業(yè)務(wù)不等人，你這一兩年怎么辦？當(dāng)然不如直接用codis。

第二個缺點完全是設(shè)計問題了，就是一個redis進程既負(fù)責(zé)讀寫數(shù)據(jù)又負(fù)責(zé)集群交互，雖然設(shè)計者已經(jīng)盡可能簡化了代碼和邏輯，但還是讓redis從一個內(nèi)存NoSQL變成了一個分布式NoSQL。分布式系統(tǒng)很容易有坑，一旦有坑必須升級redis，這就會涉及到某段時間內(nèi)不同版本共存的問題。即使是相對比較成熟的Cassandra，也在最近的版本中出現(xiàn)過當(dāng)集群中存在不止一個版本的節(jié)點時一定概率meta信息無法正常獲取的bug，何況剛發(fā)布第一個正式版的redis。這還只是其中一種可能的坑，分布式系統(tǒng)的坑多了去了……

關(guān)于redis cluster的設(shè)計，Gossip/P2P的去中心化架構(gòu)本身不是問題，但一旦有了中心節(jié)點，能做的事情就多了，比如sharding不均勻是很容易自動rebalance的，而無中心的只能靠外界來搞。然后redis cluster又是slot的形式而非C*式的一致性哈希，新節(jié)點分slot又不自動，依賴外界（ruby腳本）來分配顯得不方便更不優(yōu)美和諧。而且因為是master-slave的系統(tǒng)而非W+R>N的那種，master掛掉之后盡快發(fā)現(xiàn)是比較重要的，gossip對于節(jié)點掛掉的發(fā)現(xiàn)終究沒有中心節(jié)點/zookeeper方便快速。不知道有沒有其他系統(tǒng)是gossip+主從的模式。

redis作為一個非常成功的NoSQL，其協(xié)議其實是可以發(fā)揚光大的，基于proxy做轉(zhuǎn)發(fā)意味著屏蔽了下層存儲，完全可以根據(jù)前綴/tag/冷熱程度，來把部分甚至大多數(shù)數(shù)據(jù)放在磁盤從而節(jié)約成本又保證一致性，這都是有中心節(jié)點所帶來的好處。前段時間跟劉奇聊的時候發(fā)現(xiàn)codis也確實是這么打算的。對于只需要NoSQL的業(yè)務(wù)來說，將持久層和緩存簡化成一個顯然是最方便的，一個set、一個get就能搞定，并且不需要業(yè)務(wù)自己維護緩存和持久化的一致性，也更安全。當(dāng)然這種讓redis協(xié)議支持磁盤讀寫的競爭對手就是那些原本就是磁盤上的NoSQL直接開內(nèi)存緩存，比如Cassandra這種LSM的數(shù)據(jù)庫，memtable天生就是放最近寫入的數(shù)據(jù)，通常最近寫入也可能被讀??；加上本身支持row cache就是個緩存，理論上干掉獨立的“緩存服務(wù)”是完全可行的。

更多信息請查看IT技術(shù)專欄