作者 |   煙圈

前言

經(jīng)歷接近一年的開(kāi)發(fā)、三個(gè)候選版本，Redis 7.0終于正式發(fā)布，這是Redis歷史上改變最多的一個(gè)大版本，它不僅包含了50多個(gè)新命令，還有大量核心新特性與改進(jìn)，這些不僅能夠解決用戶使用中的諸多問(wèn)題，還進(jìn)一步拓展了Redis的使用場(chǎng)景。

雖然Redis 7.0做了許多大膽的嘗試，但是穩(wěn)定性依然是最重要的基石。Redis官方在7.0的GA博文中也強(qiáng)調(diào)這一點(diǎn)：“While user-facing features are easy to boast of, the real “unsung heroes” in this version are efforts to make Redis more performant, stable, and lean.”(雖然面向用戶的功能更容易得到稱(chēng)贊，但這個(gè)版本中的無(wú)名英雄是我們持續(xù)不斷的對(duì)Redis的優(yōu)化，使其變得更加精簡(jiǎn)、高效、穩(wěn)定)。相信從這里可以看出，Redis發(fā)展至今穩(wěn)定性始終被擺在最重要的位置，因此對(duì)于7.0的穩(wěn)定性擔(dān)憂大可打消。

下面請(qǐng)先跟隨我們一同了解Redis7.0的幾個(gè)核心新特性。

Redis7.0核心新特性概覽

Function

Function是Redis腳本方案的全新實(shí)現(xiàn)，在Redis 7.0之前用戶只能使用EVAL命令族來(lái)執(zhí)行Lua腳本，但是Redis對(duì)Lua腳本的持久化和主從復(fù)制一直是undefined狀態(tài)，在各個(gè)大版本甚至release版本中也都有不同的表現(xiàn)。因此社區(qū)也直接要求用戶在使用Lua腳本時(shí)必須在本地保存一份(這也是最為安全的方式)，以防止實(shí)例重啟、主從切換時(shí)可能造成的Lua腳本丟失，維護(hù)Redis中的Lua腳本一直是廣大用戶的痛點(diǎn)。

Function的出現(xiàn)很好的對(duì)Lua腳本進(jìn)行了補(bǔ)充，它允許用戶向Redis加載自定義的函數(shù)庫(kù)，一方面相對(duì)于EVALSHA的調(diào)用方式用戶自定義的函數(shù)名可以有更為清晰的語(yǔ)義，另一方面Function加載的函數(shù)庫(kù)明確會(huì)進(jìn)行主從復(fù)制和持久化存儲(chǔ)，徹底解決了過(guò)去Lua腳本在持久化上含糊不清的問(wèn)題。

那么自7.0開(kāi)始，F(xiàn)unction命令族和EVAL命令族有了各自明確的定義：FUNCTION LOAD會(huì)把函數(shù)庫(kù)自動(dòng)進(jìn)行主從復(fù)制和持久化存儲(chǔ);而SCRIPT LOAD則不會(huì)進(jìn)行持久化和主從復(fù)制，腳本僅保存在當(dāng)前執(zhí)行節(jié)點(diǎn)。并且社區(qū)也在計(jì)劃后續(xù)版本中讓Function支持更多語(yǔ)言，例如JavaScript、Python等，敬請(qǐng)期待。

總的來(lái)說(shuō)，F(xiàn)unction在7.0中被設(shè)計(jì)為數(shù)據(jù)的一部分，因此能夠被保存在RDB、AOF文件中，也能通過(guò)主從復(fù)制將Function由主庫(kù)復(fù)制到所有從庫(kù)，可以有效解決之前Lua腳本丟失的問(wèn)題，我們也非常建議大家逐步將Redis中的Lua腳本替換為Function。

Multi-part AOF

AOF是Redis數(shù)據(jù)持久化的核心解決方案，其本質(zhì)是不斷追加數(shù)據(jù)修改操作的redo log，那么既然是不斷追加就需要做回收也即compaction，在Redis中稱(chēng)為AOF rewrite。

