本次分享的是关于Tair的使用，云数据库Tair从稳定低延时缓存到Serverless KV。CONTENT整体分为三部分。第一部分，对云数据库Tair整体性介绍。第二部分，在缓存过程中怎么做到稳定低延迟技术。第三部分，在AI的大模型时代，应该如何将Tair从缓存往Serverless KV转移。
一、云数据库Tair概览
首先对Tair进行整体性介绍。从Tair的定位上，Tair是稳定低延时的缓存以及对KV的数据库服务。从生态上，Tair整体兼容Redis开源版，如果以Redis开源版的左从板所支持API集为全部集合，开源版的集群版对于左从版所能支持的API只有70%到78%，所以集群版对开源版的支持度并不高，但Tair的左从版和开源版完全兼容。集群版的兼容度在80%到90%之间，比开源版的集群版API兼容度高。另外Tair提供了不同的形态，可以使客户在各个业务场景中使用。单副本包括左主从版本、集群版、智能读写版，所以单副本可以用于测试环境，左从版本用于生产级别。在整体上Tair可以提供持久内存性，包括磁盘的Serverless KV给客户提供在不同场景对不同性能数据量成本有要求情况下做出综合性考量。
二、建设稳定低延迟缓存的关键技术
建设稳定低延迟缓存cache技术的挑战和解决方案
1.缓存的挑战-稳定承载流量变化
首先Redis的开源版以及在客户使用过程中可能会遇到的一些情况。Redis整体性能良好，但在中大规模以及集群规模下，会出现被爆破的情况，导致这个现象的原因是单个工作处理线程天花板能力是有限的，处理的KPI基本上在10万左右。在可运维性和稳定性上，譬如在集群下会遇到未知的情况，包括遇到超时抖动很难排查。
2.超越Redis的性能-轻松应对爆发请求
在整个Tair性能稳定以及可靠性做了非常多的工作，一是Tair采用了多线程的处理机制，相比于开源版Redis6.0，它号称多线程，但真正在处理数据上依然是单线程处理，所以整体处理的性能上限不高。通过Tair多线程之后，单进程的吞吐量是开源版的2.5倍左右，包括平均延时基本上也是Redis 6.0的50%或60%。在此性能与吞吐下，可以让客户在更多关键的场景下使用。
3.缓存服务的稳定低延时技术挑战
客户使用Redis或Tair的过程中碰到比较多的问题是超时了该怎么办以及该如何去查？如果我们使用的是开源版，由于开源版的可观测性差比较多，所以很难去定位。Tair从这方面，进程内核级别包括无所化、异步化技术，把慢查询隔离掉，可以做到在有慢查询情况下，把短的产品做到比较好的处理。
4.建设稳定低延时的缓存
把Tair的内核和阿里云操作系统紧密结合，将Redis开源版一直难以解决的问题，如在做快照或者做AOF、folk的情况下，有抖动的弊端解决掉。如果使用Redis是开源版32G的进程DB做folk时，可能会卡顿几百毫秒，但用Tair加阿里云操作系统后，卡顿基本上在1毫秒内。另外假如业务出现异常访问量或者业务上新应用，把Tair拖报之后，可能会导致意外的情况，但是Tair有RBAL的机制，可以将异常的访问API、异常的访问IP这一类定向限制住，对于客户业务来说，先通过限制住异常访问来帮助业务能够恢复到平稳态之后再来调查事故原因。
5.开箱即用-无感弹性
另外一个是客户头痛的点是扩缩容。假如使用开源板扩缩容会比较难做，特别是在一个较大的集群情况下。所以Tair在扩缩容上做了非常多工作，首先把开源版按key去搬迁的机制改成块件搬迁，通过中心化的集群管理机制来统一调度扩缩容的过程。通过改进机制可以让客户在扩容过程中完全无感知。用开源版的时候经常会出现因为有大key或是在扩容过程中有机器的情况下导致整个扩缩容失败，而且很难再回滚。
上述讲的是Tair在性能与稳定性以及扩缩容的一些工作。
三、从缓存走向一个Serverless KV
1.Tair Serverless KV助力在线服务&推理缓存加速
Tair Serverles KV是最新发布的，Tair Serverless KV从技术上可以分为两层，一层是Serverless KV 的基座，他的作用是将CPU 的DRAM包括GPU的HBM、NVM持久内存和SSD，这些介质统一混合管理。
作为混合存储介质KV池并进行统一的适调。所以可以认为他提供了较大的KV值，在各个存储介质之间流动。左右两侧分别代表了两种不同的技术业务场景，左侧是面向互联网KV负载的场景，在互联网里面KV这类使用的很多。基于Tair Serverless KV后，提供了进入Redis的在线KV服务，和前面Tair的区别，第一它是高可靠持久化；第二他是多租户，通过用户态的精细实时间片去调度，可以把时延P99做到10毫秒内。
因为他是大集群，所以把集群里面的所有的资源CPU磁盘带宽等统一规划管理，因此扩缩容速度特别快。第三就他整体处理热点上比之前数据库提升很多，因为之前数据库都是竞争级别的，而它是集群多租户级别，可以充分利用机器上资源。相比开源的Redis，处理热点的能力是五倍以上。第四，面向AI推理，和TensorRT-LLM 基于推理引擎一起制作，相当于帮助TensorRT-LLM做缓存加速，所以和TensorRT-LLM结合推出了 Tair Serverless KV推理缓存加速的服务。整体上通过PD处理的优化机制，包括PD分离的机制、 KV Cache的池化，把AI推理过程中整体成本降低了20%，性能吞吐提升30%。
2.面向在线KV负载的Serverless 演进
将上述内容细化。第一点面向互联网在线KV，与之前的Redis进程级别的核心区别：一是数据的持久化，二是整个扩缩容速度迅速，以及扩得快扩得广，可以从1GB 1QPS扩展到上百TB的，三是因为Tair的整体定位上是面向整体在线KV的，所以在稳定低延时上花了特别大的功夫。
3.用户态精细调度
在有慢查询的情况下，往往会把用户普通查询拖慢。这种情况下用快慢分离的处理，慢线程处理CPU使用率特别高，但是快处理使用率并不一定高，所以整体使用率不能提的特别高。另外可以增加更多的线程数去处理的，但是会带来线程间资源相互干扰的情况，所以采用按用户态的时间片切分的方式，可以把慢的查询在处理到一定时间片之后往外调度，将快查询处理，通过这种机制确保用户API SLV，并且确保我们集群的使用率，包括客户的成本足够低。
4.大模型推理遇到的挑战
在AI推理遇到的一些挑战。整体在推理过程中会用到比较多的KV Cache，它与用户输入的长文本相关，如果输入的越长，整个KV Cache占用的会越高，往往在一个推理中KV Cache可能占到了40%、50%显存或者更多。所以怎么优化KV Cache是推理加速很关键的部分。推理过程中为两个阶段，一个是欲填充阶段，一个decoding阶段，这两个阶段对于显存的资源消耗是不一样的，所以期望把这两个阶段拆分开来以便把GPU资源使用好。
5.Tair KVcache缓存加速推理
Tair的整体推出了以KV Cache缓存加速，把用户的Context Cache包括RAG Cache可从重复使用的放到 Tair Serverless KV中，相当于通过更多的存储来节省GPU的计算率，另外把Prefill和Decoding两个阶段拆开可以将GPU的使用力提升更高，拆分开之后，将中间KV Cache通过我们的 Tair Serverless KV池进行共享。这是整个Tair在AI所做的工作。我们也希望Tair在互联网缓存工作以及AI推理时代向前推进。
以上是本次分享的全部内容。
