阿里雲專訪Redisson做者Rui Gu：構建開源企業級Redis客戶端之路

摘要： 本文爲阿里雲同窗在RedisConf2018上對Redisson開源客戶端做者Rui Gu作的一個專訪，主要介紹了Rui Gu參與開啓Redisson客戶端開發的歷程，同時也詳細介紹了Redisson的架構模型還有在分佈式鎖上的工做，最後Rui Gu介紹了Redisson和開源的協做，同時介紹了後續Redisson客戶端的長期發展目標。

筆者表明阿里雲參加了RedisConf 2018的會議，在會議上對開源Redisson客戶端的做者Rui Gu作了一個訪談，Rui Gu在Redis社區國際上的影響力還有在開源上的工做給筆者留下了深入的印象，如下是訪談的具體內容。

以上照片爲阿里雲夏周、Rui Gu、阿里雲白宸、阿里澤賢

當初爲何參與設計開發Redisson？

自04年從事工業自動化、工業IoT工做至今，涉及到不少場景須要對一系列設備進行監控和信號處理等工做。該類場景對實時處理能力，系統穩定性，高可用性，容災能力等等要求很是高。從12年時決定採用Redis做爲實時數據庫時就產生了許多想法。Redis與Java這樣的編程語言中的經常使用數據結構看似相像卻又不一樣，一直但願可以用什麼方法將二者聯繫起來。13年開始商用Redis之後這種想法越增強烈。因而在工做之餘自行開始了一些相關的摸索與實踐，最終決定採用動態類的形式讓Redis的數據結構操做起來更像Java對應的結構。誰知遠在莫斯科的Nikita彷佛也有相似的想法，他從14年元旦便開始了實際應用的開發，並很快的開源了Redisson。於此同時個人實踐也有了許些進展，並初步的實現了一些基本功能。不過因爲工做上的種種緣由，再加上當時本身也缺少足夠的信心，畢竟這是條沒人走過的路，大半年過去了進展比較緩慢。卻不知Nikita面對這一樣的問題，可是他不只艱難地堅持了下來，並且絲毫沒有放棄的意思。14年下半年時我開始注意到了Redisson項目，仔細瞭解了之後頓時產生了很強的共鳴，雖然和個人實踐有着一樣的理念卻又是不一樣的出發點。因而乎，在有了這樣的火花之後，咱們開始了相互之間的溝通和交流，最後在15年初時決定，放棄本身的實踐項目，加入Redisson。至此，在這條沒人走過的路上咱們再也不獨行。

Redisson解決了什麼問題？相比其餘Redis客戶端它有什麼優點？

2.1）IoT行業裏，一組設備的各類實時狀態值每每是做爲一個具備業務意義的對象，由JVM管理在內存裏，若是將這個對象存儲到Redis數據庫的String結構裏，每次更新一個狀態值，就須要作一次序列化和反序列化。同時還有可能面臨着同一時刻操做同一個對象的不一樣狀態值帶來的併發難題。實際應用時採用了Redis提供的Hash數據結構來儲存這個對象，只有這樣纔能有效地避免這類問題的發生。儘管Redis的Hash結構和Java裏的HashMap極爲類似，可是在程序操做Redis的時候不能像操做HashMap同樣便捷。並且若是對Redis相關命令的用法不能稔熟於心，或在細節之到處理不當，便會最終形成業務上的各類問題。Redisson的Map就是爲了填補Redis的Hash和Java的HashMap二者之間的空缺而產生。

圖1 - Jedis的Hash操做

圖2 - Java的ConcurrentHashMap

圖3 - Redisson的ConcurrentHashMap

