从Redis到Tair:开源工具的最佳实践

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: 《从Redis到Tair:开源工具的最佳实践》介绍了Redis闭源后Valkey社区的成立及其兼容性测试、性能测试、数据迁移与校验、客户端接入最佳实践,以及Tair的开源模块。内容涵盖Redis闭源背景、阿里云在Valkey社区中的贡献、Tair与Redis的兼容性测试工具(如resp-compatibility)、性能测试工具(如RESP-Benchmark)、数据迁移工具(如Redis Shake)及数据校验工具。此外,还详细介绍了TairHash和TairDoc两个开源模块的应用场景,帮助用户更好地理解和使用这些工具。

从Redis到Tair:开源工具的最佳实践

 

内容介绍:

一、Redis闭源与Valkey成立

二、兼容性测试和性能测试

三、数据迁移和数据校验

四、客户端接入最佳实践

五、Tair的开源模块和场景介绍

 

在《数据库专题:NoSQL数据库》直播中,本次分享的主题是从Redis到Tair:开源工具的最佳实践。

本次直播将围绕五个方面展开,首先介绍Redis闭源与Valkey成立,之后是阿里云为了Redis迁移到Tair准备的一系列开源工具,最后是Tair的开源模块和场景介绍。

 

一、Redis闭源与Valkey成立

2024.3.20,Redis公司宣布将Redis开源协议修改为私有协议,而新协议限制云厂商开始售卖7.2版本以后的Redis,对目前现有的Redis不受影响,此举措后,社区开发者作出回应,包括阿里云,aws,华为等十余家企业联合成立了Valkey社区,Valkey社区基于原来Redis BSD协议成立,并交给Linux基金会运营,避免再次闭源,因阿里云在Redis社区中做出较多的贡献,在新社区Valkey中阿里云拥有一名技术指导委员会成员、五名贡献者成员以及Valkey-Java客户端Owner,在社会future方面,阿里云贡献了主从无感HA在内的六个future内容,其中有一些已经落实,还有一些在进行中。

Tair是一款阿里云自研数据内存库,并全兼容Redis,虽然Tair 内核不开源,但在整个Redis开源生态中做出了巨大的贡献。除此之外,Redis提供了许多Patch并作出了巨大贡献。在SDK层面,拥有一名Jedis Reviewer、Valkey-Java 和Redis等多个开源客户端的推动者以及贡献者,在生态工具方面,帮助用户在Redis生态得到更好的体验,其中Redis Shake拥有3800+star,并成为Redis数据迁移事实标准,而Tair开展了许多模块,并助力许多用户的发展。

 

二、兼容性测试和性能测试

