朱国云：阿里云内存数据库Tair

德物科技始终以“上海最好的技术团队”为目标，建设学习型组织，形成技术知识积累，不断提升技术硬实力。 对内，举办技术沙龙、药品分享会、技术夜校、药品博客、得物小报、技术双月刊等，持续构建学习型组织，营造良好的技术氛围。 对外，持续提供得物科技沙龙、得物科技公众号、得物科技直播，主题涵盖稳定生产、技术架构、终端智能、体验创新、算法架构、云原生、大数据、研发效率、项目管理等等，期待与您交流，共同探索。

本次内部技术沙龙邀请了来自阿里巴巴的资深技术专家朱国云先生（宗代）为我们分享《内存数据库Tair实战》，因为他拥有10多年的分布式存储和数据库经验，并拥有领导了 Tair 的发展。 阿里巴巴电商双十一促销及单位建设高效运营。 在本次分享中，朱老师从“Tair的发展历程、Tair重要节点的技术挑战、云原生内存数据库Tair的产品形态、Tair关键能力解读”的内容开始。 得物的技术生表示，学到了很多有用的信息，也学到了很多。 来了很多。 为此，经朱老师同意，我们整理了老师讲话的主要内容，供大家学习参考。

-以下为演讲全文-

今天我们来聊聊“阿里云内存数据库Tair”。 我先自我介绍一下。 我的真名是朱国云，小名是宗代。 我是2008年加入阿里巴巴的，在阿里巴巴主要从事存储数据库相关的事情，包括文件存储、缓存、内存数据库等。最初参与阿里云飞天操作系统的研发，后来主要负责Tair的研发。

泰尔的发展历程

接下来我们正式进入Tair相关交流。 整体回顾包括Tair的发展历程、主要节点、技术难点以及相关实践。 我们先来看看“Tair的历史和发展”。 你可以看下面的图片：

泰尔的历史和发展

接下来我们看一下Tair在阿里巴巴内部的应用。

现在阿里巴巴集团内部，大部分BU的核心线上业务都使用Tair，包括最初的淘宝、天猫电商的交易导购广告，到菜鸟的电子订单物流配送轨迹，再到钉钉消息传递。 推送通知、优酷视频播放列表等，这些在线业务都使用Tair。

如今，在一些基于TP的线上业务场景中，业务的主要核心就是Tair加数据库。 Tair在这里的核心定位是承载极大的流量和高速存储，而不仅仅是一个缓存。 有很多商家直接用它作为内存存储。

从上面可以看出，Tair支持了阿里巴巴的大部分项目，并且在不断优化。 在这个过程中，Tair也遇到了很多技术挑战。 接下来我们就来看看Tair发展历程中的重要节点和里程碑。 技术挑战。

Tair的重要节点和技术挑战

2.1 重要节点

淘宝电商交易刚起步的时候，当时的业务架构相对于现在的系统架构来说比较简单。

在Tair诞生之前，我们内部有一个TDBM系统，它是一个独立的、独立的缓存服务，容量非常有限，访问次数也有限。 最重要的是它是单点，没有高可用性。 于是在2009年，开发了Tair 1.0。

Tair 1.0是一个独立的、集群模式的分布式缓存服务，同时也完全实现了节点的扩展和收缩，这与TDBM系统不同。 Tair 1.0形成基础技术架构后，Tair基于这条路线演进了很多年。

随着移动互联网的诞生，整个应用场景变得更加丰富。 电子商务更加繁荣，搜索广告推荐越来越多，社交网络兴起，手机游戏发展，LBS应用。 在这些行业的线上场景中，对缓存和高速存储系统的需求变得越来越重要。 从下图可以看到，Tair 1.0随着这些行业不断进化和发展。

数据量的增加对Tair的内存存储提出了新的挑战，比如如何低成本地解决互联网在线数据的存储和查询。 正如SSD固态硬盘已经成熟一样，Tair基于SSD存储介质实现了Tair LDB持久存储引擎，提供了高性能、大容量的解决方案。 2018年后，持久内存和新存储介质的出现也给Tair提供了新的进化机会。

总体来看，现阶段Tair已经从1.0的缓存定位逐渐演变为NoSQL存储系统。 在接口层面，也从最简单的KV接口发展到提供更复杂、更丰富的数据接口。

那么Tair的技术架构是怎样的呢？ 当时是一个比较典型的架构：SDK、管理节点、数据DB节点。 集群采用一致性哈希算法，通过哈希将数据切分为多个分片。 同时通过主从机制实现数据DB节点的高可用。

除了数据流之外，整体系统还有一套完整的来完成系统管理。 比如停机时自动切换、集群扩容缩容后均衡数据自动迁移等。 此外，还可以选择带有Proxy的架构，可以实现更丰富的访问聚合、连接汇聚等高级功能。

