馬上要從有道離職。除了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就是個快取，理論上幹掉獨立的“快取服務”是完全可行的。