Tair 整体介绍及在阿里集团的应用

开发者学堂课程【阿里云原生内存数据库 Tair 课程：Tair整体介绍及在阿里集团的应用】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/1198/detail/18168

内容介绍

一、Tair 整体介绍及阿里的应用

二、Tair 在阿里集团内的应用

一、Tair 整体介绍及阿里的应用

1、Tair 十三载砺剑，助力企业构建在线实时场景

Tair 的发展过程，Tair 其实到现在已经有十三年的历程了，Tair 诞生在2009年，Tair 当时在淘宝的应用发展过程中诞生的，Tair 一开始的定位是一个缓存，Tair 开始被用在了淘宝的用户中心，商品中心这类业务场景。随着2009，2011是这几年的移动互联网的发展，Tair 也从一个缓存定位逐步走向一个分布式持久化 KV 的定位。在过程中，其实 Tair 的应用场景也也发生了非常大的扩展，就在淘宝、天猫的记录登陆的过程中，浏览的商品的过程中，交易下单的链路，购物车，交易快照，包括广告推荐里面 Tair 都是作为缓存跟持久KV存储在被业务所使用的。在2014跟2015年间，在阿里云上推出了云 Mencache 和云 Redis 社区版这两个云产品对外提供服务，集团内部这条线还一直在往前走，在2015年之后，推出了 Tair 2.0，Tair其实是兼容的redis的数据结构，并且在产品的稳定性，产品的体验，产品的吞吐性能上做了非常大的提升，还在这个过程中孵化了 TairGraph，这是一种变相高度连接数据的存储、查询和分析的系统。在2019年之后，这些集团内的产品跟云的产品全面去融合，集团内外使用一套产品去使用，所以在前两年 Tair 其实在云 redis 的社区版以企业版的形式早已经在对外部客户去服务了。在2022年，也就是上个月九月份，把 Tair 正式推出云原生内存数据库 Tair，今天正式在阿里云数据库 NoSQL 栏目下直接看到包括直接去购买使用。

2、Tair 全新升级--云原生内存数据库

Tair 全新升级成云原生内存数据库，Tair 的产品定位是什么？

第一，整个 Tair 其实还是实时在线的场景中，期望通过更多的数据结构，更多的数据能力来帮业务的实施场景做得更高效，更便捷，所以这是最基础的地方，所以从上图的左边中间下面来看，是 Tair 最核心的一部分，从接口上其实兼容了Mencache&云 Redis 包括兼容图引擎的 Gremlin，包括还在对 SQL 接口做一定的兼容性，所以其实希望提供给客户丰富的生态跟标准生态所提供兼容接口来使用Tair。

业务场景上，客户可以把 Tair 作为缓存用，其实客户认为可以跟 Mencache、云Redis 是一样的，客户也可以把 Tair 作为一个高性能持久数据库去用，这其实跟今天 Redis 是在大部分的业务场景中定位是一样的，还有一块就是相当于通过在内存中的计算做一些数据实时处理，图引擎包括 SQL 兼容之后做一些更多的计算处理，也是在这一块里面去做。

所以 Tair 的提供的能力主要分以下几块，从系统级别来说，Tair 要整个系统是纯自研的系统，在生态兼容，其实是兼容了开源的 redis/Mencache/Gremlin，整个的系统引擎上，其实相当于在数据安全性上比社区版本会做得更完整一些以对企业级客户的需求。然后，整个的系统引擎上其实是一个并行的处理器，比 Reids 的社区版，能够做到更高的吞吐和更低的延时。这样能够在客户的在线业务关键场景中能够发挥更大的作用，另外一个方面，就是在成本上面是客户一直在追求的，所以也通过内存 DRAM 存储器，内存 SCM。包括云盘 ESSD 一种混合存储引擎来帮助客户做到更低的成本。

最底层是阿里云基础设施，通过阿里云操作系统，包括神龙粿金属，包括倚天服务器这一类云原生基础设施，把 Tair 与云原生完整结合到一起做到云原生一体。

3、Tair 病行处理引擎，更高的吞吐和更低的延时

