Tair 在雪球和作业帮的使用剖析 | 学习笔记

开发者学堂课程【阿里云原生内存数据库 Tair 课程：Tair 在雪球和作业帮的使用剖析】学习笔记，与课程紧密联系，让用户快速学习知识。

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

Tair 在雪球和作业帮的使用剖析

内容介绍

一、Tair 在典型金融行业的应用

二、Tair 持久内存型产品概况

三、Tair 持久内存类型VS开源Redis

四、雪球客户案例

五、FAQ

六、Tair 在作业帮的实践

一、Tair 在典型金融行业的应用

首先介绍 Tair 三种形态对比，如果以 Redis 社区版的性能为1.0基准，则可以分为三个不同的版本：Tair 性能增强型、Tair 持久内存型及Tair 容量存储型，若用户对性能方面有很高的要求，可以选择Tair 性能增强型，整体的性能是 Redis 社区版本的两到三倍，整体的价格是 Redis 社区版本的两倍。若 Redis 性能有瓶颈，且在同样的规格下，想要更高的性能，则可以选择增强型，此类型在极限抗压以及高热点承受力方面要比标准的 Redis 社区版本好很多。除此之外，还包含了许多 Redis 社区版本没有的常用数据结构，适合应用迭代，比如 Tair Hathaway 。若选择 Tair 性能增强型版本，则用户就可以得到一款天猫、淘宝、高德、优酷同款的高性能的内存数据库，在双十一时可达到15亿次请求每秒。对于高版本的企业形态与功能，例如任意时间点恢复、全球分布式及热点散列，这些性能是 Redis 社区版本没有的。

接下来介绍 Tair 持久内存型，此版本主要看重高性价比，对标社区版本时可以提高0.9倍的性能，但是价格却只有百分之七十，基本上完美兼容 Redis 5.0，对版本的兼容力是很好的。之所以名为持久内存型，是因为采用一些 Intel 做腾持久内存，包括内部做了许多优化，命令级持久化，故 RTO=0，与此同时，没有 aofrewrite 运动，无周期性抖动。

Tair 容量存储型可以简记为对标 Pika 等开源存储型 Redis 产品，但不是本次课的内容重点，本次课主要讲解 Tair 容量内存，帮助用户可以在性能与价格之间达到一个很好的平衡。

二、Tair 持久内存型产品概况

Tair 持久内存是全球首家的公共云持久内存数据库，若使用开源自建的 Redis ，则会遇到三个问题，其中之一为内存的容量限制，若想要扩容则会比较麻烦，并且受物理硬件的限制，其次内存本身是比较昂贵的，此时使用一个 Redis 会比马斯卡好很多，还有 Cache 的双层系统。简单来讲，像 Mysql 、Redis 这种形态，若使用为持久内存，在特定情况下是可以舍弃此 DB 的。

接下来介绍 Redis Tair on PMEM 的特性，此为 Tair 独家的 PMEM 持久化引擎，若使用 Tair on PMEM ，则可以得到一个云原生的数据管理，不再需要担心扩容、运维、监控、报警等问题，底层的硬件使用的为神龙裸金属服务器，包括阿里云的Linux 定制优化，整体性能在之前已经提到过，接近百分之九十的一个性能，但却可以让成本降低很多，可能基本上是70%的开源版本的成本，除此之外也是占用高规格。可以看到整个 Tair 持久内存适用于用户在温数据、温热数据，包括部分热数据这种情况下都是可以使用 Tair 持久内存的，只要用户不是对性能的要求非常极致的这种场景下，是可以平替 Redis 的数字版本是十分方便的，而且价格也是十分合适的。

在传统组织架构下，如果用户需要使用 Tair 作为缓存，则需要一个 DB 来进行一个持久的存储，长期则使用 circle，标准的也有集群加 Redis 集群，再加一个传统的DB。若使用 Tair 持久内存场景，可以直接使用一个 Tair 持久内存来实现缓存加持的内存，实现架构的一个简化和升级，也让综合成本有所下降。

三、Tair 持久内存类型VS开源 Redis