然而AOF rewrite期間的增量數(shù)據(jù)如何處理一直是個(gè)問(wèn)題，在過(guò)去rewrite期間的增量數(shù)據(jù)需要在內(nèi)存中保留，rewrite結(jié)束后再把這部分增量數(shù)據(jù)寫(xiě)入新的AOF文件中以保證數(shù)據(jù)完整性?？梢钥闯鰜?lái)AOF rewrite會(huì)額外消耗內(nèi)存和磁盤(pán)IO，這也是Redis AOF rewrite的痛點(diǎn)，雖然之前也進(jìn)行過(guò)多次改進(jìn)但是資源消耗的本質(zhì)問(wèn)題一直沒(méi)有解決。

阿里云的Redis企業(yè)版在最初也遇到了這個(gè)問(wèn)題，在內(nèi)部經(jīng)過(guò)多次迭代開(kāi)發(fā)，實(shí)現(xiàn)了Multi-part AOF機(jī)制來(lái)解決，同時(shí)也貢獻(xiàn)給了社區(qū)并隨此次7.0發(fā)布。具體方法是采用base(全量數(shù)據(jù))+inc(增量數(shù)據(jù))獨(dú)立文件存儲(chǔ)的方式，徹底解決內(nèi)存和IO資源的浪費(fèi)，同時(shí)也支持對(duì)歷史AOF文件的保存管理，結(jié)合AOF文件中的時(shí)間信息還可以實(shí)現(xiàn)PITR按時(shí)間點(diǎn)恢復(fù)(阿里云企業(yè)版Tair已支持)，這進(jìn)一步增強(qiáng)了Redis的數(shù)據(jù)可靠性，滿足用戶數(shù)據(jù)回檔等需求。

Sharded-pubsub

Redis自2.0開(kāi)始便支持發(fā)布訂閱機(jī)制，使用pubsub命令族用戶可以很方便地建立消息通知訂閱系統(tǒng)，但是在cluster集群模式下Redis的pubsub存在一些問(wèn)題，最為顯著的就是在大規(guī)模集群中帶來(lái)的廣播風(fēng)暴。

Redis的pubsub是按channel頻道進(jìn)行發(fā)布訂閱，然而在集群模式下channel不被當(dāng)做數(shù)據(jù)處理，也即不會(huì)參與到hash值計(jì)算無(wú)法按slot分發(fā)，所以在集群模式下Redis對(duì)用戶發(fā)布的消息采用的是在集群中廣播的方式。

那么問(wèn)題顯而易見(jiàn)，假如一個(gè)集群有100個(gè)節(jié)點(diǎn)，用戶在節(jié)點(diǎn)1對(duì)某個(gè)channel進(jìn)行publish發(fā)布消息，該節(jié)點(diǎn)就需要把消息廣播給集群中其他99個(gè)節(jié)點(diǎn)，如果其他節(jié)點(diǎn)中只有少數(shù)節(jié)點(diǎn)訂閱了該頻道，那么絕大部分消息都是無(wú)效的，這對(duì)網(wǎng)絡(luò)、CPU等資源造成了極大的浪費(fèi)。

Sharded-pubsub便是用來(lái)解決這個(gè)問(wèn)題，意如其名，sharded-pubsub會(huì)把channel按分片來(lái)進(jìn)行分發(fā)，一個(gè)分片節(jié)點(diǎn)只負(fù)責(zé)處理屬于自己的channel而不會(huì)進(jìn)行廣播，以很簡(jiǎn)單的方法避免了資源的浪費(fèi)。

Client-eviction

Redis支持內(nèi)存規(guī)格配置，maxmemory和maxmemory-policy大家已經(jīng)都很熟悉了，但是在這里我還是想再解釋一下：maxmemory控制的是Redis的整體運(yùn)行內(nèi)存而非數(shù)據(jù)內(nèi)存，例如client buffer、lua cache、fucntion cache、db