刚刚也说到 Tair 有一个并行处理引擎，与 Redis 的其实区别还是比较大。看左边这一列，像社区开源的 Redis 在六点零版本之前，Tair 都是一个单线程在做，所以Tair 的性能好，但是 Tair 依然整体性能与吞吐会被单线程所限。另外一点就是因为Tair 是单线程，所以 Tair 所能处理的活跃连接处也是有限的，如果是一个大几千万或者上万的连接，那么整体性衰竭还是比较大。在社区 Redis 6.0版本之后，Tair 把Tair 的网络处理现在改成了一个多 IO 的模型仪，以加速个网络处理的速度。

当 Tair 的个工作处理线程，数据处理这部分还是一个单线程并没有完全摆脱单线程处理的瓶颈，所以 Tair 这一块其实是把整个系统，就是把网络处理，数据操作这一块，完全是开发出一个多线程的处理引擎，这上面相当于提供给客户在一个固定规格之后，将来也能够不断的扩线程，能够在单进程里面提升处理能力，右下角是Tair 与 Redis 测试的性能对比，可以看到从吞吐的 QPS 上 Tair 要比 Redis 其实会高出特别多，高出了一倍及以上的，平均访问延时也会低很多，是由于譬如在单线程做单的处理里面每一个请求都需要排队去做，今天在多线程之后整个处理延时会低很多。所以带来的好处是今天有很多客户，在单个进程里面会有一些多余的操作，包括会有一些事物的操作，如果把这些操作去做成一个集群，由于单进层没有办法处理这种，把这些扩成一个集群之后，对于业务测来说，可能会要做出一些非常复杂去改造因为要把这些事务拆掉或者是在 Tair 系统层面做一些分布式事务的处理，这些会给系统复杂度带领非常高而且性能也不一定好，面对这一类的场景，如果单节点能够做的能力非常强大，其实是一个比较好的解决方案，包括业内前几个月有一个加工 flight 系统，其实做的也是一个兼容 Redis 的一个多线程系统,是一个开源的，其实今天的思路跟 Tair 有点相似，但是说 Tair 也跟云 Redis 做了一个对比，整个多线程性能还是比 Redis 社区版会高不少。

4、Tair 兼容生态回馈社区

Tair 在自研的同时，也兼容个社区生态的同时，也在不断的开源。从历史的社区来看，今天就是说全球总共五名 core team member 情况下有一名。还有两名contributor ，然后这几年总共贡献了200+的 patch，所以也其实一直在 redis 社区愉快，期望把 redis 社区建设更繁荣，也希望 redis 能够建设成为一个真正的实时数据处理的平台，然后除了给 redis 社区做贡献之外，也开源了自己的一些工具 SDK , Tair Modules。生态工具这一块开源了 RedisShake，是一个在 Redis 实例间相互搬迁数据的工具，今天其实被非常多的外部客户所使用包括有一些云厂商也是在用这些工具，SDK 除了 Tair/java/go/python 等 SDK，在将来也会放更多的功能到 SDK 里面去做。在集团里面，其实在前几年积累了一些非常好的数据结构，像TairString TairHash TairZset 也以 module 方式开源出来，这些数据结构其实带了版本信息，包括只 field 上带了 TTL，对于客户来说，客户往往并不是想把整个K在某一个时间上过期的，而是希望里面的一个只 member 、只 field 在某一个时间的过程。所以这些数据结构其实，能够在客户非常多场景下可以去使用。

5、Tair 完善的企业级安全能力

除了建筑生态回馈社区之外，Tair 相比于社区开源的 race 来说，在安全能力上，其实做了非常大、非常多的工作，社区的开源的 Tair 来说，工作主要是在高性能应用性，其实在服务高效同时要把安全性做好，所以在链路层面，真正健全审计层面，包括在数据的安全层面，其实都是在这上面做了非常多的加固，比如有白名单安全阻挡，其实相当于 SLGS 之外，客户可以确定客户哪一些服务，可以访问 Tair 实例的，然后落盘加密这块可以帮助客户来选择去开启 TDE 透明加密的，相当于落盘的数据是已经加密过的，还提供了自动备份的功能，包括提供了按任意时间点回溯功能，这个功能其实今天面向有很多客户，包括这几年也听到有一些客户被脱库、删库之类的，这个功能可以帮助客户把数据恢复到之前的某一个确定的时间点上去，可以精准到秒级别。

6、Tair 可观测性，快速定位问题

