简介： 阅历挨近一年的开发、三个候选版别，Redis 7.0总算正式发布，这是Redis历史上改动最多的一个大版别，它不只包含了50多个新指令，还有许多中心新特性与改善，这些不只能够处理用户运用中的诸多问题，还进一步拓宽了Redis的运用场景。

发布会概况：developer.aliyun.com/topic/redis…

前言

阅历挨近一年的开发、三个候选版别，Redis 7.0总算正式发布，这是Redis历史上改动最多的一个大版别，它不只包含了50多个新指令，还有许多中心新特性与改善，这些不只能够处理用户运用中的诸多问题，还进一步拓宽了Redis的运用场景。

尽管Redis 7.0做了许多斗胆的尝试，可是安稳性依然是最重要的基石。Redis官方在7.0的GA博文中也强调这一点：“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.”（尽管面向用户的功用更容易得到称赞，但这个版别中的无名小卒是咱们持续不断的对Redis的优化，使其变得更加精简、高效、安稳）。信任从这儿能够看出，Redis开展至今安稳性始终被摆在最重要的位置，因而关于7.0的安稳性担忧大可打消。

下面请先跟从咱们一同了解Redis7.0的几个中心新特性。

Redis7.0中心新特性概览

Function

Function是Redis脚本计划的全新完结，在Redis 7.0之前用户只能运用EVAL指令族来履行Lua脚本，可是Redis对Lua脚本的耐久化和主从仿制一向是undefined状态，在各个大版别乃至release版别中也都有不同的体现。因而社区也直接要求用户在运用Lua脚本时必须在本地保存一份（这也是最为安全的方法），以避免实例重启、主从切换时或许造成的Lua脚本丢失，保护Redis中的Lua脚本一向是广阔用户的痛点。

Function的出现很好的对Lua脚本进行了补充，它答运用户向Redis加载自定义的函数库，一方面相关于EVALSHA的调用方法用户自定义的函数名能够有更为明晰的语义，另一方面Function加载的函数库明确会进行主从仿制和耐久化存储，完全处理了曩昔Lua脚本在耐久化上含糊不清的问题。

那么自7.0开端，Function指令族和EVAL指令族有了各自明确的定义：FUNCTION LOAD会把函数库自动进行主从仿制和耐久化存储；而SCRIPT LOAD则不会进行耐久化和主从仿制，脚本仅保存在当前履行节点。而且社区也在计划后续版别中让Function支撑更多语言，例如JavaScript、Python等，敬请期待。

总的来说，Function在7.0中被规划为数据的一部分，因而能够被保存在RDB、AOF文件中，也能经过主从仿制将Function由主库仿制到一切从库，能够有用处理之前Lua脚本丢失的问题，咱们也十分主张咱们逐步将Redis中的Lua脚本替换为Function。

Multi-part AOF

AOF是Redis数据耐久化的中心处理计划，其本质是不断追加数据修正操作的redo log，那么既然是不断追加就需求做收回也即compaction，在Redis中称为AOF rewrite。

可是AOF rewrite期间的增量数据怎么处理一向是个问题，在曩昔rewrite期间的增量数据需求在内存中保存，rewrite结束后再把这部分增量数据写入新的AOF文件中以确保数据完好性。能够看出来AOF rewrite会额定耗费内存和磁盘IO，这也是Redis AOF rewrite的痛点，尽管之前也进行过屡次改善可是资源耗费的本质问题一向没有处理。

阿里云的Redis企业版在最初也遇到了这个问题，在内部经过屡次迭代开发，完结了Multi-part AOF机制来处理，一同也奉献给了社区并随此次7.0发布。详细方法是选用base（全量数据）+inc（增量数据）独立文件存储的方法，完全处理内存和IO资源的浪费，一同也支撑对历史AOF文件的保存办理，结合AOF文件中的时刻信息还能够完结PITR按时刻点恢复（阿里云企业版Tair已支撑），这进一步增强了Redis的数据可靠性，满意用户数据回档等需求。

对详细完结感兴趣的同学能够检查本文结尾参考资料。

Sharded-pubsub

