如何評價阿里開源的ApsaraCache？

01-01

我是阿里Redis和MemCache的技術負責人子嘉，ApsaraCache也是我們團隊的作品，整個開源過程和邀請作者來華也主要由我們團隊負責推進。

先說為什麼開源，主要是兩個原因，一是在雲上我們能接觸到各行各業的用戶和各種各樣的需求，而且能遇到絕大部分用戶永遠也不會碰到的場景，在這些需求和場景的基礎上我們做了很多有意思的事情，我們不想離社區主流太遠，也希望能把這些功能回饋給社區，我們在實現這些需求的時候也盡量遵循Redis社區現有版本的架構和設計哲學；二是Redis目前是商業公司Redislabs的資產，Redislabs會在商業和開源之間有個balance，這也是正常的商業邏輯，有些功能如RoF會選擇閉源，有些功能如Redis Module會選擇走AGPL協議，未來阿里也會基於Redis Module推出一些功能，但根據AGPL協議我們也是要開源的，晚開不如早開，被動開不如主動開。

針對目前已經開源的MemCache協議，大家分析也都比較到位了，除了前面同學提到的「一箭三雕」還有其它的一些好處，就是直接復用Redis整個的技術架構和生態工具，比如可以用一些migrate工具來遷移MemCache數據，後端可以直接使用redis的master-slave複製機製做數據同步，使用sentinel來做HA，redis的監控數據更為詳細，監控體系也更為完整，這些功能在memcached架構上是很難實現的，所以我覺得這個feature賦予了MemCache新的生命力，我和Salvatore當面溝通過這個feature，Salvatore明確表示不會merge這個patch，原因是他覺得他要更關注Redis，不想分心做這些兼容工作，如果用戶有持久化和多副本容災的需求，那就從MemCache客戶端換成Redis客戶端，反正成本也不高，這麼說也是有道理的。我個人看法是很多用戶還是在同時維護兩套系統，memcached+Redis，從MemCache協議轉Redis也是有成本的，很多老庫也不是說轉就轉，對於有這種需求的用戶可以直接基於ApsaraCache來構建。

為何不在一個Redis進程里同時支持Redis和MemCache協議？在技術上是完全可行的，但是我們擔心key衝突的問題，MemCache的key是在Redis key的基礎上做了格式兼容，如果一個Redis client去讀取MemCache的key或者MemCache client去讀取Redis key都會有問題，兩種client都寫同一個key也會有覆蓋問題，而且這種衝突還不好追蹤和審計，所以嚴謹一些，我們不打算一個後端server同時支持兩種協議。

後續還會陸續開源其他功能，如AOF binlog，原理類似MySQL binlog，有了該功能之後Redis就有了一個可靠穩定的stream，有了stream你就可以做像MySQL或者Oracle一樣來實現各種容災形態和讀寫分離等，Salvatore對這個feature非常感興趣，會和我們一起來review代碼，希望部分思想也能被吸收到psync3的設計中；熱升級優化，通過將Redis的主體拆成一個獨立的so來實現40ms完成一次Redis內核代碼熱升級，對運維更為友好；獨立的監控線程，用來做精確的HA，防止keys flushdb等耗時操作阻塞主線程導致sentinel誤切換；還有其它的一些穩定性和性能優化，在這裡不做展開。

這些功能最開始都是基於2.8版本做的，開源是基於4.0版本，我們做了大量測試之後才一次性合併到4.0版本上，所以一個重大feature看起來只有一個commit。很多功能可能和社區的思路有衝突，比如支持MemCache協議、熱升級等，社區可能不接受或者即使接受但是有一個很長的過程，對於遊離於社區之外的這些功能我們會在ApsaraCache上繼續維護下去，也算給用戶一些不一樣的選擇。我們對開源的貢獻也不僅限於ApsaraCache，很多重大的bugfix和optimization我們目前都直接提到4.0的mainstream上，大家也會看到Redis社區有越來越多來自Alibaba的committer。

作者來華的一個重要原因是中國有很多優質的committer，Redis在中國也有廣大的群眾基礎，作者也希望有dedicated team的大廠加入研發工作，這樣能夠最大限度保證commit的質量，另外也想宣傳一下Redis 4.X的後續工作。作者除了對我們開發的一些feature感興趣之外，對我們後端的各種全鏈路監控系統和工具也很感興趣，有了牛逼的刀才能更好地砍木頭是不是？