那再来看看 Tair 持久内存类型与开源社区相比，整体的产品对比与功能，对于基本内容，官网有十分详细的内容对比，先介绍一下性能的延迟，基本上是90%的版本性能，延迟p95也是要优于内存的，而且服务更加平滑。开源版本因为 fork 问题线上抖动，则容易出现一些抖动以及诸多不可预期的延迟。成本最低可以达到内存的50%，而且无需像自建一样需要预留一些内存，用户可以随开随用，用多少就花多少钱。那如果使用开源 Redis，自建肯定是需要预留内存的，内存不够的时候则需要进行扩容。对于容量目前也是要优于开源 Redis，在持久化方面的话，RPO 是等于0的，不会丢失数据。可靠性也是要开源 Redis 要高的。关于企业能力方面，原生版的 Redis 是没有企业机功能的，开源版本的 Redis 是完全兼容 Redis 本身社区版本的，同时包含一些企业级别的能力，例如数据闪回、全球多活，还有各种增强数据结构。对此 Tair 性能增强版本，在未来的话，Tair 持久内存型也会支持刚才提到数据闪回、全球多活。

四、雪球客户案例

以雪球为例，雪球是一个拥有超过4300万用户的在线财富管理平台。对于股票、基金等，投资者在雪球都会进行一个广泛的交流，并且完成一个交易。雪球的整个的内容主要是数据，还有交易体覆盖A股，港股，美股。包括公墓基金、私募基金为主要市场。每日在雪球是有数百万用户在社区进行交流互动，并进行一个跨市场、跨品类的行情数据查询、内容订阅，还有创作及线下下单交易。从目前雪球的行情看来，其中的海量股票数据在实时处理展示，例如软件中看到的实时k线、实时成交明细数据，均是使用阿里云的内存数据 Tair 进行存储，并实时呈现反馈给雪球用户。客户的痛点是成本比较高，例如客户大规模自建 Redis，整体的内存利用率是非常低的，没法做到按需开通，需要留有余量。并且对于 Redis 开源版本，自由的hope 机制是需要预留内存的，而且导致客户自建 Redis 成本居高不下。其次就是数据库的数据系统化能体验，比如股票信息在k线成交明细这种场景，它不仅有性能要求，也有持久化的要求。但若用户开启 Redis 开源版本以后，会存在性能下降及 rt 抖动的问题，肯定会对客户的体验带来不利的影响。但是若不开则可能会丢失数据，故处于一个比较左右为难情况。第三个痛点为运维方面，若用户使用传统的开源版本的专辑策划，维护难度是比较大的，尤其是随着业务量持续增长的情况下，原生 Redis 的扩容、故障处理、以及问题排查，这些工作都会对研发团队带来比较大的挑战。有时客户也会经常熬夜扩容，有时候还会出现一些各种意想不到问题，对业务本身是不利的，而且也会消耗大量的精力。若使用云上的 Redis 平替自建的Redis，首先可以做到百分之百兼容，尤其性能强，其次，若用户对成本有考量，就完全可以使用 Tair on PMEM ，雪球就是使用 Tair on PMEM ，而整体的价格仅仅是社区版的百分之七十。而且吞吐访问延迟是较相当的，若数据有持久化需求，可以使 Tair on PMEM 可以将数据实时的持久化，而且断电时也是不丢失的。那再加上 Tair 产品的开箱、开箱即用以及透明弹性、伸缩等能力，可以解决客户的重要数据存储的忧虑，并且可以将客户从运费压力中解放。阿里云云原生 Tair 为雪球提供了开箱即用的高性价比的持久化存储，同时大大简化了客户的维护成本以及运维的复杂度，为客户的业务支撑带来了一个质的提升。主要就是实现了降本，但是不降性能。或者说基本不降性能，课后其实是无需再对运维做内存预留。再加上Tair on PMEM 成本设计版本的70%，因此综合成本为 Redis 社区版本会更低，而且 Tair 的 PMEM 吞吐能够达到一个社区版本的90%以上，并且p95延迟更低。可以满足客户的降本不降性能的苛刻的要求。数据持久化也解决了很多的业务难题，例如 Tair on PMEM 能够将数据实时持久化，并且真正做到了断电数据不丢失，此能力不再限于常见的缓存持久化，而是一个可靠的高性能持久化数据库，让客户能够放心的去存储重要的数据。整个运维的负担也会降低非常多，因为 Tair 可以很轻松的实现业务的变化，可以大幅度的降低运维的压力。例如弹性伸缩可以将复杂的扩容从数小时进行简化到点击几下鼠标就可以实现。而且支持非常丰富且多维度的审计、监控还有可以分析能力，肯定可以帮助客户快速定位问题，并且及时解决。更多的把精力投入到业务当中去，而不是一维层面。  客户对整个过程表示支持且十分认可的，包括希望做到简化架构来降低维护成本。在 Tair on PMEM 以及 Tair 型增强数据库，整体的数据库架构得到优化，通过 Tair on PMEM 策划的能力消除了缓存、搭配磁盘存储一致性的问题，扩容也会变得十分简单，也不再需要预留很多内存。通过一键扩容能够比较轻松的应对容量负增情况，而且客户的工程师也就不用再熬夜进行数据的迁移，此为客户比较满意的几个方面。客户使用的是Tair  PMEM 持久化内存 、Tair 性能增强以及 Mysql  ，客户目前包括 Tair 性能增强版本都是有用到的，目前客户在行情业务中是没有用到社区版本的 Redis。对于 Tair 的使用场景以及能力，雪球客户这边主要是在k线、主笔交易两个核心上进行使用，对性能要求是很高的。在性能要求很高的场景，则使用性能增强，主要是用于k线。在此类场景，Tair 性能的优势会很明显。其次就是持久化内存使用在性能要求不那么高的地方，主要负责降本，降本对雪球其他客户有很大的吸引力的。除了Tair 本身之外，也有其他的 Tair strength 可以承担一定的交接角色。对于阿里云Redis 与 Tair 目前需要与客户保持紧密的合作与联系，对于之前遇到的一些问题，都可以迅速进行解决。目前客户反馈没有新的问题和疑问，用的整体还是挺顺畅的。可以看到整个从港股，美股，a股走到 receive server，再经过 Kafica 和replicator 然后汇聚到 Redis、 Mysql 、ES 方面。整体的业务价值就是实现降本增效，为雪球提供一个高效的缓存以及高性价比的存储能力。大大简化了客户维护的成本和复杂度，性能方面也是非常接近开源数据版本，并且达到降本存储及置换能力。