metadata等這些都會(huì)算在運(yùn)行內(nèi)存中，如果運(yùn)行內(nèi)存超過(guò)了maxmemory就會(huì)觸發(fā)evict刪除數(shù)據(jù)，這也是用戶在使用Redis時(shí)的一大痛點(diǎn)。

在這些非數(shù)據(jù)內(nèi)存使用當(dāng)中，又以client buffer消耗最大，在大流量場(chǎng)景下client需要緩存很多用戶讀寫(xiě)數(shù)據(jù)(想象一下keys的結(jié)果需要先緩存在client output buffer中再發(fā)送給用戶)，由于網(wǎng)絡(luò)流量的內(nèi)存消耗導(dǎo)致觸發(fā)eviction刪除數(shù)據(jù)的情況非常之多。雖然Redis很早就支持對(duì)client-output-buffer-limit配置項(xiàng)，但其限制的也只是單個(gè)連接維度的output

buffer，沒(méi)有全局統(tǒng)計(jì)client使用內(nèi)存和限制。為了解決這個(gè)問(wèn)題，7.0新增了maxmemory-clients配置項(xiàng)，來(lái)對(duì)所有client使用的內(nèi)存做限制，如果超過(guò)了這個(gè)限制就會(huì)挑選內(nèi)存消耗最大的client釋放，用來(lái)緩解內(nèi)存使用的消耗。

Client-eviction并不是終點(diǎn)，還有很多元數(shù)據(jù)的內(nèi)存使用會(huì)對(duì)用戶造成困擾，Redis是基于內(nèi)存的數(shù)據(jù)庫(kù)，我們需要對(duì)各個(gè)模塊的內(nèi)存進(jìn)行更精確的統(tǒng)計(jì)和控制，讓用戶能夠?qū)?shù)據(jù)存儲(chǔ)有更為清晰的理解和規(guī)劃。

Redis歷史回顧

Redis發(fā)展至今已歷經(jīng)7個(gè)大版本，而每個(gè)大版本都有大量的新特性產(chǎn)生。例如從3.0開(kāi)始支持cluster集群模式;4.0開(kāi)發(fā)的lazyfree和PSYNC2解決了Redis長(zhǎng)久的大key刪除阻塞問(wèn)題及同步中斷無(wú)法續(xù)傳的問(wèn)題;5.0新增了stream數(shù)據(jù)結(jié)構(gòu)使Redis具備功能完整的輕量級(jí)消息隊(duì)列能力;6.0更是發(fā)布了諸多企業(yè)級(jí)特性如threaded-io、TLS和ACL等，大幅提升了Redis的性能和安全性。

國(guó)內(nèi)開(kāi)發(fā)者與Redis社區(qū)建設(shè)

感謝國(guó)內(nèi)開(kāi)發(fā)者，中國(guó)區(qū)已經(jīng)成為Redis社區(qū)最大的貢獻(xiàn)來(lái)源之一

阿里云從Redis 4.0開(kāi)始就深度參與到Redis開(kāi)源社區(qū)當(dāng)中，向社區(qū)貢獻(xiàn)了大量能力，目前阿里云在Redis社區(qū)共有1名core team member(核心維護(hù)者)和2名contributor(核心貢獻(xiàn)者)，是原作者和Redis Labs以外對(duì)Redis社區(qū)貢獻(xiàn)最大的組織。

我們見(jiàn)證了Redis用戶在國(guó)內(nèi)的快速增長(zhǎng)，阿里云與Redis社區(qū)的深度合作也逐漸吸引了更多的國(guó)內(nèi)開(kāi)發(fā)者參與到Redis建設(shè)中去。尤其是在Redis core team成立之后，社區(qū)maintainer也和Redis一樣變成了多線程(1->5)，對(duì)于issue和PR的快速處理大幅提升了社區(qū)的活躍度。這次7.0的release note中也可以看到已經(jīng)有超過(guò)5名國(guó)內(nèi)開(kāi)發(fā)者貢獻(xiàn)了核心feature，并貢獻(xiàn)了近半數(shù)commit。