感謝雲棲大會組委會對整個活動的大力支持和有序的後台組織工作，作者本人對整個行程非常滿意，唯一不滿意的就是杭州的雨，目前他還被杭州的雨封印在酒店裡。

最後，我們這邊非常缺人、缺各種人，如果你覺得自己夠geek、夠聰明、經驗夠豐富（3個條件滿足其一就可以了）就可以知乎投簡歷給我（級別P7起），我們在招KV內核、中間件、數據分析、DevOPS等各個領域的人才，我們那個沒良心的老闆褚霸天天嫌棄我招人不力，世道艱難啊。除了直接給我投簡歷，也可以投簡歷到下面鏈接：

阿里雲-技術專家-KVstore

阿里雲-技術專家-NoSQL資料庫

繼承了阿里一貫以來的，抄一下、改一改、加一點、補一點、擴展一點、組合一點的思想。當然，其他公司也是一個樣兒。

看了下代碼就是把redis4.0 fork過來之後，支持了memcached協議，還做了某些增強

不知道為啥起了個ApsaraCache這麼奇怪的名字，還把redis作者請過來了，看來背地裡做了一些奇怪的py交易

ApsaraCache 中文文檔
ApsaraCache 是基於Redis 4.0的分支開發的。我們在Redis的基礎上做了大量的新功能和性能的優化。本次發布的代碼包括對memcached協議的支持和短連接優化兩個主要功能，其他新的功能會逐漸的開源出來。

目前看到說明只針對memcached協議做了支持和短連接優化，其他新的功能還未開源。

對於協議，只能選擇redis協議或者memcached協議，不能同時支持兩個協議。

對於業務使用memcached的好處就是可以使用ApsaraCache實現aof和rdb的持久化，統一分散式緩存。阿里雲上有redis和memcached兩個資料庫產品，使用ApsaraCache應該可以把兩個團隊合併成一個節省人工成本，即能開源傳播影響力又能統一江湖還能節省成本，至少一箭三雕的戰略。

樓下有ApsaraCache團隊負責人子嘉的正式解說。

目前的代碼和官方的redis相比，改動非常小。

而且從commit的時間來看，合併的還挺倉促的。估計是著急趁著這次大會熱度宣布開源

繼續觀望，看看後續還會有什麼新的feature加入~

阿里開源的東西還是先持半年觀望態度再說...

還沒有看源碼，然後就先找到這裡了。作為一個阿里雲的用戶，說兩句吧。

ApsaraCache 應該是阿里雲自己銷售的 Redis 的後端，我們的業務一直都在用aliyun的redis服務。除了一次阿里雲的運維人員手抖出了一個問題之外，其它時間都是穩定的很。對於我們這種小到連運維都沒有的公司來講，真的是很好的一個服務了。

說實話，這個問題下的答案很多都看不下去。有幾個回答裡邊，真的是極盡嘲諷之能事。我就想問問這些答主，你們為開源社區貢獻過什麼？如果你們就是一些看客，那麼請你先多了解一下技術背後各個技術團隊的付出與艱辛。把你自己放到一個商業公司的技術的位置上去，你再想想你又能夠做什麼，你又能做到多好？話說回來，即使你已經是開源屆的支柱，假使你已經做得比阿里團隊要好，那麼你也不應該是在這裡嘲諷什麼。技術相輕是病。

just for kpi

參考 tengine https://github.com/alibaba/tengine/issues/921

MemCache 和 Redis協議是啟動時切換的。本來以為是能同時一個key支持以兩種協議訪問。如果是二選一就對大部分人沒什麼意義。

為了其他的優勢和特點也沒明顯必要去選用，還是redis主流最穩妥。

具體來說，ApsaraCache還具備多方面的技術特點和優勢，一是災備深度加固，可以重構內核同步機制，解決了原生內核在弱網條件下容易複製中斷導致的全量同步問題。

二是兼容Memcached協議，能支持雙副本的Memcached，數據可持久化、提供更可靠的Memcached服務）

三是短鏈接優化，使短鏈接場景下性能提升30%以上，對PHP短鏈接應用居多的用用提升效果明顯。

四是AOF強化，避免 AOF Rewrite 頻繁造成的主機穩定性瓶頸，且能精確到秒級的按時間點恢復。

五是獨特的熱升級機制，增加了熱升級的功能，能夠在 3ms 內完成一個實例的熱更新，解決了內核頻繁升級對用戶帶來的影響。

六是可是用於實例可用性檢測。