除了安全性之外，在可观测性上其实也是的一个工作中心。因为整个 Tair 的定位，在前面说过在业务客户的在线实施场景中做一些数据查询与管理的功能，对客户的稳定性来说至关重要，因为一旦出问题，整个业务可能就没办法服务了，所以今天其实从多个维度上面提供了一些客户诊断的工作，比如当客户在访问出现超时或者访问异常同时，可以提供给客户审计部分，比如客户可以看到在当前 top 的访问客户端，包括 TOP 的执行命令式是什么，包括可以也可以看到服务方面的 Tair 节点里面把一些访问命令处理延时是比较高的，包括也能够看到实施的有哪些访问频率会比较高或者 Keepsigh 是比较大。这些都可以从系统里面能够看到，来帮助客户能够更快速的定位到问题在哪里。

7、基础 SCM 的存储引擎，降低增效

前面这一系列工作安全性、可观测性，包括的高性能跟 DS。能够帮助客户在在线实施关键场景上把 Tair 用起来。其实也希望能够帮助客户去降低成本，所以研发了把内存 Durbie 跟存储及内存 SCM 一个混合的存储引擎，把数据存储在 DRM 跟SCM中，在系统内部会是一个自动去调度的，成果也其实刚刚在2022的 VLDB 上去做了一个发布，整个系统的性能跟纯 DRM 纯内存系统相比，其实性能吞吐延时是在90%多，所以从客户测看上去访问延时基本没有变化，因为还有经历网络处理切换，其实没有什么变化，但是成本降低会降低了33%多，然后，另外一块就是跟DRM 的系统不太一样的是整个的操作，所有的操作都能够做到一个实时的持久化。包括没一个操作的节点上都会直接去入到持久存储介质上的。再加上系统层面的半同步机制。所以把整个数据的可靠性提升了很多。这些能力有的时候其实来看现有的应用架构一般是通过应用加缓存加持久存储。这三个组合来给客户去提供一个服务，如果今天 Tair 提供了一个比较高的吞吐性能够承担大流量，也能够提高提供比较好的数据可靠性之后。再有一些场景中，或者在有一定的数据规模的场景中这种相对来说客户可以简化一部分的应用架构去做，会给客户带来整体的综合成本降低。

8、Tair 在互联网兴业的应用

再来看一下，Tair 要在互联网中的行业中的应用是怎样的。其实是从一个电商上面就有导购，广告，交易，风控之类。其实今天在各个产业，在互联网往在线化过程中，这些系统大部分也都有，所以说是一个通用的系统。可以看到导购广告，商品详情，用户信息，广告物流，这些都是需要缓存来承担客户的访问量，所以要在这些成就做一个程序。另外，在消息推送，实施用户画，像指标平台这些业务所需要的高性能第一件事，但是也需要一定的数据高可靠，所以在这些场景中作为高性能数据库去用的。还有一些交易与风控，实时优惠系统，决策引擎，这些其实作为业务来说，需要做一些计算，再把结果返回过去，所以在 Tair 里面会在做一些的计算包括譬如在知识指标平台通过图引擎将数据进行融合，做一些计算与推理把最终数据返回上面给推荐的客户去用或者实施 Tair 类的客户去用，所以整个 Tair 其实是希望能够帮助业务，就在 Tair 的在线实时场景里面提供一站式的在线数据处理系统。就是希望提供更多的功能让客户用的更简单。包括通过云原生的技术让客户成本更低，包括整个的异常处理，能够做得更快，所以再来看一下，整个内存数据库业内的发展，包括 Tair 网站的发展情况，今天所看到的内存数据库，今天主要往前有这么两块，一个是提供更丰富的数据处理能力，比如拿 Redis 商业公司来举例，今天除已有的系统往前去运营，这几年提供了 TairString TairHash TairZset。Redis社区等数据处理能力，也看到这些模块其实是被越来越多的客户所用，Redis 社区是一个轻量级的全文搜索引擎，今天在看到很多数据再用。所以这条路线是提供更多的数据处理能力，然后另外其实作为内存数据库来说，虽然是把数据以内存储为主，但是在磁盘上依然会做，包括一些增量设置，所以如何确保内存数据库的高可靠性，其实也是内存数据库一直去做的，包括宜搭 AS 的 memoryDB。通过云原生的共享存储，来把数据存到共享存储上做到了数据的高可靠，所以在这方面的工作做了很多，包括也有 Tair 前面做的开源的数据结构，包括也有一些数据结构是没有开源的，Redis 商业公司是提供的这些数据都是对齐的，今天使用了 Redis 商业公司的客户，如果有一天想到迁到阿里云上，Tair 能够提供对应的功能出来。另外一块Tair 是今天用了阿里云的基础设施，阿里云云原生基础设施，譬如阿里云整个操作系统服务器一天，包括通用的共享存储，包括高性能的弹性，ADV 网络等等，来把这些云原生态的软件与 Tair 结合起来，能够给客户提供一个更稳定、更可靠、更高性能的系统，这是一直在追求的目标。