图中右侧实际上是单个DB进程。 它是一个统一的服务技术框架，可以支持多种存储引擎。 比如我们最初定义的Tai1.0 MDB就是KV内存。 上面的流程框架是完全一样的，下面的存储引擎可以替换。

2.2 技术挑战

接下来我讲一下阿里巴巴集团近年来面临的三个技术挑战，即阿里巴巴集团的单元化、热点、性能和成本。

单元化项目实际上是非常雄心勃勃的，这意味着从整个应用层开始，到中间件，例如MQ和TTDL，然后到Tair和数据库层。 当时Tair的三个主要部分包括MDB、RDB和LDB。 对于MDB，我们将其用作缓存。 因此，在做单元化的时候，不会主动进行数据同步。 而是数据库层会进行数据同步，然后到另一个单元进行反向失效。 对于RDB和LDB来说，很多业务都将其作为数据的最终存储，所以对于这两个块，我们相当于做了自己的数据同步方案。

这里更困难的问题是，如何保证源端写入的内容能够在目的地快速消费？ 这个问题与源端的写入速度、目的端的消费速度、两个集群之间的机房距离、网络速度等因素有关。 第一个是做好容量规划，第二个是流程方面，我们需要多做批量、合并处理，以流式的方式发送。

此外，也无法保证我们的任何系统，尤其是在线处理系统不会出现问题。 无论是新发布的版本，还是很久以前就存在的bug被触发，往往很难定位。 可能几分钟甚至半小时内都找不到。 此时流量可以快速切换到另一个机房，对整体业务基本没有影响。 这也是单元化带来的一个非常大的好处。

2016年双十一期间的一个插曲，我们的一台Tair机器流量极高，峰值在70%+左右。 当时服务器的QPS是每秒几十万次，但是数值规模却非常大。 一看就是一款热门的手机产品，也是当年双十一期间最火的产品之一。 它的访问量最大，所有流量都流向一台服务器。 当时还算顺利。 如果访问量和流量较大的话，服务器的流量可能真的会达到很高的水平，从而对稳定性产生影响。

目前，大多数存储系统和数据库系统仅从单个节点访问一条数据。 这个问题其实是很难避免的。 单个数据节点的访问量很大，造成这种现象的原因有很多。 比如有热点产品问题，或者业务写了死循环。 这些可能会导致某个节点的访问量特别多。

当年双十一期间，Tair最新的SDK居然有本地缓存​​功能，可以通过推送的方式开启。 但有的业务已经升级到新版本的Tair SDK，有的还没有，很难全部掌控。 这也是系统复杂、应用复杂、版本难以保证统一时的常见现象。 同时，SDK端的本地缓存占用了应用服务器的资源，内存非常宝贵。 这个缓存可能会对业务产生影响。 由于SDK端的解决方案并不是最合适的，所以我们考虑通过服务器端来解决。

最终讨论的解决方案是在每个DB节点上开辟一个热点区域，然后实时监控热点的发生。 热点发生后，热点会被推送到集群中的N台机器，比如10台左右的机器。 当热点发生时，我们可以使用集群中的10台机器来处理，而不是仅仅使用一台机器。

这里的核心关键是如何快速准确地发现并推送到其他数据节点。 这时候我们可能会在过期时间内读到脏数据，这对于大多数业务来说基本上是可以接受的。 如果不可接受，我们将不会启用此功能。

2017年又出现了一个新的问题，随着Tair在阿里巴巴内部的规模越来越大，就有了降低成本的要求，比如降低10%、20%甚至更多。

成本优化最直接的任务就是提高单机、单节点的服务能力。 如下图左侧可以看到，我们任何一个服务进程基本上都会有锁。 因为锁的存在，导致整个流程的性能跑不了很高，所以我们改造了整个MDB，包括今天的Tair。 改造后，每个操作都尽量在单线程中完成，相当于尽可能去掉锁，然后采用DPDK加用户态协议栈技术。 经过一系列的优化，下图可以看到锁只占了1%。 32c机器上的极限可以达到500万QPS。 如果是64c的机器的话可以达到几千万。 这个吞吐量基本上是线性的。 当然，当它真正在线运行时，并不是要跑到这么高的负载，而是要保证高吞吐量、低延迟和稳定性之间的一个权衡。 这项工作的成果之一——Tair，我们也在FAST会议上发布了它。

以上是阿里巴巴集团内Tair近年来面临的一些重要技术挑战，如稳定性、单元化、性能成本等。

云原生内存数据库Tair产品形态

经过多年的演进，阿里云的内存数据库Tair完全兼容&Redis，其中一部分是我们的图引擎，兼容开源和Neo4j。 我们还有一个支持标准SQL的引擎，我们用它来进行高性能的实时数据处理。 所以我们今天Tair内存数据库的定义是缓存，再加上高性能数据库和实时数据处理的定义。