這些變化與我們?cè)诎⒗镌粕系慕y(tǒng)計(jì)結(jié)果也是相符合的：Redis目前同樣也已是國(guó)內(nèi)用戶使用規(guī)模最大的NoSQL數(shù)據(jù)庫(kù)之一，并一直處于高速增長(zhǎng)中，越來(lái)越多的泛互聯(lián)網(wǎng)甚至傳統(tǒng)行業(yè)也在逐步接納Redis，用于快速高效的構(gòu)建業(yè)務(wù)應(yīng)用服務(wù)。

雖然Redis發(fā)展迅速，但國(guó)內(nèi)用戶卻大都無(wú)法享受技術(shù)紅利

Redis社區(qū)目前主流維護(hù)版本是6.0，5.0版本已經(jīng)進(jìn)入低維護(hù)階段，而國(guó)內(nèi)還有大量2.8，3.0，4.0版本在使用中。這就很矛盾，一方面，一些對(duì)用法，性能，穩(wěn)定性和抖動(dòng)控制的能力都貢獻(xiàn)在了新版本上，另一方面，國(guó)內(nèi)用戶卻“看的到，用不上”。

除去6.0，7.0上的高級(jí)穩(wěn)定性優(yōu)化不說(shuō)，比如在4.0前，沒(méi)有l(wèi)azyfree刪除一個(gè)大key是同步的會(huì)卡住數(shù)據(jù)庫(kù)引擎直接導(dǎo)致業(yè)務(wù)中斷。又比如，Redis其實(shí)安全性尤其是lua是一直有較大問(wèn)題的，這些升級(jí)也都“隱含”在了新版本中。雖然阿里云仍然在堅(jiān)持把這些漏洞的修復(fù)拉回到低版本上，但是在公網(wǎng)當(dāng)中還是有大量的低版本實(shí)例存在安全風(fēng)險(xiǎn)。

過(guò)多用戶擔(dān)心升級(jí)版本的兼容性，一方面阿里云也在要求社區(qū)來(lái)提供一些兼容性驗(yàn)證工具，另一方面阿里云對(duì)版本跟進(jìn)是很快的，可以讓用戶在新版發(fā)布后盡快進(jìn)行驗(yàn)證。從Redis整體和阿里云的大量客戶升級(jí)情況來(lái)看，版本的向前兼容性是非常好的，大可放心升級(jí)。

希望更多的國(guó)內(nèi)用戶深度參與社區(qū)建設(shè)

國(guó)外使用Redis的方式和國(guó)內(nèi)使用明顯有差異，比如國(guó)外更多的是使用在緩存場(chǎng)景，而國(guó)內(nèi)大多數(shù)的用法卻是內(nèi)存數(shù)據(jù)庫(kù)。社區(qū)的發(fā)展和roadmap的制定，目前國(guó)內(nèi)用戶的聲音較小。

目前國(guó)內(nèi)開(kāi)發(fā)者在社區(qū)活躍度很高，但更多的是圍繞在bugfix，和feature上。我們還是建議無(wú)論是國(guó)內(nèi)開(kāi)發(fā)者還是使用者可以深層參與進(jìn)去，舉個(gè)簡(jiǎn)單的例子，提需求、講明白需求、證明需求的合理性都是參與社區(qū)建設(shè)，這樣才能更好的把我們國(guó)內(nèi)的需求傳達(dá)，后續(xù)甚至可以深度參與開(kāi)發(fā)，跟蹤交付，這些社區(qū)工作的含金量無(wú)疑更高。

在功能上，不僅僅包括API層面的增加，包括接入，可觀測(cè)性，一致性，一致性和安全等目前社區(qū)都在等待需求中。雖然core team member可以代表國(guó)內(nèi)用戶來(lái)把一些需求寫(xiě)進(jìn)roadmap，但是真實(shí)用戶的發(fā)聲會(huì)提供更有力的支撐。