五、FAQ

最后介绍一些常见的 FAQ ，在这里总结了客户在上云过程中最常见的四个问题。首先就是性能方面，企业版本、Redis 开源版本及持久化内存之间的性能实际上在 ppt的前几页已经做过介绍，同时官网会有详细的资料。大家可以简记为性能增强有接近300%的性能基准，对比一个开源Redis。则持久化内存是90%的开源 Redis 性能，是无限于接近的。整体的特性可以在官网的产品简介、云数据库初始与选型、Redis企业版本与社区版本特性对比中进行查阅。查阅过程中肯定是需要用到一些工具的，基本上会使用两种工具，一个是 Redis Tair。还有一个是推荐的 DTS，是阿里云资源的一个数据库同步工具，它可以支持包括 MYSQL mango、Oracle各种异构和同构都可以支持数据。在整个雪球上升过程中，也是使用的Redis DTS，DTS本身是一个全量加增量同步的工具，可以帮助业务在上云过程中保持平滑的上云。只有在最后割接的时候才会需要断开业务，同时断开一个链接。整个DTS 在上云过程中，全量同步的时候是支持限速的。通过限速功能，在全量过程中，对云库压力有一定的影响。可以通过限速能力来避免对云库造成一个较大的影响，同时可以根据每秒查询云库的速率、每秒全量迁移的行数等进行全量速率的调整。

第三点再介绍一下客户端，目前推荐用户使用 Jedis 客户端来访问云数据库的，而不建议使用 Lettuce ，尤其是在使用期间，它整个性能方面还有故障恢复的时间方面是远远不及 Jedis 。研发时也曾多次跟 Lettuce 作者进行沟通，作者开始是认可Lettuce 的问题，但是目前还是处于不断优化代码层面。所以说一般不建议用户使用 Lettuce 的原因，同时官网也有详细介绍不建议使用 Lettuce 的原因、整个客户端的改造方面及代码层面都会有详细的介绍。

