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

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

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

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

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

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

但是，突然有一天，翻譯的服務掛了，無任何響應。

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

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

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

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

至于缺點，就非常嚴重了。

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

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

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

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

更多信息請查看IT技術專欄