Tair产品的架构形式其实和我们今天在阿里云上销售的Redis是一样的。 分为标准主从版本、双副本主从版本、集群版本。 所以最大可以从1G扩展到几个T。那么它和社区托管的Redis有什么区别呢？ 基于持久内存和云盘，我们推出了持久内存类型和容量存储类型。 这两者实际上可以满足客户对访问量和容量有不同要求的情况和场景。 性能增强版，它的整体性能比开源Redis高出一倍甚至更多，包括我们在里面内置了很多企业级的功能，针对客户的关键业务场景。

今天我们主要推荐两种形式。 一是Tair性能增强，相当于客户业务的核心关键场景。 我们建议客户选择它。 与开源Redis相比，首先它的性能更强，可以支持由于操作活动或者业务变化导致的流量突然增加，访问连接数也会更多。 开源Redis要支持几万个活跃连接其实很难，但是Tair的性能增强其实可以支持几万个。

比如我们实际看到很多客户使用社区版的Redis，采用一主五从的方式进行读写分离。 这个架构可以看到整个扩展性非常低。 它是从从节点读取，读取的一致性实际上会比较弱。 因此，我们向客户推荐集群版本的Tair。 最终价格比社区版贵了1.2倍，但是整体容量是社区版的4倍，包括总吞吐量，也是4倍。 因此，Tair的性能增强版在很多场景下对于客户的整体TCO来说相对比开源版本更有优势。

2018年之后，我们以持久记忆的形式花费了很多经验。 我们有两个核心目标。 首先是提供比社区Redis成本更低的系统，性能与Redis类似。 吞吐量约为社区版redis的90%+，成本约为社区版的70%。 比社区版本更好的是，每个操作都可以持久化并落入持久内存中。

下一页是我们的持久内存性能比较。 左边是Redis 6.0，右边是Tair持久内存版本。 我们可以看到写入和读取性能的总吞吐量约为90%+。 右图中，客户端延迟为 P95（us）。 我们去掉了Redis中的AOF重写机制，因此毛刺抖动更低。 由于持久内存本身的原因，读取确实比全内存版本慢一点。 访问延迟会更高。

接下来我们看第四部分，这部分其实是讲支撑我们Tair产品形态的关键能力，包括和开源Redis的核心区别是什么，关键技术点是什么？ 我们先来看看客户使用Redis的一些痛点。

云原生内存数据库Tair关键能力

4.1 Redis的一些痛点

我们可以看一下为什么左右的痛点是这样的？

其实总结就是开源Redis在访问链接过多的情况下性能会下降。 但容器化时代，应用服务器越来越多，每个应用的访问连接数也会增加。 几千、几万是很常见的。

另外，从延迟&抖动来看，Redis实际上是单线程的。 这种情况下，只要有一个慢查询，比如，往往会造成整体变慢，其他短查询也会变慢。 没有处理好。

HA高可用会造成误判。 和之前一样，在比较大的情况下，处理线程会完全占用CPU，HA活判断可能处理不完，所以它的整个数据操作和控制操作都会被中断。 它是在工作线程内处理的。 另外，整体内存统计不区分，因此用户经常会发现在实例内存未完全使用之前发生数据淘汰。

那么，我们从内核技术的角度来谈谈Redis和Tair的区别。

4.2 Redis 与 Tair

上图左侧是开源的Redis。 在6.0之前，它是单线程的。 6.0之后，号称是多线程，但从右图可以看到，只是在IO处理上变成了多线程，但在实际内部数据操作时，仍然是单线程。 做。

为什么很难使其成为多线程？ 首先，因为原来的Redis内部，一切都是单线程的，大部分操作都是没有锁的，所以改成多线程是非常困难的； 第二，代码是10年前写的，没有被返工过。 据了解，优化历史代码是比较困难的。

对于 Tair，我们脱离了 Redis，自己从头开始开发。 我们将网络接收线程和工作处理线程分开，两者都可以以N x M的方式灵活分配； 这样，Tair 就可以处理数十万个活跃连接数，因为有足够的网络线程，单机的处理引擎可以提高到足够高，甚至可以达到百万级别。

业界也有一个讨论，是做成分布式好还是做成单机式好？

在我看来，很多时候，单机格式会有很多优势。 今天的业务变得越来越复杂。 如果做成分布式的话，往往会出现一些跨节点的计算，这些计算甚至可能需要交易。 形成集群后，跨节点计算和交易将变得越来越复杂和难以处理。 这种情况下，为客户提供大规格、大访问处理能力的单机引擎其实是最合适的。