最后介绍切换。若使用 Tair 性能增强型、持久内存型及容量存储型，此三种类型可以进行平滑切换，但目前暂时还不支持直接进行切换，正在加紧进行开发，但是可以通过前面第2点提到 DTS 同步工具来实现以后再进行切换。以上就是今天的分享，感谢各位的聆听。

六、Tair 在作业帮的实践

1、公司介绍

作业帮成立于2015年，一直致力于使用科技手段助力教育普惠，用人工智能、大数据等前沿技术为学生提供更高效的学习解决方案。今日的分享内容主要包括以下几个部分，第一部分简单介绍作业帮的一些业务特点，主要是介绍和技术相关的一些特点。第二部分会介绍作业帮之前使用的 Redis 架构，以及在使用此架构时遇到的一些问题。第三部分是对 Tair 的优势做一些介绍，说明作业帮选择和阿里云合作、选择 Tair 方案的原因。第四部分主要介绍当前作业帮的 Tair 集群架构，最后介绍作业帮的 Tair 方案，在现有方案的基础上正在进一步做的事情。

2、业务特点

第一个就是稳定性，作业帮的一些流量型的服务用户，日活量大概是在数千万的一个级别，任何一个达到此用户量的产品，对稳定性一定都有极高的一个要求。此外还有一些履约型的服务，又是一个非常强的履约时效性的要求，一旦在固定的时间点无法完成履约，则后续很难补救，同时会很大程度上影响履约的质量，对稳定性、履约服务也有很高的要求。基于对稳定性的高要求，作业帮选择通过多云的方式解决。也就是第2点需要介绍的，提升服务的整体稳定性，作业帮已经基本完成了多元建设，实现了所有的核心服务的多云。多云指在多个云情况下都能进行完整的部署，另一方面日常的流量通过一定的策略，动态的在多个云之间进行调度和分配。第三个特点就是自主可控，因为作业帮要基于多云的架构，去建设公司整体的一个技术架构。所以当时在数据存储服务上，基本就需要选择一个自建 pass 服务的道路，因为开始做多云建设的时候，其实各家云厂商都有一个私有化部署方案，现在其实各家云厂商都会提出私有化部署的方案，当时还没有那么成熟，如果现在公司做多点的话，可能会有更多的选择。但是从作业帮当时开始做多云建设的那个时间节点，在 pass 服务这一层，自建是当时一个比较好的选择。最后一个特点想重点强调的一个就是成本，作业帮从成立以来，其实在成本上一直都是有比较高的要求的，这一点与作业帮合作的阿里云的老师们应该都有体会。随着这些年的互联网红利的一个消费期的到来，很多公司就会越来越多的把目光放在降本增效的事情上，很多技术方案的升级很多的时候都是从成本的角度去考虑去做这个升级的，以及从成本的角度去推动方案的落地。例如本次要分享的 Tair，从一开始决定要使用以及最终上线之后达到的效果来看，成本在其中都是扮演了一个非常关键的角色。

3、Redis Cluster 集群架构图-双云部署

接下来介绍作业帮原来使用 Tair 集群之前，使用的是 Redis Cluster 集群的多元部署的架构，在此次做了一些简化，只是画出了两个云，然后每个 cluster 里只画出了一个分片。此为示意图，用户流量从入口就开始按比例的分配到这两个云。此两个云的应用层又通过各个云的 lb 服务，然后连接到作业帮自研的 Redis 上，Redis Cluster 的一个关键用途就是包括流量路由、屏蔽 Redis Cluster 对客户端的一些差异、屏蔽底层节点的一些故障切换以及主动切换等操作。然后底层使用的就是社区版的 Redis cluster，然后做了跨云的部署，也就是一个 Redis Cluster 的节点分布在多个云上面。其中主节点会将它都放在一个云上，不管 Cluster 有多少个分片，所有它的主节点都会放在一个云上。从节点会按照业务的流量在各个云按比例去分配，而主从之间就使用 Redis 原声复制。简单的介绍一下具体的路由策略就是无请求，则优先路由到本人的存户，然后避免去跨云堵，但是斜请求因为只有一个原请求，所以确实在架构下会存在一定比例的跨原写。Redis Cluster 不承担独流量的，就是说如果业务对 Redis 有持久化需求，选择是为了避免持久化导致的性能抖动，则会增加一个独立的、不承担无流量的从节点来完成持久化的工作，此架构在整体上看，是可以满足多云架构的需求的，稳定性也比较令人满意，但是也有一些希望能够优化的地方。