二、Tair 在阿里集团内的应用

今天带来的主题是 Tair 在阿里集团内的应用。首先做一个简单的自我介绍，花名裴度，2012年加入阿里巴巴，自2019年至今近四年时间里，深度参与了集团双11大促的保障工作，在保障工作过程当中，面临的主要技术挑战在于超大规模中用户并发以及超高的访问量，为了解决好这两个问题，Tair 作为重点的数据库产品提供了坚实的支持。今天借这个场合着重介绍一下采用 Tair 解决的一些重点问题以及在过程中取得一些心得，接下来开始正式的分享。

1、Tair 是阿里集团内调用量最大的系统之一

大家在阿里云的官网上面可以看到，数据库产品性提供了丰富的产品解决方案，其实在集团内部，也是采用不同的数据库产品，解决了各不尽相同的业务场景和技术问题。其中历史悠久的两款产品，分别是 MYSQL 内核逐步迭代产生的云数据库RDS，是一款典型的关系形数据库，另外就是今天介绍的主角就是 Tair，是 NOSQL产品里面的典型和翘楚，作为自身的用户采用 Tair 主要是基于两个方面的考虑，第一个方面是在于 Tair 的高性能，第二个方面在于 Tair 的高可用，所谓高性能，今天在双11保障的过程当中，单个的一个热点的 Tair 集群的一个访问量可以达到两千万，甚至更高的 QBS。为了满足这样的一个高可用量，其实需要的物理资源非常有限的，仅仅需要100台不到的 Tair 容器就可以支撑两千万的容量。同时在这样的访问量规模下面，在客户端可以统计发现 Tair 平均 RP 被严格控制在一毫米以内，在服务端更是被收敛在0.3毫米以内。另一方面，高可用这块，Tair 也提供了非常完备的一个考虑。在不同纬度都做了高可用设计，在日常运维当中，其实最常见的情况就是个别的数据容器突然出现了宕机，一旦这种情况发现发生之后，Tair 的自动巡检及 Tair 的自控能力就会定时的拉起新的容器，将故障容器下线，将整体的服务能力转移到新容器上面去，在过程当中，对于前端的应用以及用户来说是完全无感的，可以做到平滑无缝的迁移，整体的用户体验是非常棒，在一个更高维度的一个应用场景下面，典型的就是当出现系统性风险的时候，针对这种情况 Tair 会考虑说在同一个 RDS 里面，会在各自独立的 Az 里面部署个独立的集训，当单个 Az 出现系统风险的时候，会将流量快速的切换成一个 Az 的集训上面去，可以保障整个网站以及服务的一个持续可用，为整体带来一个非常高的可用性。有了高性能和高可用这两个关键的能力，整个 Tair 在集团里面得到了广泛应用，几乎可以想到的方面的业务都有 Tair 的身影，同时在集团的国际化和国内业务场景里面，在云的不同的区域 Region 上面都部署有 Tair，这是一个已经作为一个非常规范，常用的服务在集团内部进行使用。

2、Tair 丰富的形态对满足数据存储的所有需求

上面介绍了 Tair 在整个集团的一个使用的概况，接下来具体的产品，形态和使用场景进行介绍。今天要介绍的使用场景主要分为三大块，都有各自对应的产品解决方案，在支撑集团的业务。

第一个方案是比较常见，也是一个非常经典的场景，就是称之为内存的一个缓存，QPS 缓存。在这种场景里面，Tair 要解决的一个主要的问题就在于说要为后端的数据库抗压力，同时要基于一个高并发以及底延时为前端提供更高的吞吐，当然在这种场景下面，由于数据全部是保存在内存里面的，能够接受一部分数据的逐出或者说丢失，必须在一个方案选型的过程当中有一个考虑的一个点。