Redis自2.0开端便支撑发布订阅机制，运用pubsub指令族用户能够很方便地树立音讯告诉订阅体系，可是在cluster集群形式下Redis的pubsub存在一些问题，最为显著的就是在大规划集群中带来的播送风暴。

Redis的pubsub是按channel频道进行发布订阅，可是在集群形式下channel不被当做数据处理，也即不会参加到hash值核算无法按slot分发，所以在集群形式下Redis对用户发布的音讯选用的是在集群中播送的方法。

那么问题清楚明了，假如一个集群有100个节点，用户在节点1对某个channel进行publish发布音讯，该节点就需求把音讯播送给集群中其他99个节点，假如其他节点中只要少量节点订阅了该频道，那么绝大部分音讯都是无效的，这对网络、CPU等资源造成了极大的浪费。

Sharded-pubsub便是用来处理这个问题，意如其名，sharded-pubsub会把channel按分片来进行分发，一个分片节点只负责处理属于自己的channel而不会进行播送，以很简略的方法避免了资源的浪费。

Client-eviction

Redis支撑内存规格装备，maxmemory和maxmemory-policy咱们现已都很熟悉了，可是在这儿我仍是想再解释一下：maxmemory操控的是Redis的全体运转内存而非数据内存，例如client buffer、lua cache、fucntion cache、db metadata等这些都会算在运转内存中，假如运转内存超过了maxmemory就会触发evict删去数据，这也是用户在运用Redis时的一大痛点。

在这些非数据内存运用傍边，又以client buffer耗费最大，在大流量场景下client需求缓存许多用户读写数据（想象一下keys的成果需求先缓存在client output buffer中再发送给用户），由于网络流量的内存耗费导致触发eviction删去数据的情况十分之多。尽管Redis很早就支撑对client-output-buffer-limit装备项，但其约束的也只是单个衔接维度的output buffer，没有全局核算client运用内存和约束。为了处理这个问题，7.0新增了maxmemory-clients装备项，来对一切client运用的内存做约束，假如超过了这个约束就会挑选内存耗费最大的client释放，用来缓解内存运用的耗费。

Client-eviction并不是结尾，还有许多元数据的内存运用会对用户造成困扰，Redis是根据内存的数据库，咱们需求对各个模块的内存进行更精确的核算和操控，让用户能够对数据存储有更为明晰的了解和规划。

Redis历史回忆

Redis开展至今已历经7个大版别，而每个大版别都有许多的新特性发生。例如从3.0开端支撑cluster集群形式；4.0开发的lazyfree和PSYNC2处理了Redis长久的大key删去堵塞问题及同步中止无法续传的问题；5.0新增了stream数据结构使Redis具有功用完好的轻量级音讯行列才能；6.0更是发布了诸多企业级特性如threaded-io、TLS和ACL等，大幅提高了Redis的功用和安全性。

国内开发者与Redis社区建造

感谢国内开发者，我国区现已成为Redis社区最大的奉献来源之一

阿里云从Redis 4.0开端就深度参加到Redis开源社区傍边，向社区奉献了许多才能，现在阿里云在Redis社区共有1名core team member（中心保护者）和2名contributor（中心奉献者），是原作者和Redis Labs以外对Redis社区奉献最大的组织。

咱们见证了Redis用户在国内的快速添加，阿里云与Redis社区的深度合作也逐步吸引了更多的国内开发者参加到Redis建造中去。尤其是在Redis core team建立之后，社区maintainer也和Redis一样变成了多线程（1->5），关于issue和PR的快速处理大幅提高了社区的活泼度。这次7.0的release note中也能够看到现已有超过5名国内开发者奉献了中心feature，并奉献了近对折commit。

这些变化与咱们在阿里云上的核算成果也是相符合的：Redis现在相同也已是国内用户运用规划最大的NoSQL数据库之一，并一向处于高速添加中，越来越多的泛互联网乃至传统职业也在逐步接收Redis，用于快速高效的构建事务运用服务。

尽管Redis开展迅速，但国内用户却大都无法享用技能盈利

Redis社区现在主流保护版别是6.0，5.0版别现已进入低保护阶段，而国内还有许多2.8，3.0，4.0版别在运用中。这就很对立，一方面，一些对用法，功用，安稳性和抖动操控的才能都奉献在了新版别上，另一方面，国内用户却“看的到，用不上”。