2.2）工控和某些IoT場景對實時處理能力要求很高，全部的信號都必須實現毫秒級響應。這類場景還具備併發量巨大的特色。與社交電商等場景不一樣的是這類應用場景基本沒有峯谷流量，時時刻刻都是峯值。所以其它場景裏常見的削峯填谷措施在這裏只能加劇負擔。在這樣的場景下若是使用像Jedis這樣採用同步編程模型的客戶端時，就須要隨時確保併發線程數與鏈接數一對一，不然獲取不到可用鏈接會直接報錯。相比之下Redisson利用了Netty異步編程框架，使用了與Redis服務端結構相似的事件循環（EventLoop）式的線程池，並結合鏈接池的方式彈性管理鏈接。最終作到了使用少許的鏈接既能夠知足對大量線程的要求，從根本上緩解線程之間的競爭關係。同時異步操做的模式還可以避免數據請求形成業務線程的阻塞。

2.3）Redis 發展至今經歷了屢次技術變遷。官方版在迭代的過程當中不但增長了許多有用的功能，同時也發展了幾種高可用性方案。於此同時，社區和雲計算商在官方版上進而開發出了多種基於代理（Proxy）的高可用方案。相比之下，這些方案各有優劣，適用場景也各自不一。多樣化的方案在帶來便利的同時也帶來了麻煩。好比在業務擴容，從簡單的單機或主從模式遷移到哨兵或集羣模式；或是業務遷移，從自建的Redis環境遷移到雲上；亦或是項目的持續性交付CD/CI過程當中，不一樣的階段使用不一樣Redis運行模式等等狀況。每每須要開發人員針對不一樣的高可用方案開發出一套與之匹配的使用方法。使得一個項目對Redis運行模式的耦合度高，在Redis運行模式變化時就必須更改業務代碼。Redisson針對這種狀況提供了一套便捷的文件化配置方法，在無需修改程序代碼的狀況下，經過不一樣的JSON，YAML或SpringXML文件實現對不一樣Redis運行模式和環境的支持。這既下降了開發難度，也下降了運維難度。

Redisson在分佈式鎖方面的工做很是多，可否介紹下這方面的實踐？
對於Redis分佈式鎖的實現方式，網上討論相關文章都基本都「爛大街」了。然而幾乎全部相關介紹都是在單純使用setnx命令的基礎上進行一個簡單封裝，且少有文章分析這樣設計的缺陷。在這個博客滿天飛，代碼隨便貼的時代，這樣的局面無形之中給了你們一個假象，就是Redis分佈式鎖只能是以這樣簡單的形式存在，即使有缺陷也只能在業務代碼裏規避。那麼爲何不換位思考一下，即用稍微複雜點的設計來彌補它的不足，從而換取業務上的靈活性呢？再從新設計Redis分佈式鎖以前，咱們先了解一下單純使用setnx命令封裝的分佈式鎖有哪些不足。
1). 不具有可重入性
在執行setnx命令時，一般採用業務上指定的名稱做爲key名，用時間或隨機值做爲value來實現。這樣的實現方式不具有追蹤請求線程的能力，同時也不具有統計重入次數的能力，甚至有些實現方式都不具有操做的原子性。當遇到業務上須要在多個地方用到一樣一個鎖的時候，很顯然使用不具備可重入的鎖會很容易發生死鎖的現象。特別是在有遞歸邏輯的場景裏，發生死鎖的概率會更高。Java併發工具包裏的Lock對象和sychronized語塊都具備可重入性，對於常用這些工具的人來講，每每會很容易忽略setnx的這個缺陷。

2). 不支持續約
在分佈式環境中，爲了保證鎖的活性和避免程序宕機形成的死鎖現象，分佈式鎖每每會引入一個失效時間，超過這個時間則認爲自動解鎖。這樣的設計前提是開發人員對這個自動解鎖時間的粒度有一個很好的把握，過短了可能會出現任務沒作完鎖就失效了，而太長了在出現程序宕機或業務節點掛掉時，其它節點須要等很長時間才能恢復，而難以保證業務的SLA。setnx的設計缺少一個延續有效期的續約機制，沒法保證業務可以先工做作完再解鎖，也不能確保在某個程序宕機或業務節點掛掉的時候，其它節點可以很快的恢復業務處理能力。