4、Redis 双云架构存在的问题

问题主要分为两类，一类为社区版的 Redis 本身相关的一些问题，另一类是和与多云架构直接相关的一些问题。Redis 本身的不足又分为几类，简单介绍一下，第一个为Redis本身是一个纯内存的存储，随着业务的不断发展，现在 Redis 的使用量已经增长到了数万核级别。如果能够降低成本，则会有很大的一个收益，第二是通过一组多重的方案，虽然避免了一些数据丢失的风险，比如说节点挂了，自然有空间顶上来，但是有些集群或者分片的故障，集群级别的，或者分辨级别的故障，仍然还是有导致数据丢失的可能，做过 Redis 运维的同学可能对这些场景有一定的了解，然后此外就是原生的复制其实并不能保证在主动切换的时候不丢失数据。第三点为如果业务有持久化的需求，则要么接受因此带来的性能抖动，要么接受增加一个持久化的节点带来的进一步成本的上升。第四点，随着节点数的增加，在实际的使用的时候，发现就是过百了之后，可以看到切换之后，由于 Redis 的高速协议，导致的集群状态的一个收敛的速度会非常的长。第五就是原生 Redis 的迁移，是以k为单位的，有时候就是容量不够的时候需要做一些切换或扩容的时候，信息速度比较慢，带来的集群性能的影响时间越来越不可控，这是原生 Redis 的方案带来的几个问题。

此外，因为作业帮使用的是多云的架构，还存在一些和多元相关的问题。例如刚才提到的有个不可避免的这个写操作跨云的问题，部分对于延迟比较敏感的业务来说，还是会有一定的反馈的。第二就是出现语音级别的故障的时候，主要就是主节点所在的云的故障的时候，由于所有主节点存在云故障，则所有主节点可以认为发生了故障，其实此时 Redis 本身是不会发生切换的，则需要依赖 Redis 多云管控平台去做批量的集群操作才能完成，其实时间是比较久的。例如真的出现一个单云的故障的时候，从出现故障到决策需要做一个云的切换，大概需要十分钟，而 Redis 在平台上做批量的切匀，大量的集群整体做一个切换，再需要十分钟，再加上一些其他操作的时间，其实是很难达成在云级别的故障在15分钟之内恢复的目标。

5、Tair 的优势和上线方案

带着这些问题与阿里云的 pass 团队做了几次深入的交流，对 Tair 的方案做了一些详细的测试，最后决定开始使用 Tair 方案，主要因为看上了以下几个优点。最大的一个优点是成本上 Tair 使用持久化内存作为存储介质，然后持久化内存的成本只是普通内存的60%~70%，而且性能和 Redis 基本一致，在实际测试中 Tair 基本上可以达到 Redis 吞吐量的98%到百分之百，然后延迟上相比 Redis 确实略高一点，但是也完全在业务的接受范围内，因为目前已经完成了阿里云的所有 Redis 的节点替换为 Tair 节点，现在整个对业务来说是完全无感的。第二个就是 Tair 是一个持久化的方案，天生持久化，断电数据不丢失，支持半同步，对于数据的可靠性和一致性来说是非常高的，RPO 是等于0的。然后第三就是持久化也就不再需要做 RDB、AOF等事情，然后写延迟显然是低于 Redis，而且此时持久化因为没有特殊的操作，其实是没有毛刺的。有了二三两列加起来，也就不再需要单独的持久化节点了，可以进一步的降低整个缓存的成本，但是当时真的要使用 Tair 方案的话，当时其实也有两个很大的障碍。第一，刚才说了的，作业帮所有的集群都是基于裸金属服务器，然后自建的一个集群，Tair 作为一个产品，如何能够使用在自建自建当中。然后第二个就是作业帮所有的集群都是多云部署。Tair 作为阿里云的产品，如何能够部署在一个多云的集训当中。所以一开始其实对 Tair 上线也是有一点悲观的，但是阿里云的团队非常给力，其实是在短时间内就解决了这两个问题。首先阿里云提供了 Tair 的专属集群方案，就是提供一个云资源独享主题管理，这种方式可以直接将 Tair 服务器的操作系统暴露给作业帮，对于整个缓存的一个管控平台来说，抹平了 Tair 和裸金属在使用上的差异，可以方便的将 Tair 纳入对方自己作业帮的一个缓存的管理和管控平台。第二，针对作业帮多云的架构的特点，Tair 利用专属集群完全兼容协议的这种方式，在 Redis Cluster 可以平滑的替换 Redis Server，也就是说，在一个 Redis Cluster 集群内可以任意将一个节点替换为 Tair 节点，对上层用户来说是完全没有感知的，这一点轻松解决了这两个问题，则顺利的上线了 Tair 的集群方案。