当人们替换一款数据库时,大家首先会进行兼容性测试和性能测试,通过后会进行数据迁移,数据校验,最后会将业务平滑地迁移过来,接下来会与大家分享在这些过程中人们会运用到一些工具。第一个是兼容性测试,开发兼容性测试工具resp-compatibility,(项目地址:https://github.com/tair-opensource/resp-compatibility,)来测试Tair与Redis的兼容性,主要分为三个部分。

第一部分是接口兼容的测试工具有7500行,包含400多个测试 case ,用来测试 Redis4.0版本到7.2版本的兼容性。

第二部分是 RDB 文件兼容 resp-compatibility ,可以将旧版本的 RDB 导入到新的Tair引擎。并且实时的验证它是否能支持旧版本的 RDB 文件来方便用户备份数据完整无误的迁移。

第三部分也是来源于社区的 VLK 社区的一个 feature,替换Redis 或者在替换 Redis 的过程中,有可能作为 Redis 的备库挂载到Redis 的节点上,使用 master 节点需要写入数据,等待数据同步完成之后从备节点读取数据来校验,从而获得它整个主备复制的兼容性。整个项目利用 git hub pages 也发布了一个网站,该网站上有列举对于常见的开源类的 Redis 产品以及阿里云的产品的兼容性。大家可以看到左边包括常见的 kdbkv rocks 以及阿里云的 Redis ,后面也会增加到其余的云产品上。

可以看到在集群版的模式下,由于 Redis 集群版跨 slot 执行命令的限制,所以它的兼容性实际上是比它的本身的单机版要低的,其用户不能直接单纯从单机版迁移到集群版,但阿里云的Tair和 Redis 可以通过集群版的 proxy 可以将很多的命令进行聚合发散的过程,因此用户可以像使用单机版一样使用阿里云Tair的集群版。从而兼容性也是比Redis 本身集群版要高的,目前报告是会周期性的更新,但是目前在开源之下的活动中,已经与四川大学的同学一起基于自动购买云上的实力,并且完成自动化测试的任务,这部分工作会在11月份上线,大家可以关注 github 网站。在进行完兼容性测试之后,需要进行的是性能测试。

在 Redis 的领域进行性能测试的工具主要是 Redis-benchmark 。但是 Redis-benchmark  它有一些固有的缺点,不能满足我们预期的要求,一方面是它的测试不太灵活。

第二个是对于例如像测试Hash测试等复杂的数据结构的时候只会生成一个 key,其实对于他来说是无法体现多线程的引擎能力,其不能将的引擎压满。因此开发并开源了一个名为 RESP-Benchmark 的测试工具,它的语法如下所示,大家可以用大括号括住整个key的格式,key的格式可以指定 uniform 或者 zip 的熟悉的格式。

然后RESP-Benchmark 默认就会启用压测机器上与 CPU 核数相同的线程数来启动整个压测程序,并且在压测的过程中也会动态的调节它的连接数,从而测出引擎最好的性能,右边是基于 RESP-Benchmark 制作的Tair和新一版的白皮书,对于白皮书的要求就是有 p99的延迟,也有平均延迟以及 QPS。并且客户使用的压测方法也可以复现的性能白皮书。

 

三、数据迁移和数据校验

做完性兼容性测试和性能测试之后,便可以进行数据迁移和数据校验的环节。Redis shake 是一款专门用来做 Redis 之间或类 Redis 数据库之间迁移的工具,可以通过备份文件 Redis 集群和单机以及其他不支持开放协议导出的数据库进行迁移。

备份文件其实就是非实时的一个迁移方式,用户用 RDB 文件 Redis 进行解析之后,导入到目的数据库,偏向实时的导入的方式是 Redis 可以利用模拟 rica 节点来挂载到 Redis 的集群或单机上,通过 Redis 的复制协议来将数据导入。

整个过程有两个步骤,第一个是发送全量的 RDB 阶段并解析后,对于增量的数据,会通过直接发送 AOF 的命令导入到目的端,对于既不能通过 RDB ,也不能通过支持 Psync的协议的导入方式,Redis Shake还支持 scan的高级模式, scan 的高级模式是会连到云端的数据库上,通过便利数据库中的key,然后通过 dump+的方式拿到所有的数据发送到目的端。

但是有一个问题是在导入的过程中,如果产生的增量变化需要及时同步的话,就需要通过订阅 Redis keyspace notification 机制。从而能拿到导入期间key增量的变化,从而实现数据的实时同步,以及全部的全量同步。除了上述的同步模式之外,还可以支持对于导入过程中,对于用 LUA脚本对于数据进行加工是一个非常实用的功能。也就是用户可以实现 LUA脚本来在导入过程中实现它数据的一个 ETL 的过程,比如说只想导入某些 prefix 开头的key,或者说想在导入的过程中过滤掉某一部分的 key 都是可以通过LUA脚本机制来实现的。 Redis 它作为 Redis 的数据迁移的一个事实标准,它的社区也非常的活跃。

有40多个 contributor 累计贡献过代码,并且有八百多个Issues属于 PR,社区目前已经有3800个 star。在进行完数据导入后,需要进行数据验证。也提供了数据校验工具来进行两个 Redis 之间的数据校验,原端可以是 Redis 的单机或者集群支持异构的校验。它校验的原理是,首先会进行多轮的比较。在第一轮的过程中会从原端抓取整个原端的key,然后用原端的 key 作为对比的基础点,然后目的端查看是否有差异。如果有差异的话,会将差异存储到本地的Splite DB 中,在第二次的比较中,从 Splite DB 中获取到之前的有差异的可以再进行一次对比。默认的轮次是三次,大家可以配置上述的配置。

更多的轮轮次如果需要的话,通过比较收敛的方式,直到最后得到两个两个需要对比的节点key是否一致。值得一提的是,Redis Full Check 的对比过程实际上是单向的,也就是说如果需要两端同时来对比是否完全一致,需要反向再做一次对比。

对比方式也支持三种,最简单的是校验它的key是否一致,然后更复杂一点的可以校验 value 的长度是否一致。最严格的模式就是除了校验上述的两种之外,仍然校验 value 的值是否一致。因为对于 Redis 而言,它的key通常是比较小的, value 是比较大的,因为 value 的整个校验是比较耗费时间的。在进行完整个数据的校验确认无误之后,可能会尝试的将 Redis 的连接地址修改为目的连接地址来将整个业务进行切换。

 

四、客户端接入最佳实践

由于在服务云上众多客户的过程中,接触到了非常多的开源客户端,这里也总结了一份Redis开源客户端的最佳实践分享给大家,第一部分是一些常见的语言推荐了相应的客户端,比如对于Java领域,推荐的是Jedis以及Valkey Java 客户端,Jedis它是Redis Java 中使用最广泛的一个客户端,使用量是其余客户端的十倍还要多。

但由于前面提到的前述提到的整个 Redis 的闭源以及相关的事,也为Valkey了一个Valkey Java 的客户端,是阿里现在在维护的一个客户端,还有其他的一些领域,包括C#、python等一些常见的开发领域。除了这些客户端之外,在的官网文档上也提供了非常详实的一些连接Redis的事例,包括连接单机集群,通过TLS模式,通过center的模式,也有一些常见问题的排查文档。

刚才提到的Valkey Java客户端是因为在Redis闭源之后可预见的社区,其实它已经走向了一个分裂,在新的开源社区中Valkey 也会有自己的一些 feature,如果想要让 Redis 公司控制的这些客户端支持它的功能是不太现实的。因此社区的开发者也为Valkey创建了很多新的客户端,无论是 fork 还是从头开始编写。

现在 Valkey 已经有五种语言的客户端,其中 Java 语言就是阿里贡献的,它的是完全和Jedis兼容的,只需要用户修改就可以将整个的业务从迁移到Valkey,目前已经完成两个版本,第二个版本也已经支持了最新的Valkey的新需求,就是主从无感切换,通过主从无感切换用户在主动运维的过程中可以感知到更少的错误,也为整个的大规模运维提供了可能性。还有一些未来的计划,包括支持异步的API,然后加强可观测性,优化集群模式下的连接数量等。

 

五、Tair的开源模块和场景介绍

最后一部分介绍一下Tair的开源模块和场景分享Tair,它在服务阿里和整个云上客户的过程中沉淀了非常多的module,大多数是适配一种业务场景或者是多种业务场景。如果第一个session中客户介绍他们用 tell 的rolling bit map来做整个的RTA的广告推广,目前一共有十余款的module,其中五款已经完全开源到github来供大家使用。今天重点介绍的两个是TairHash和TairDoc。

TairHash是一个支持 field 的过期的一个Hash的数据结构。在 Redis 最新发布的7.4版本中,他们引入了个Hash结构来支持 field 的过期,但结构其实在五年前就已经线上使用,并且在三年前,TairHash的 module就已经开源到github了。它的内存结构与原生的Hash不同的是,它不仅仅会在dict中保存一个KV的这么一个简单的结构,而value 的结构是经过设计的,value的结构需要有两部分,一部分,除了原生的保存Redis的这一部分的field和value之外,还会引入一个排序结构。

排序结构一旦用户为它的field设置了一个过期时间,可以理解为小点堆的形式,就会为排序结构维护到排序结构中,将整个顺序维护。在需要过期的时候有两种过期方式,一种是主动过期,一种是被动过期。

对于主动过期,会周期性的扫描排序结构,看哪些field已经到期了,就会把它删掉。被动过期是当写入TairHash的 Key。

或者说是进行一些操作修改的时候,会主动的检查本身的Key中是否有过期,在如此一种模式下,如果它的效率已经很高了,但并不是最高的原因在于如果说整个数据库中存在较多Key并不是TairHash的Key,所以每次扫描时,首先需要random的轮询到Key,它的效率本身比较低,因此还支持一种SORT的模式。

SORT的模式可以将每个DB中带有TairHash过期的Key,再维护一个web的索引,也就是其实还是计算机中一个比较经典的概念就是用空间来换取时间有这部分空间及索引信息之后,可以更快速的索引到整个的带有过期时间的field,并且迅速的找到,从而提升它的过期效率。这两部分就是适用的是两个不同的场景。一个是需要高效的过期,一个是正常的过期就可以满足,它整个的语法其实是与Redis的Hash是非常相似的。如果您使用TairHash的接口是非常容易理解的。

来看一个典型使用TairHash的例子,如果说有的用户要做一个登录态设备的管理,比如很多的APP它都是有登录限制的,也有可能使用多个设备来进行登录,如果在传统的只有一个设备,或者说是只有一个用户管理的这么一个单设备的模式下,用来做需求会维护用户的信息,以及TTL 就session的TTL ,然后利用Redis本身的过期机制,它如果到期了之后就把用户踢掉,用户下次就需要重新登录。但当用户如果有多个设备,它有一个手机,还有一个苹果电脑,或者说是windows的笔记本,这三个平台登录的时候,需要维护三条的信息,相当于从一到多设备的管理,它的Key的数量实际上是增大了三倍的。

但如果使用太小TairHash就可以将用户的笔记本电脑以及他的手机全部都放在同一个Key下面,只用为每一个 field 配置过期时间即可。如此它的整个业务设计的架构上也是更容易理解和对于Key的组织上也是更加容易,无论是理解上还是运维上,都是更方便的。

第二部分是TairDoc,它支持存储和修改json的结构,因为Redis其实它本身一直不支持json的结构,在社区中有类似于Redis json  如此一的个module来做事,TairDoc 其实就是对标Redis json  的一个结构,对于存储json这么一个需求,其实在Redis中也是非常常见的,比如说在这里会存储一个带color,还有一个车的颜色是蓝色,一个模型是比如说它是80的需求。在Redis中要做事就需要把 key 以来存储下来。

然后读取的时候会先读取Key,然后反序列化再修改,再把json序列化出来再存储,如此它其实需要做七次交互,但是如果使用TairDoc,在服务端就已经将json以数的形式存储在了存储引擎中,并且只需要使用json set命令来指定路径修改,比如color red命令,就可以完成整个修改。它的RTT就会从四次减少为一次,并且也减少了整个序列化和反序列化的开销,并且目前也已经开源了,而且后续也在做自己json的过程中,同时会跟进和推动json的发展。

一方面介绍了在开源上面所做的项目以及在整个Redis生态中为大家提供的工具Tair,也欢迎大家有机会可以参与Tair的开源生态。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
8月前
|
存储 监控 NoSQL
35个Redis企业级性能优化点与解决方案
Redis作为企业级应用中广泛使用的高性能键值存储数据库,其性能优化是一个复杂且多面的话题。以下是V 哥整理的一些关键的优化点和相应的解决方案,提供给兄弟们参考。
|
9月前
|
存储 缓存 NoSQL
Redis 服务器指南:高性能内存数据库的完整使用指南
Redis 服务器指南:高性能内存数据库的完整使用指南
192 0
|
9月前
|
消息中间件 存储 NoSQL
Redis开发最佳实践
Redis开发最佳实践
125 0
|
9月前
|
缓存 监控 NoSQL
redis企业级解决方案
redis企业级解决方案
143 0
|
缓存 监控 NoSQL
Redis常见问题企业级解决方案
Redis常见问题企业级解决方案
179 1
|
存储 缓存 NoSQL
课时1:Redis(Tair) 产品介绍
课时1:Redis(Tair) 产品介绍
|
存储 监控 NoSQL
Redis官方的高可用性解决方案
Redis官方的高可用性解决方案
183 1
Redis官方的高可用性解决方案
|
NoSQL Redis CDN
分布式服务器框架之搭建C#+MongoDB+Redis初步
WebAccount站点主要干的事儿是下发 服务器状态信息,这个服务器会和WorldServer建立连接,等所有的GameServer初始化完成之后会同步给WorldServer,WorldServer同步给账号服务器站点,然后账号站点等待玩家请求。
|
缓存 NoSQL Redis
Redis基础实践
Redis基础实践
135 0
|
存储 消息中间件 缓存
Redis高效实践
Redis 是一个开源(BSD许可)的内存中的高性能Key-Value数据结构存储系统,它可以用作数据库、缓存和消息中间件。支持多种类型数据结构,包括字符串(String)、列表(List)、集合(Set)、有序集合(Sorted Set)和散列(Hash)等。
183 0
Redis高效实践