Redis使用場(chǎng)景拓展與展望--Redis還能做什么?

多模服務(wù)進(jìn)入爆發(fā)期

Redis是一直貼著用戶使用發(fā)展起來(lái)的，它如此受歡迎主要因?yàn)閮蓚€(gè)特點(diǎn)，極高的性能以及豐富、方便使用的數(shù)據(jù)結(jié)構(gòu)，這些簡(jiǎn)單好用的數(shù)據(jù)結(jié)構(gòu)能夠大幅度降低開(kāi)發(fā)業(yè)務(wù)復(fù)雜度。

我們可以看到，以Redislabs為代表的廠商正在大力的豐富Redis的數(shù)據(jù)結(jié)構(gòu)(modules)，如RedisSearch、Redis-Json、RedisGraph、RedisTimeSeries和RedisBloom等。

同樣的，阿里云內(nèi)存數(shù)據(jù)庫(kù)Tair很早就在研發(fā)各類(lèi)增強(qiáng)數(shù)據(jù)結(jié)構(gòu)和模塊，目前我們?cè)诠苍芓air服務(wù)中提供的商業(yè)化擴(kuò)展型數(shù)據(jù)結(jié)構(gòu)比Redislabs提供的更多，部分模塊功能更強(qiáng)，有興趣可參見(jiàn)文檔(本文末尾參考資料)。

目前已有大量云上用戶在利用Tair增強(qiáng)型數(shù)據(jù)結(jié)構(gòu)來(lái)構(gòu)建代碼，提高開(kāi)發(fā)效率，甚至完成此前難以完成的工作。2022年是一個(gè)Redis擴(kuò)展結(jié)構(gòu)的爆發(fā)年，業(yè)內(nèi)已經(jīng)渡過(guò)接納期，進(jìn)入高速發(fā)展階段。無(wú)論是Tair還是Redis，我們相信不斷豐富的數(shù)據(jù)結(jié)構(gòu)能夠讓它們走的更遠(yuǎn)，從緩存演變?yōu)楦咝阅艿挠?jì)算型內(nèi)存數(shù)據(jù)庫(kù)，突破、并解決更多場(chǎng)景問(wèn)題。

一致性能力上的發(fā)展

落盤(pán)一致性和副本一致性是使用數(shù)據(jù)庫(kù)繞不開(kāi)的兩個(gè)話題。長(zhǎng)期以來(lái)許多人對(duì)Redis的應(yīng)用場(chǎng)景僅僅認(rèn)定為緩存(尤其是國(guó)外用戶)。Redis自誕生之初便支持持久化機(jī)制RDB和AOF，并且AOF還提供了不同級(jí)別的持久化語(yǔ)義：如appendfsync采用最高級(jí)別always時(shí)可以保證數(shù)據(jù)完全落盤(pán)不丟失，具備與傳統(tǒng)數(shù)據(jù)庫(kù)一樣的強(qiáng)落盤(pán)一致性。

在多副本一致性上，主要是指主備一致性上，原生的Redis仍舊采用異步復(fù)制，數(shù)據(jù)修改操作只要在本地執(zhí)行完成就會(huì)返回結(jié)果，相比于其他數(shù)據(jù)庫(kù)沒(méi)有提供副本間數(shù)據(jù)強(qiáng)一致的語(yǔ)義。這也限制了Redis的使用場(chǎng)景，在對(duì)數(shù)據(jù)可靠性有極高要求的用戶(例如金融行業(yè)，和傳統(tǒng)行業(yè))中還沒(méi)有被完全接納。

目前業(yè)內(nèi)也都在對(duì)Redis的持久化能力上進(jìn)行發(fā)展。比較有代表性的，是阿里云的Tair持久內(nèi)存版、AWS的MemoryDB、和業(yè)內(nèi)開(kāi)源的一些Redis-like的基于rocksdb的系統(tǒng)，商業(yè)化如Tair的容量存儲(chǔ)版(前混合存儲(chǔ))。