6、加入 Tair 节点后集群架构图-双云部署

下图是简化的一个集群架构，在这个方案里，在阿里云上用Tair节点就是无感的替换了所有的 Redis节点。在其他云上，在同一个集群内就是仍然使用普通的节点，然后同组成一个跨越的集群，因为有了Tair节点，也就不需要单独的持久化节点，之前可以看到独立的一个持久化节点，现在就不需要了。在这种模式下Tair在协议上、管理命令上都做到了完全兼容，并且整个替换过程对上层业务做到了完全无感。没有业务改造本，这一点也是Tair能够快速上线的一个非常重要的一点，就是业务层是完全不需要做任何的改造，在这种方式下快速完成了Tair 的上线，大大降低了缓存成本，同时也解决了持久化的问题。

7、Tair 其他优势

这种架构，说实话，也是一种折中和妥协的方式，为了做到和 Redis 的完全兼容，也就没有办法无法利用 Tair 很多其他的优秀特性。主要就是刚才其实有些已经提到了，第一个就是知识多活，然后最多支持三个集群之间的双向数据同步。多活方案其实是多云架构下一个比较理想的方案，可以避免跨原写以及语音级别故障的时需要人为介入切换这种问题。还有，例如 Tair 支持半同步，可以降低数据丢失的风险，但是为了与 Redis 的复制兼容，其实也就放弃了，还有就是像slot级的数据迁移、合资兼容协议等比较好的特性，其实在现有的这种集群架构下是没有办法支持的。所以其实也很想用上比较理想的方案，所以目前正在和阿里云做进一步的合作，对现在的缓存方案去做进一步的优化。目前的进展包括 Tair 已经完成在所有作业帮合作的几家云厂商的一个持久化内存机型上的一个兼容性测试，也就是说，Tair 可以实现就是在所有作业帮使用的这种云厂商的服务器上的部署，目前没有技术上的障碍。另外 Tair 在其他的云上面去做部署，毕竟还要解决一些商务合作上的问题，这部分也和阿里云的团队一直保持合作，目前已经在合作方案上达成一致，近期也在进一步的优化Tair 集群的架构。正在做的架构方案也简单的介绍一下。

8、正在做的架构-Tair 多云多活

在新的架构里，每一个语音上都会部署一个完整的一个Tair 集群。此 Tair 集群是一个真正的 Tair 的完全体，具备所有的优秀的特性。读写操作都可以实现单元闭环，同时还可以利用 Tair 原生多活能力对多云之间的Tair 集群做一个双向的复制。对于发生故障的时候，就不再需要做底层的主动切换操作，只需要在业务的上层去做切流就可以了。

在 proxy 这层，其实之前一直使用的是自研的 Tair  proxy。 Tair 其实也有自己原生的 Tair proxy，对于没有自研 Redis proxy 的公司来说，在使用上也会十分方便。此外，原来其实也在做多活的类似的架构，其实还要做 Redis 的改造、字眼、以及Redis proxy，有了 Tair 本身的这些能力之后，整个团队的研发成本会降低不少。希望新的架构可以尽快上线，等上线了之后，希望有机会再给大家做一次分享，再做一下详细的介绍。