3). 不具有阻塞的能力
日常你們多少都接觸過的鎖，因爲加鎖策略（Locking Strategy）的差異，使得每種鎖都有各自不一樣的特性。可是在一般狀況下這些鎖都具有兩個共性：一是互斥性，二是阻塞性。互斥性是指在任什麼時候刻最多隻能有一個線程得到通行的資格。阻塞性是指的在有競爭的狀況下，未獲取到資源的線程會中止繼續操做，直到成功獲取到資源或取消操做。很顯然setnx命令只提供了互斥的特性，卻沒有提供阻塞的能力。雖然在業務代碼裏能夠引入自旋機制來進行再次獲取，但這僅僅是把本來應該在鎖裏實現的功能搬到了業務代碼裏，經過增長業務代碼的複雜程度來簡化鎖的實現彷佛顯得有點南轅北轍。

Redisson的分佈式鎖在知足以上三個基本要求的同時還增長了線程安全的特色。利用Redis的Hash結構做爲儲存單元，將業務指定的名稱做爲key，將隨機UUID和線程ID做爲field，最後將加鎖的次數做爲value來儲存。同時UUID做爲鎖的實例變量保存在客戶端。將UUID和線程ID做爲標籤在運行多個線程同時使用同一個鎖的實例時，仍然保證了操做的獨立性，知足了線程安全的要求。

加鎖時經過Lua腳本先檢查鎖是否存在，如不存在則建立hash相關字段並設定過時時間後返回，這表示加鎖成功。若是該hash字段已經存在，再檢查隨機字段和線程id是否一致。若是一致則遞增value的值並從新更新過時時間後返回，此時表示同一節點同一線程再次成功加鎖，從而保證了可重入性。若是hash存在且字段不一致，說明其餘節點或線程已經擁有了這個鎖。所以Lua腳本返回這個hash的當前有效期。當結果返回到在客戶端後，若是加鎖成功，則經過線程池依照設定好的參數定時執行續約，最後通知請求線程繼續後續操做。若是加鎖沒有成功，則監聽一個以這個key爲後綴的pubsub頻道，直到收到解鎖消息後再次重試。

解鎖時經過Lua腳本先檢查鎖是否存在，若是已經不存在則直接發佈解鎖消息並返回。若是任然存在則檢查標籤是否存在，若是不存在則表示這個鎖並不爲本線程所擁有，這種狀況請求線程將收到報錯。若是存在則表示該鎖正是被該線程所擁有。在這種狀況下，遞減標籤字段後判斷，若是返回的加鎖數量仍然大於0，說明當前的鎖仍然有效，僅僅只是重入次數減小了。相反這表示鎖已經徹底解開，則當即刪除該鎖併發布解鎖信息。

Redisson的可重入鎖解決了setnx鎖的許多先天性不足，可是因爲它仍然是以單一一個key的方式儲存在固定的一個Redis節點裏，而且有自動失效期。這樣的設計雖然能夠很大程度上避免客戶端程序宕機或業務節點掛掉形成的影響，可是隨之帶來的弊端是遇到服務端Redis進程宕機或節點掛掉的狀況，仍是有可能會形成鎖的信息丟失，這樣的缺陷顯然沒法知足某些特定場景提出的高可用性要求。

介於這種狀況，Redis做者Salvatore提出了一個基於多個節點的高可用分佈式鎖的算法，起名叫紅鎖（RedLock： https://redis.io/topics/distlock）。在這種算法下，客戶端須要同時在多個節點裏同時嘗試獲取一個獨立的鎖，只有當一次性成功獲取了大多數鎖的狀況下才能被視爲贏得了高可用分佈式鎖，不然須要解除已經部分獲取到的鎖，等待一個隨機時間後再次重試。

在算法設計上，Salvatore依然採用的是setnx做爲舉例講解分佈式鎖的互斥特性。在算法實現上，Redisson的RedissonRedLock採用的是前面提到的更加靈活方便的可重入鎖。Redisson的擴展算法是Redis官網惟一承認的Java實現。

雖然Redlock的算法提供了高可用的特性，但創建在大多數可見原則的前提下，這樣的算法適用性仍然有必定侷限。Redisson爲此提供了基於加強型的算法的高可用分佈式聯鎖RedissonMultiLock。這種算法要求客戶端必須成功獲取所有節點的鎖才被視爲加鎖成功，從而更進一步提升了算法的可靠性。