除掉6.0，7.0上的高档安稳性优化不说，比方在4.0前，没有lazyfree删去一个大key是同步的会卡住数据库引擎直接导致事务中止。又比方，Redis其实安全性尤其是lua是一向有较大问题的，这些晋级也都“隐含”在了新版别中。尽管阿里云仍然在坚持把这些漏洞的修复拉回到低版别上，可是在公网傍边仍是有许多的低版别实例存在安全危险。

过多用户忧虑晋级版别的兼容性，一方面阿里云也在要求社区来供给一些兼容性验证东西，另一方面阿里云对版别跟进是很快的，能够让用户在新版发布后赶快进行验证。从Redis全体和阿里云的许多客户晋级情况来看，版别的向前兼容性是十分好的，大可定心晋级。

希望更多的国内用户深度参加社区建造

国外运用Redis的方法和国内运用显着有差异，比方国外更多的是运用在缓存场景，而国内大多数的用法却是内存数据库。社区的开展和roadmap的制定，现在国内用户的声音较小。

现在国内开发者在社区活泼度很高，但更多的是围绕在bugfix，和feature上。咱们仍是主张无论是国内开发者仍是运用者能够深层参加进去，举个简略的例子，提需求、讲明白需求、证明需求的合理性都是参加社区建造，这样才能更好的把咱们国内的需求传达，后续乃至能够深度参加开发，跟踪交付，这些社区工作的含金量无疑更高。

在功用上，不只仅包含API层面的添加，包含接入，可观测性，共同性，共同性和安全等现在社区都在等待需求中。尽管core team member能够代表国内用户来把一些需求写进roadmap，可是真实用户的发声会供给更有力的支撑。

Redis运用场景拓宽与展望–Redis还能做什么？

多模服务进入迸发期

Redis是一向贴着用户运用开展起来的，它如此受欢迎主要由于两个特色，极高的功用以及丰富、方便运用的数据结构，这些简略好用的数据结构能够大幅度下降开发事务复杂度。

咱们能够看到，以Redislabs为代表的厂商正在大力的丰富Redis的数据结构（modules），如RedisSearch、Redis-Json、RedisGraph、RedisTimeSeries和RedisBloom等。

相同的，阿里云内存数据库Tair很早就在研发各类增强数据结构和模块，现在咱们在公共云Tair服务中供给的商业化扩展型数据结构比Redislabs供给的更多，部分模块功用更强，有兴趣可参见文档（本文结尾参考资料）。

现在已有许多云上用户在运用Tair增强型数据结构来构建代码，提高开发功率，乃至完结此前难以完结的工作。2022年是一个Redis扩展结构的迸发年，业界现已渡过接收期，进入高速开展阶段。无论是Tair仍是Redis，咱们信任不断丰富的数据结构能够让它们走的更远，从缓存演变为高功用的核算型内存数据库，打破、并处理更多场景问题。

共同性才能上的开展

落盘共同性和副本共同性是运用数据库绕不开的两个话题。长时间以来许多人对Redis的运用场景只是认定为缓存（尤其是国外用户）。Redis自诞生之初便支撑耐久化机制RDB和AOF，而且AOF还供给了不同级别的耐久化语义：如appendfsync选用最高档别always时能够确保数据完全落盘不丢失，具有与传统数据库一样的强落盘共同性。

在多副本共同性上，主要是指主备共同性上，原生的Redis仍旧选用异步仿制，数据修正操作只要在本地履行完结就会回来成果，相比于其他数据库没有供给副本间数据强共同的语义。这也约束了Redis的运用场景，在对数据可靠性有极高要求的用户（例如金融职业，和传统职业）中还没有被完全接收。

现在业界也都在对Redis的耐久化才能上进行开展。比较有代表性的，是阿里云的Tair耐久内存版、AWS的MemoryDB、和业界开源的一些Redis-like的根据rocksdb的体系，商业化如Tair的容量存储版（前混合存储）。

表1: 社区Redis和其他商业化、开源产品的落盘共同性与副本共同性比照
注1：与开源Redis社区版比较
注2：与开源Redis根据内存的运用本钱比较
注3,4：来自AWS官方博客测试数据