第二个是关于持久化存储的，虽然在读取和存储的形式上面依然使用 Kv 的形式，但是会要求一部分数据是能够持久化保存的，最主要在一些交易场景里面的交易快照，整体安全风控里面会有广泛的应用存在。

第三款，也是这两年跟 Tair 的一个逐步合作过程当中摸索出来一个新的场景，称之为数据实时处理，其实更加通俗的一个称呼就是在于说基于一些技术预测的算法，可以解决基于关系数据库做一些聚合类数据统计的时候，在大数据的情况下面，性能不能完全满足要求，或者吞吐不能满足要求的情况下，会基于这些算法提供一个安全可靠的解决方案，后面也会详细展开介绍。

3、Tair 支持了阿里集团内所有缓存场景

以下就来逐个介绍各个不同的业务场景和 Tair 提供一些特殊的一个特性。

第一个场景就是刚才介绍的最经典的场景，就是关于 TV 缓存，阿里使用缓存其实是非常简单直接的使用方式，但是同时也是被证明非常的高效，就是一个惰性加载的方式，缓存数据是通过用户流量，从关系数据库里面写入到 Tair，在后续的一个学习过程中，就可以在 Tair 里面进行读取，可以提供一个非常高的一个吞吐能力，以及非常低的延时。在使用产品里面一个最棘手的问题，其实就是关于一个单 key 的热点，在电商的产品上面一个会出现单 key 热点典型场景就是大主播，在带货的过程当中，对于商品或者对一些店铺的一个缓存访问量单 key 有时候会达到几十万甚至上百万，标准的 Tair 提供单 key 的一个访问量，其实已经相当可观，可以达到10万，但是在这种场景下面依然不能完全满足要求，这时候 Tair 就为提供一个称之为 Hot Cache 的一个热点打赏的能力，当在流量的访问过程当中，Tair 会自动识别出热点K，同时，将热点K在不同的上面进行复制，形成一份冗余，同时另一方面Tair 会将这份热点K的一个列表下发到所有的上面，在接下来的访问到这些热点数据的时候，流量就会被均摊到不同的上面去。通过这种方式，经过实测，单 key 的热点读可以从十万一直提升到200万，完全可以满足现代集团内部所有的电商业务的热点的需求，对于这来说是一个非常关键的提升，也是集团的业务能够稳定运行的一个非常重要的保障。

4、Tair 支撑了阿里电商二十年交易快照存储

接下来介绍第二个典型的使用场景，就是称之为说持久化存储的一个 KV，关于持久化储存 KV，个人最熟悉的一个业务领域，就是交易的订单快照，在这个场景里面，为什么要承担快照，是为了以后常在一个不定期，要处理可能一些交易的纠纷，需要说当时交易下单的时候，Tair 的一个商品的顺时状态是什么样的，以及Tair 的一些交易的一些当时的落盘收到的一些信息，存储这份数据，首先会使用 Tair 一个最基本的出发点在于这份数据的一个单个的空间会要求比较大，达到5KB，如果采用关系型数据库来进行存储，熟悉关系型数据库的朋友们可能会知道 Tair 会引入一个非常关键的问题，就是 Tair 的读和写都会引入到一个跨越的问题，一旦引入到跨越的问题，性能就是会出现线性的下降，是折半的一个下降，这是要极力避免的场景。所以在当年的技术方案的一个设计的意识，就采取了一个通过 Tair 的一个数据化存储来存储订单快照，既可以满足的业务需要也可以解决说关系数据库里面的跨越的问题，这是第一点。

接下来还有两个点，也是重点要关注的一个点。就在于说随着业务的经年累月的发展，到目前为止电商业务已经走过将近20年，这20年带来的数十 PB 的一个数据，订单快照的数据存储量，如果全部用标准的存储进行保存，会带来一个非常可观的一个成本的支出。Tair 团队也帮助一起对成本进行了控制，采用了一个所谓冷热存的方案，会将一年以上的交易快照的数据存储到一些冷存上面，比如说典型的是一个 OSS 的存储，既可以满足对成本控制的需要，也可以满足对历史数据低频的一个读取的需求，这样可以双面兼顾达到的一个收益的平衡点。