4.可否介紹下Redisson最前沿的發展方向？
Redisson的發展路線決定了它在Redis的功能擴展及應用方式上始終走在業界的前列，其中最具備表明性的即是本地緩存功能了。2016年爲了解決一企業版用戶的切實需求開發了這一功能。其原理是採用犧牲客戶端自身內存的空間的方式，換取在頻繁獲取某些經常使用數據時消耗在網絡上的時間。該功能在同年9月開源後便當即受到了廣大用戶的關注。這一功能的出現加速了傳統IT用戶從其餘相似平臺遷移到Redis的速度。其受歡迎程度大大超乎了Nikita和個人想象。以致於每一年都有企業用戶不遠萬里去Redis大會等相似國際交流大會，並分享它們使用Redisson從其餘平臺向Redis遷移過程和經驗。也正是由於這種趨勢而引發了Redis做者Salvatore的注意，在同一些用戶面對面溝通交流以後，Salvatore決定將客戶端緩存功能做爲Redis從此發展的重要方向，併爲此提出了RESP3協議。RESP3的出現將爲客戶端緩存功能提供服務端協調的能力。同時Salvatore還邀請Redisson團隊做爲專家組成員參與Redis客戶端緩存標準的指定。

5.Redisson作爲開源項目如何保證持續的發展？
爲了保證Redisson項目的可持續性的健康發展，爲了不像其餘開源項目面臨的一段時間之後就無人維護的尷尬局面，17年初Nikita和我商量後決定在開源項目基礎上提供收費諮詢服務，爲項目的正常運做提供必要的資金。同時還針對大型企業用戶遇到的特殊場景提供了企業級的綜合性解決方案，最後將這些全部的方案與企業級SLA支持服務打包做爲Redisson PRO正式面向企業用戶。

相對於其餘客戶端而言，雖然Redisson項目創立的時間較短，但已經受到了來自不一樣行業企業的信任，其中不乏許多行業領頭羊企業，其中最值得介紹的是這幾個世界級的企業用戶：
• 計算機行業的IBM。想必你們都熟悉IBM，PC機的鼻祖。，業界少有同時具備超強硬件軟件研發能力的企業，即使如此，IBM也心甘情願的使用Redisson，這種信任是對咱們最大的支持。
• 航空國防制造業的波音。在它們主動聯繫咱們之前，我很難想象波音也會對Redisson感興趣。事實上波音除了造飛機之外，它也是全球最大的飛行航圖提供商和移動電子飛行包的方案提供商，幾乎每一個航空公司都是他們的用戶。Redisson爲他們的在線飛行導航業務提供了紮實的基礎。
• 保險業的美國國際集團（AIG）。美國國際集團成立於1919年的中國上海，它是首個將保險概念帶給中國人的西方企業，其業務遍及全球130多個國家和地區。雖然08年經濟危機中，遭遇股價瞬間暴跌的慘劇將AIG推入了吃瓜羣主的視線，但它今天還是一個擁有99年曆史，總資產爲6千多億美圓的國際性大型企業。在通過AIG團隊長時間的調研後，Redisson被用於支持其名目衆多的金融保險業務。
• 金融機構標準普爾（S&P Global）。提到經濟危機就不得不提一下世界權威金融分析機構標準普爾。它是美國證券交易委員會（SEC）承認的三大評級組織之一，專門爲投資者提供信用評級，投資研究和諮詢等服務。在業內外的知名度很高，頗負盛名的S&P 500美國股指即是由它建立並維護着。標準普爾不只對外提供針對上市企業的評級，還提供針對國家政府的評級。它在2011年時斷然下降美國政府的評級，並把其前景調整爲負面之後，立馬引起了金融業的劇烈波動。但正是這個呼風喚雨無所不能，連美國政府都不放眼裏的機構也成爲了Redisson的忠實用戶，並將其用於提供複雜的金融數據的分析和處理。因而可知Redisson的信任評級是很是的高[奸笑]。

原文連接