综合来看，随着用户对Redis的运用范围的扩展，与此一同关于容量、本钱和数据可靠性的需求也在不断提高，这些也逐步成为了衡量Redis企业级才能的重要指标。各大厂商和开源产品也都在构建这些才能上提出了许多处理计划。下面介绍一些典型产品和计划。

AWS的MemoryDB

AWS MemoryDB的思路是根据类似Aurora的同享存储概念，把日志存放在远端同享存储中，一同内存中仍然保存Redis原有的结构。经过这种方法提高数据的耐久化共同性，一同也确保了数据读取的延时和吞吐；而缺点则相同由于日志保存在远端，写入功用严峻下降（仅有ElastiCache也即Redis社区版的15%~25%，该数据来自AWS官方评测，见本文结尾参考资料）。在主备共同性上，由于直接采取日志的物理仿制，所以主备共同性近似挨近落盘共同性。

值得一提的是原来AOF rewrite这种压缩（compaction）引起的开销也由于在远端做掉而规避掉，因而是一种很完全的云原生解法。

阿里云自研内存数据库Tair

在耐久化上阿里云走了另外一条路，经过引入新介质耐久化内存来处理本钱，大容量和耐久化才能的问题。这个计划带来的应战是运用耐久化内存存储结构规划上较为复杂，既要操控功用衰减，又要确保兼容性。Tair耐久内存很好的处理了这些问题，比照MemoryDB本钱更低，读功用基本持平的情况下写入的速度也更快（见本文结尾参考资料），更关键的是基本原封原样的兼容了Redis API，大幅下降了用户的切换本钱。

而且，Tair耐久内存型还支撑半同步和强写入共同性，无论MemoryDB仍是Tair耐久内存都真实的做到了内存数据库的数据容错性要求。

其他开源产品的开展

国内也出现了一些原创性的优秀落盘开源产品（Redis-Like体系），这些产品大都根据LSM存储结构如rocksdb上的。它们的优点主要是磁盘介质相对内存更为便宜，但相同现在存在的缺点也十分多：运维复杂度较高，直接映射为运维本钱、KV无法原生的支撑Redis的数据结构、把Redis的强类型变成弱类型等等。

现在这类体系在共同性和容错性上仍有很大的改善空间，而在用户运用体感上，由于许多用户运用习气仍是把Redis-like体系用在事务的同步链路上，关于LSM KV引擎的延时上抖动全体吞吐的影响直接映射成了用户体感，因而很难作为一款通用型产品，而这些痛点也相同存在与Tair容量存储型中（曩昔叫混合存储版），这也是一个需求长时间在存储和兼容性上优化的方向。

综上所述，容量版别能够很好地处理用户的运用本钱问题，可是只要更好地处理了落盘共同性问题和副本共同性问题，才能够把Redis类体系的运用场景拓宽到企业级。这也是现在看来云厂商一个剧烈竞赛的企业级产品主流赛道，也有较高的技能门槛。

写在最终

Redislabs在2021年8月正式更名为Redis，咱们看到社区版Redis的主页也现已重构修正过了。本身Redis的商业化进度十分快，比方在主页上“夹带” Redis Stack；又比方在github大将一众常用的SDK都购买后，开端添加部分Redislabs商业化开源的支撑等。最终Redis或许也会像MongoDB，ElasticSearch一样走向完全的商业化。但现在社区仍是十分公开和活泼的。

Redis8.0的 feature计划现已开端，一方面咱们也如上文所述，主张国内开发者更多的参加到深层次的社区评论，让社区更多的向国内运用习气挨近，这对重度依赖Redis的国内企业情况是十分实际的；另一方面，能够经过社区参加来提高咱们的人才竞赛力，除掉耐久化体系，还有分布式架构，高吞吐低延时中心引擎，多模服务和脚本引擎，安全与审计等都需求持续投入。假如国内在Redis领域也能够有10～20名内存数据库的顶尖专家，那么即便是Redis走向商业化闭源其影响对国内用户都会十分小。

最终，欢迎咱们运用Redis7.0，也愿咱们一同在Redis等内存数据库技能上走得更远！

原文链接：click.aliyun.com/m/100034543…

本文为阿里云原创内容，未经答应不得转载。