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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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