Tair的重要节点和单元化、热点、性能与成本等技术挑战

kavin 运维技术 2023-01-29 790浏览 0

重要节点

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

在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节点的高可用。

整体系统除了数据流之外，还有一整套的泰斗（Tiddo）来配合完成系统的管理。例如宕机的自动切换，集群扩缩容后的自动迁移平衡数据。除此之外，也可以选择带Proxy的架构，Proxy可以实现更丰富的访问聚合、连接收敛、QueryCache等高级功能。

图上右边其实是单个 DB 进程，它是统一的服务技术框架，它可以支持多个存储引擎在里面。譬如，我们原来定义的 Tai1.0 MDB 那它就是一个 KV 内存的，就我们上面的这个进程框架是一模一样的，下面的存储引擎是可以替换的。

技术挑战

接下来，我会讲三个我们就在阿里集团这几年面临的这一些技术挑战，就是阿里集团做单元化、热点、性能与成本。

技术挑战–单元化

单元化这个项目其实非常宏大，相当于要从整个应用层开始，到中间件，譬如 MQ、TTDL这一层，再到Tair跟数据库这一层。Tair当时的三大块包括MDB、RDB和LDB。对于MDB，我们是作为缓存去用的。所以在做单元化的时候，并不会主动去做数据同步，而是由数据库这一层做数据同步之后到另外单元来做一个反向的失效。对于 RDB和LDB，很多业务是拿来作为数据最终的存储去用的，所以这两大块我们相当于做了自己的数据同步方案。

这里面比较难解的问题是，怎么能够确保源端写入的能够快速地在目的端所消费掉？这个问题会和源端的写入速度目的端的消费速度、两个集群间机房的距离、网络速度都是相关的。第一是要做好容量规划，第二是在进程上面，我们要更多地做批量的、合并的处理，流式地去发送。

另外，我们任何一个系统，特别是在线处理类的，没有办法确保没有问题产生。无论是新发版还是触发了一个很久之前有 bug 的情况，往往是很难定位的，可能在几分钟里面定位不出来或者半小时都定位不出来。那这个时候可以快速地把流量切到另外一个机房去，这样对业务整体基本上没影响。这也是单元化带来了一个非常大的好处。

技术挑战–热点

2016年双十一的一个小插曲，我们Tair的一台机器流量特别大，最高大概到了70%+左右，该服务器的 QPS 在当时几十万次每秒，但是value size特别大。当时一看就是一个火热的手机商品，也是那几年双十一最热的商品项之一，它的访问量最大，而流量都到了一台服务器上。当时平稳度过了，如果访问量再大一点，流量再大一点，那可能服务器流量真会跑到一个非常高的水位，对稳定性产生影响。

目前绝大部份存储系统和数据库系统，对于一份数据都是单节点访问，这个问题其实是很难避免的。而单个数据节点访问量大，造成该现象的原因很多，例如有热点的商品反问，还是业务写了个死循环之类，这些都可能造成某一个节点的访问量特别大。

在那年双十一，Tair最新的SDK 其实具备本地缓存的功能，可以通过推送开启。但是有的业务升级到了新版的Tair SDK，有的还没有，所以很难全部控制住，这也是系统复杂之后应用复杂之后常见的现象，很难确保版本统一。同时，SDK侧的本地缓存，占用应用服务器的资源，内存是非常宝贵的，这个缓存可能会对业务产生影响。既然SDK侧的方案并不是最合适的，所以我们考虑通过服务端来解决。

最终讨论的方案是，每一个DB 节点上开一个热点区域，然后实时监测到有热点发生。热点发生之后，会把热点推送到一个集群里面的 N 台机器数，譬如 10 台左右。在有热点发生情况下，我们可以用集群里面 10 台机器来扛，而不是像原来一台机器去扛。

这里面最核心的关键是如何快速精准地发现，然后推送到其他数据节点上。这个时候我们可能会有在可失效的时间里面读到脏数据，对于绝大部分业务来说基本上都是可接受的。无法接受的，我们就不开启这个特性。

技术挑战–性能与成本

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

成本优化，最直接的一个工作就是提升单机单节点的服务能力。下图左边可以看到我们任何的服务进程基本上都会有锁，因为锁的存在，使得整个进程的性能没有办法跑得非常高，所以我们对整个MDB包括今天的Tair都进行了改造。改造之后把每一个操作尽量在单个线程里面做下去，相当于尽量把锁去掉，然后再用上了DPDK加用户态协议栈技术。通过一系列优化之后，在下图可以看到锁只占了1%。在32c的机器上极限可以跑到 500万QPS ，如果是64c的话可以达到上千万，这个吞吐基本上是线性的当然，真正线上运行的时候，并不是运行到这么高负载，而是确保高吞吐、低延时和稳定的一个权衡值。这个工作中的成果之一——Tair HotRing，我们也将之发布在FAST会议上。