当然，我们也做了一些多线程内的慢查询请求，实时监控，分离到慢查询请求池中。 对于这类工作，我们尽量保证用户的请求能够在相对一定的访问延迟内返回给用户。

接下来我们看一下Tair引擎的高可用性。 前面我们谈到了 Redis 的社区版本。 它的探索和数据操作实际上是在一个工作线程中。 因为当数据运算慢的时候，会出现一些误判，所以我们把所有的控制请求放到一个独立的处理系统中； 使用这些HA来完全隔离这些访问、统计信息等，包括用户数据访问和系统高可用性统计，以保证更好的质量。

接下来我们来说说Tair的集群架构。

4.3Tair的集群架构

Tair的集群架构，包括迁移和扩展，与开源社区版本完全不同。 开源社区都用它，相当于P2P进行信息同步和探索。 另外，随着它的节点越来越多，集群中实现信息一致性的速度也会越来越慢。 社区版的迁移扩缩容是基于key级别的，所以当key较大的时候，往往会出现一些迁移滞后等情况，这时候也会出现一些HA的误判。 我们现在在这方面做了一些改进，相当于中心节点对整个集群做HA判断，包括集群管理。 整个数据迁移是按slot进行的，所以整个迁移速度会比按key快很多。

4.4 具体重要场景优化

相当于Tair和Redis中用于消息处理。 如果挂载了很多客户端，原来的单线程实际上会推送得更慢。 它的单线处理相当于将其视为Tair中的多线程，因此这是一个并发处理操作。

4.5：丰富的数据模型

它拥有丰富的数据模型，实际上是阿里巴巴内部实践中积累的常用数据结构，目的是让业务开发更简单。 从上图可以看到，我们的一些结构是对外开源的，包括： 客户使用。

接下来我们看看Tair的企业级能力。

4.6 Tair的企业级能力

这里我主要讲Tair企业级能力的三个部分，包括全局多活动、安全能力和Tair引擎可观测性。

当今的一些客户，尤其是中型和大型客户，希望在多个地区从事多项工作。 所以今天我们可以同步三个区域的多个活动。 其原则是三地多活动。 我们还建议，当一个应用程序执行多个任务时，可以在应用程序级别通过键将其分发到多个单元。 这将更容易避免冲突。

安全能力也是公有云中比较重要的一部分。 我们给客户提供的实例是在VPC内，保证整个网络的安全。 客户可以通过SSL加密对Tair的访问，SSL可以对更高级别的访问通信进行加密。

我们有一个功能叫PITR，可以帮助客户将数据恢复到客户指定的任意时间点，可以降到秒级。 另一个重要的功能是用户审核。 经常有客户问，为什么我的访问量这么高？ 这个访问源从哪里来？ 或者我的数据已经被清除了，删除到哪里可以通过这个看到。 所以从整个技术实现的角度来看，我们实际上做了一些高频的快照，你可以认为是全量快照，再加上增量的快照来帮助客户恢复到那个时间点。

我们在可观察性方面也投入了很多，但是当然还有一些事情我们做得不是特别好。 例如，我们一直在探索集群级别的聚合工作。 我们可以实时看到热键和访问量比较大的按键，包括引擎层面。 可以看到每个操作的访问延迟。 一旦慢了，我们就可以看到哪个操作慢了。

泰尔应用

在电商中，Tair主要用于缓存和内存存储。 一般用于登录系统、用户系统、产品系统、购物车、个性化推荐等。

对于游戏客户来说，最重要的不仅是低延迟、弹性伸缩、高可用性，还有备份回滚和非侵入式扩展。 今天我们正在积极扩大产能，它的业务不会下线。 这是通过我们的整体集群解决方案（包括数据迁移解决方案）向客户提供的。

在财务和安全风控方面，Tair做了一些计算，比如一定时间内购买的商品数量。 这种类型的计算可以用来防止黄牛和反作弊。

LBS生活服务主要通过实时功能完成。 它与Redis最核心的区别在于它只能进行点对点的邻近查询。 例如，它只能搜索最近10公里内的人或离我最近的商店。

总结

第一部分讲述了Tair从阿里巴巴集团的发展到13年后在阿里云上面向客户推出的过程。 从单一缓存到帮助客户构建多样化的实时场景。

第二部分是阿里巴巴集团内部过去几年面临的一些重要技术挑战，包括热点、多活动、性能、成本等问题的解决和优化。

第三和第四部分是通过Tair自研引擎充分利用云基础设施上的不同存储介质，为客户提供更合适的选择和更高的服务SLA。 最后，Tair的应用解读帮助客户构建在线实时场景。

*编辑/

关注得物科技，每周一、三、五18:30更新技术资讯

如果您觉得文章对您有帮助，欢迎评论、转发、点赞哦~