表1: 社區(qū)Redis和其他商業(yè)化、開(kāi)源產(chǎn)品的落盤(pán)一致性與副本一致性對(duì)比

注1：與開(kāi)源Redis社區(qū)版比較注

2：與開(kāi)源Redis基于內(nèi)存的使用成本比較注

3,4：來(lái)自AWS官方博客測(cè)試數(shù)據(jù)

綜合來(lái)看，隨著用戶對(duì)Redis的應(yīng)用范圍的擴(kuò)大，與此同時(shí)對(duì)于容量、成本和數(shù)據(jù)可靠性的需求也在不斷提升，這些也逐漸成為了衡量Redis企業(yè)級(jí)能力的重要指標(biāo)。各大廠商和開(kāi)源產(chǎn)品也都在構(gòu)建這些能力上提出了許多解決方案。下面介紹一些典型產(chǎn)品和方案。

AWS的MemoryDB

AWS MemoryDB的思路是基于類(lèi)似Aurora的共享存儲(chǔ)概念，把日志存放在遠(yuǎn)端共享存儲(chǔ)中，同時(shí)內(nèi)存中仍然保留Redis原有的結(jié)構(gòu)。通過(guò)這種方式提升數(shù)據(jù)的持久化一致性，同時(shí)也保證了數(shù)據(jù)讀取的延時(shí)和吞吐;而缺點(diǎn)則同樣因?yàn)槿罩颈４嬖谶h(yuǎn)端，寫(xiě)入性能?chē)?yán)重下降(僅有ElastiCache也即Redis社區(qū)版的15%~25%，該數(shù)據(jù)來(lái)自AWS官方評(píng)測(cè)，見(jiàn)本文末尾參考資料)。在主備一致性上，由于直接采取日志的物理復(fù)制，所以主備一致性近似接近落盤(pán)一致性。

值得一提的是原來(lái)AOF rewrite這種壓縮(compaction)引起的開(kāi)銷(xiāo)也因?yàn)樵谶h(yuǎn)端做掉而規(guī)避掉，因此是一種很徹底的云原生解法。

阿里云自研內(nèi)存數(shù)據(jù)庫(kù)Tair

在持久化上阿里云走了另外一條路，通過(guò)引入新介質(zhì)持久化內(nèi)存來(lái)解決成本，大容量和持久化能力的問(wèn)題。

這個(gè)方案帶來(lái)的挑戰(zhàn)是使用持久化內(nèi)存存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)上較為復(fù)雜，既要控制性能衰減，又要保證兼容性。Tair持久內(nèi)存很好的解決了這些問(wèn)題，對(duì)比MemoryDB成本更低，讀性能基本持平的情況下寫(xiě)入的速度也更快(見(jiàn)本文末尾參考資料)，更關(guān)鍵的是基本原封原樣的兼容了Redis API，大幅降低了用戶的切換成本。

并且，Tair持久內(nèi)存型還支持半同步和強(qiáng)寫(xiě)入一致性，無(wú)論MemoryDB還是Tair持久內(nèi)存都真正的做到了內(nèi)存數(shù)據(jù)庫(kù)的數(shù)據(jù)容錯(cuò)性要求。

其他開(kāi)源產(chǎn)品的發(fā)展

國(guó)內(nèi)也出現(xiàn)了一些原創(chuàng)性的優(yōu)秀落盤(pán)開(kāi)源產(chǎn)品(Redis-Like系統(tǒng))，這些產(chǎn)品大都基于LSM存儲(chǔ)結(jié)構(gòu)如rocksdb上的。它們的優(yōu)點(diǎn)主要是磁盤(pán)介質(zhì)相對(duì)內(nèi)存更為便宜，但同樣目前存在的缺點(diǎn)也非常多：運(yùn)維復(fù)雜度較高，直接映射為運(yùn)維成本、KV無(wú)法原生的支持Redis的數(shù)據(jù)結(jié)構(gòu)、把Redis的強(qiáng)類(lèi)型變成弱類(lèi)型等等。