第三个解决问题，在于说阿里电商业务的特性采取了单一化，在单一化场景里边，由于用户根据不同时间段，可以切换到不同的单元实行相当于用户整体荣耀的伸缩性，这就要求所有的存储都必须是在所有的单元里面都有权量，就引入一个数据同步的一个问题，Tair 也是提供了跨 Redis 的数据自动同步的能力，是原生态 Tair 的内核中的，而且可以达到一个秒级的数据同步，在大促场景里面也是经过了历年大促的考验，是一个非常稳定可靠的数据同步姐居然方案。

综上所述就是 Tair 的一个持久化存储，解决关于数据库因为大存储列 RUITair 的问题，第二个以及经年累月的数据成本问题，第三个就是 Tair 的数据同步问题。

5、Tair 持久内存助力电商成本降低30%

在介绍完了上面两个点之后，这边稍稍的展开一下，Tair 关于持续的成本控制，刚才提到的无论是持久化内存的方案，还是以内存进行一个 KBE 缓存的方案，其实都会强依赖内存，而内存就是当中整体缓存当中 Tair 的一个成本方面重要的点，特别是在一些存储密集型的层面，在过去几年当中，通过 Tair 团队合作，Tair 团队引入了 Intel out 服务器，Intel out 服务器的一个特点就是提供AEP这种持久型内存的一个解决方案，同样规格的机器，AEP 机型的一个存储的空间是非 AEP 机型也就是传统的近两倍，而他只会带来有限的一个提升，综合考虑成本降低30%。另一方面采取了持久化内存上面会有一定的下降，但是通过 Tair 团队近年来持续的努力，现在不论从 QPS 层面，JPS 层面，还是从一个独写的 NTS 层面，已经逼近了传统的机型，已经达到了传统机型的10%，所以在一个完全可接受的使用体验情况下，使用成本已经达到了有效的控制，这是 Tair 团队在电商场景给带来一个非常重要的支持和优化。

6、Tair 助力商品销量架构升级

接下来进入到最后一部分的介绍，也是最后一个场景，就是前面提到的关于技术预测，为什么会有这种场景，就是关于过去以商品销量为例，当交易产生下单的时候会累加商品销量，传统有两种解决方案可以解决需求场景。

第一个场景是最直接的，就是通过关系型数据库，或者说通过分析型数据库的一个聚合计算能力，求 cache 或者 summer 可以满足业务场景的需求，这个解决方案里面 Tair 的性能是远远达不到预期的，特别是在有大量订单的一个实际的业务场景下面，并不能完全满足需要，这就造成在一些类似于大促的一些极端产品，不得已对这些功能进行有限度的降级。还有一些比较传统的解决方案，就是通过 Tair 的内存版本进行一个数据累加，相当于 CB 的计数器可以保证数据积累的有效性，但是由于内存版是一个意识的状态，也不能满足说数据要长期有效的需要，所以综合考虑这两方面的方案的一个优势及不足，在近些年来跟 Tair 一起考虑的方式称为技术预测，其实在社区的 Redis 上面有类似，就是 have lock，当然社区的方案，在空间利用率以及一个预测的准确度上面会有一定的提升空间，也是主要跟 Tair 团队一起合作，在上面有一些进度和一些优化方案的核心思想就是说基于预测，不会把所有的数据的比如说交易的一个完整信息，存储到存储空间里面，会对 Tair 相当于一个特征的抽取，同时会把整个商品的销量或者说一些数字进行累加的方式存储在的存储空间，当然累加方式其实是通过一些算法的预测方式进行落盘，整体取得一个平衡在可以去保存保密的情况，因为以同一笔订单进行对接之后可以实现一个去重，同时又能保证数据达到一个办法的准确度可以达到的一个使用场景的一个基本 sra ，同时 Tair 的一个吞吐性也是，无论用关系数据库的聚合函数来说还是一些解决方案来说都不能达到比拟的吞吐量，那么，综合这三方面考虑，就是最新的阶段里面，对于这种场景的一个基于技术预测执行的一个解决方案，而且目前来说，在共云上面看也已经提供了一个共云 CPC 版本供大家使用。