目前這類(lèi)系統(tǒng)在一致性和容錯(cuò)性上仍有很大的改善空間，而在用戶使用體感上，由于很多用戶使用習(xí)慣還是把Redis-like系統(tǒng)用在業(yè)務(wù)的同步鏈路上，對(duì)于LSM KV引擎的延時(shí)上抖動(dòng)整體吞吐的影響直接映射成了用戶體感，因此很難作為一款通用型產(chǎn)品，而這些痛點(diǎn)也同樣存在與Tair容量存儲(chǔ)型中(過(guò)去叫混合存儲(chǔ)版)，這也是一個(gè)需要長(zhǎng)期在存儲(chǔ)和兼容性上優(yōu)化的方向。

綜上所述，容量版本可以很好地解決用戶的使用成本問(wèn)題，但是只有更好地解決了落盤(pán)一致性問(wèn)題和副本一致性問(wèn)題，才能夠把Redis類(lèi)系統(tǒng)的使用場(chǎng)景拓展到企業(yè)級(jí)。這也是目前看來(lái)云廠商一個(gè)激烈競(jìng)爭(zhēng)的企業(yè)級(jí)產(chǎn)品主流賽道，也有較高的技術(shù)門(mén)檻。

寫(xiě)在最后

Redislabs在2021年8月正式更名為Redis，大家看到社區(qū)版Redis的主頁(yè)也已經(jīng)重構(gòu)修改過(guò)了。本身Redis的商業(yè)化進(jìn)度非?？?，比如在主頁(yè)上“夾帶” Redis Stack;又比如在github上將一眾常用的SDK都購(gòu)買(mǎi)后，開(kāi)始添加部分Redislabs商業(yè)化開(kāi)源的支持等。最后Redis可能也會(huì)像MongoDB，ElasticSearch一樣走向徹底的商業(yè)化。但目前社區(qū)仍是非常公開(kāi)和活躍的。

Redis8.0的 feature計(jì)劃已經(jīng)開(kāi)始，一方面我們也如上文所述，建議國(guó)內(nèi)開(kāi)發(fā)者更多的參與到深層次的社區(qū)討論，讓社區(qū)更多的向國(guó)內(nèi)使用習(xí)慣靠攏，這對(duì)重度依賴Redis的國(guó)內(nèi)企業(yè)情況是非?，F(xiàn)實(shí)的;另一方面，能夠通過(guò)社區(qū)參與來(lái)提升我們的人才競(jìng)爭(zhēng)力，除去持久化系統(tǒng)，還有分布式架構(gòu)，高吞吐低延時(shí)核心引擎，多模服務(wù)和腳本引擎，安全與審計(jì)等都需要持續(xù)投入。如果國(guó)內(nèi)在Redis領(lǐng)域也能夠有10～20名內(nèi)存數(shù)據(jù)庫(kù)的頂尖專(zhuān)家，那么即便是Redis走向商業(yè)化閉源其影響對(duì)國(guó)內(nèi)用戶都會(huì)非常小。

最后，歡迎大家使用Redis7.0，也愿我們一起在Redis等內(nèi)存數(shù)據(jù)庫(kù)技術(shù)上走得更遠(yuǎn)!

參考資料：

[1]Redis 7.0 Multi Part AOF的設(shè)計(jì)和實(shí)現(xiàn)：https://developer.aliyun.com/article/866957

[2]Amazon MemoryDB 與 Amazon ElastiCache比較：https://aws.amazon.com/cn/blogs/china/comparison-of-amazon-memorydb-and-amazon-elasticache/?nc1=b_nrp

[3]Tair擴(kuò)展數(shù)據(jù)結(jié)構(gòu)概覽：https://help.aliyun.com/document_detail/146579.html

[4]Tair持久內(nèi)存型性能白皮書(shū)：https://help.aliyun.com/document_detail/185189.html