云端问道21期方案教学-应对高并发，利用云数据库 Tair（兼容 Redis®*）缓存实现极速响应

 

摘要：今天分享的是如何应对高并发利用云数据库 Tair 缓存实现极速响应的 Case。首先是云数据 Tair 的概览及特性；然后介绍 Tair 在建设稳定低延迟缓存中的关键技术；第三点我们会介绍方案以及产品的选型介绍以及应用场景；第四点我们会介绍一些线上的活动与权益，主要分为以上四个方面来介绍。

1. 云数据库 Tair 概览及特性

2. 建设稳定低延迟缓存的关键技术

3. 方案及产品选型介绍、应用场景

4. 线上活动与权益

01. 云数据库 Tair 概览及特性

首先我们讲一下云数据库 Tair 的概览及特性，高性能的云数据库 Tair 兼容 Redis 包含 Redis 开源版和 Tair 企业版，提供亚毫秒级的稳定实验与数据。

1.1 云数据库 Tair 概览

云数据库 Tair 旨在为用户提供稳定低延迟的缓存和 KV服务。在命令的兼容性上来说，首先针对非集群版的 Redis ，我们从 Redis 5.0到 Redis 7.0，甚至是未来的7.2，7.4，8.0都可以做到100%的兼容。假设 Redis 的非集群版本的命令基准兼容性基准是百分百，那 Redis 自身在集群模式下，只能兼容到非集群模式下命令的70%~78。而在集群模式下，依然可以做到80%~90多的命令兼容性的支持。所以使用 Tair 就可以实现 Redis 的零接入成本，甚至在集群的命令兼容性上表现还会更好。同时 Tair 支持四种架构不停机转换，用户的业务也无需修改代码。我们支持主备结构单副本，智能读写，分离以及集群四种架构。其中集群包括代理模式访问以及直联模式访问，同256 MB到数10 TB，从数万 QPS 到千万 QPS ，我们都支持灵活扩展和动态调整在产品的选型方面，我们提供超强性能的 Tair 内存型，也提供成本更低性能稍有逊色的持久内存型。同时，针对成本敏感型的客户，我们也提供了低成本的容量存储型供客户进行选择。针对不同的性能数据量和成本的需求，我们可以做到全场景的覆盖。

1.2 云数据库 Tair 的功能特性

Tair 的功能特性包括高性能，持久化，低成本。丰富的数据模型以及企业级能力在高性能方面，我们针对大业务流量，大连接处时依然可以淡然处之。相比开源 Redis 我们拥有两倍以上的性能。在持久化方面，我们可以做到数据可靠，大部分场景下无数据丢失。在成本方面，我们的用户可以按需选择多种存储介质，性价比要高于用户在 ECS 上自建的成本。在数据模型方面，我们提供了丰富的企业版自研的数据模型，包括 Tair Hash， Tair String、Tair Zest等更多的面向了应用场景进行了数据结构的开发，让用户可有更丰富的选择。在企业能力方面，我们提供了全球多活动能力以及数据按时间点上回的能力也提供了混合多元的部署。

02. 建设稳定低延迟缓存的关键技术

接下来讲一下 Tair 在建设稳定低延迟缓存中所使用到的关键技术。

2.1 缓存的挑战—稳定承载流量变化

Redis 开源版等解决方案。长期存在的问题如下

(1) 性能：性能容易被打爆单线程的性能不够，而且最大连接处往往会受到限制。

(2) 稳定性：抖动超时难以排查，因为社区版 Redis 的可观测性相对来说还不够完善，快照 Fork可能导致抖动环境的波动也可能导致抖动，HA切换，也可能因为超时导致误判，探活也不够精准。

(3) 可运维性：传统的 Redis 可以说有运维难，观测难和诊断难几大难题。集群的扩缩容通常需要等待非常久的时间。高可用的建设也缺乏非常有效的工具，可观测和诊断的工具都非常的缺乏。

(4) 成本上：内存成本太高，无法存储大量的数据也无法满足业务性能和数据容量的需求。

2.2 超越 Redis 的性能—轻松应对爆发请求

针对这些痛点， Tair 都一一提供了相应的解决方案。首先是性能在左边的途中可以看到 Redis 5.x版本及以下的线程模型，基本就是单 IO 、单 Work 的线程模型。无法支撑请求爆发的场景。如果有大量的请求过来，中间但凡掺杂着一条慢命令，后面的命令就会被强制要求等待， Redis 6.x和7.x版本之后的线程模型使用了多 IO 的模型，可以看到在读和写的时候都通过多 IO 来增大了负载。但是中间核心的 Process 还是单线程进行的，所以可以理解为是 多IO 的模型大量，连接依然会带来血崩。而 Tair 通过完全自研的代码，真正地实现了多线程的模型吞吐，提升到了原来的200%+，延时降低到50%。对比测试的话，可以看右侧 QPS 对比相比 Redis 6.0， Tair 的读写都接近有两倍的提升。同时，时延也有很显著的降低。

2.3 缓存服务的稳定低延时技术挑战

接下来讲一下，在稳定性建设过程中，可能遇到的问题。在整套缓存服务的链路中，不仅仅是缓存系统本身的问题，有可能是用户的业务系统产生的问题。

(1) 业务系统侧：比如业务侧的虚拟机，自身的服务器状态，CPU 内存等竞争、 PPS 限制等。应用 Service 的问题，包括自身运行和资源占用情况，GC 情况慢查询等以及 SDK 的问题，包括连接尺码， SDK bug等。

(2) 网络侧：同时中间的网络侧也有可能出现问题，包括丢包、重传、物理网络设备故障等。

(3) 数据库测：数据库测的问题包括 Proxy DB 节点的服务过载，慢查询，数据访问不均资源层面过在瓶颈以及 Proxy DB 的网络抖动等。

所以针对业务来说，如何减少抖动变为如何实现快速诊断和恢复是非常重要的。

2.4 避免抖动/超时

Tair 从自身的代码，内核以及操作系统方面，针对这些场景做出了优化和改进。首先是自身数据库内核的优化，我们在代码层面做了机制的优化，包括 RCU， Lock Free 的数据结构，Cache 预取等。同时做了异步化，包括任务，投递和回调 Scan TTL 的针对网络和文件 IO 的调用也做了优化。对于缓存系统中最让人头痛的慢查询问题，我们利用 Tair 本身的多线程特性，实现了慢查询的隔离。我们能够对慢查询首先进行实施的判断，然后将漫长命令投递到独立线程进行处理，不影响其他的短请求和快速的请求。可以看到在单一get压测的场景， Tair  QPS 为 Redis 的两倍，在 Get 与 Keys 混合压测的场景， Keys 可以理解为一条漫长命令，在传统的单线程模型中，keys会对实例造成阻塞。因此 Redis Get QPS 大幅下降只有300多，而具备漫查隔离的 Tair 受到的影响明显更小达到了35万左右每秒。在操作系统层面，我们也深度联动，优化缓解了 Fork 的阻塞问题。 Tair 和操作系统团队合作添加了特定的 Feature 优化，我们将列表的拷贝方式从前台拷贝挪到了后台，这样的 Feature 使得我们的 Fork 机制在对实例阻塞的影响基本没有，实例阻塞时长可以降到1毫秒以内。

下面介绍一下 Tair 是如何使用规则来限制用户的不合理请求的，也就是 Tair RBAl（Rule Based Access Limit）可以通过 Accel 的命令，可以基于特定的命令 IP 甚至 Key 来组合成规则设置其允许的最大 QPS 和流量。适用于特定情况下，用户对指定请求进行限制，以保证高优请求的执行。在右侧的表格中，我们可以看到比如说限制一个 QPS 为10000，限制lrange这条命令的 QPS 为100，设置特定 Key 的访问的 Get QPS ，以及针对客户端的 IP 和用户的 ID 来进行限制。下面是限流的效果。测试我们把 Set 和 Lrange 混合场景进行测试，限制了 Lrange 的 QPS 。

2.5 开箱即用无感弹性

接下来介绍一下 Tair 是如何实现开箱即用无感弹性的，相比于社区版的 Redis 集群， Tair 最大的区别就是通过自研的管控组件来实现中心化的集群。社区版的 Redis 集群是去中心化的，使用了 Redis 的 Slot 协议来达到集群变配的路由表的最终一致性。 Tair通过自研的中心化集群组件以及集群数据迁移的机制来实现独立 Slot 力度的数据迁移。在迁移过程中，能够确保用户的多 Key 访问依然保持正常。同时能够屏蔽大 Key 的影响，保证稳定性和性能。如果在迁移的过程中出现异常，也可以快速稳定的回滚。相比于 Redis 开源版，中心化集群的优势包括在可靠性上 Tair 的数据更加可靠。中心化控制迅速准确。在集群变配的状态，收敛时间可以从30多秒降到500毫秒以内。在管控层面，我们可以实现全自动，无需人工干预。对于用户的 Redis 运维来说，不再需要起夜。迁移的平滑性上，即使存在大 Key 的情况下，我们也可以做到无感迁移在变配过程中没有明显的 RT 上涨，也不会有新增的命令错误迁移的速度。相比社区按 Key 迁移的方案，我们按 Solt 的迁移整个速度实现大幅的提升。在运维的复杂度上，相比社区的去中心化集群，我们突破了64的数目限制，支持超大分片的模式。同时，用户也可选择 Proxy 模式和直联模式，主从与集群可以实现透明的转换。

 

03. 方案及产品选型介绍、应用场景

介绍完 Tair 的关键性技术之后，下面开始进入方案以及产品选型介绍以及应用场景的说明。我们今天分享的就是这个方案。

3.1 方案介绍

首先是方案介绍，我们提供了一个实践来帮助大家一键部署包括云数据 Tair 云数据库 RDS以及云数据库 ECS 的一整套的系统。这个方案是介绍如何运用云数据库来构建缓存为应用提速的缓存是一种数据存储机制，通过在高速存储介质中暂存频繁请求的数据来减少对主存储或数据库的直接访问。在这个方案中， Tair 提供了高性能键值存储服务，可以满足各种业务场景的需求。同时基于双机热备架构及集群架构，Tair 可以支持自动扩容，提供多种高可用的方案。可以根据业务需求动态调整实例规格和容量。同时 Tair 拥有丰富的数据类型支持，提供丰富的自研增强型数据结构，包括 EX String 、EX Hash、EX Zset、GIS、Bloom、Doc、Ts等，帮助用户精简代码，并提高业务的整体性能。

3.2 方案架构

下面介绍一下方案架构方案实例，模拟了员工与部门关联的场景，通过 HTTP API 以部门ID为参数获取部门下的员工ID及其姓名。数据优先从数据库中查询，选择使用 Redis 作为缓存后，首次加载仍然通过数据库查询，之后的查询将会优先从 Redis 中取出结果。在清理掉数据库数据之后，由于缓存存在有效期，仍然可以查询到结果。架构图大致如图所示，从用户到云数据库的 ECS 云数据库 Redis 以及云数据库 RDS。

3.3 方案涉及的产品选型

Redis 实例规格为按量付费，云原生盘 RDS MySQL 的规格为按量付费。 MySQL 8.0基础系列， MySQL.N1e.Medium.1的规格。 ECS 的规格为按量付费，计算型 C6，ECS.C6.Large。

3.4 Tair 应用场景：在线电商

下面介绍一下 Tair 一些典型的应用场景。首先就是在线电商，Tair 作为从淘宝双11中孵化出来的超强缓存系统，在线电商是 Tair 的主要业务应用场景之一，可以看下面的图中像从登录系统，用户系统，商品目录，购物车个性化推荐等都可以看到 Tair 的使用痕迹。针对追求极高稳定以及多地域分布的用户来说， Tair 都可以提供优质的服务。在在线电商这个场景下，我们可以实现低延迟压毫秒级别的缓存服务。高吞吐每秒亿级别的访问，并且支持弹性伸缩，应对流量高峰以及极致的高可用性能。

3.5 Tair 应用场景：游戏娱乐

第二个典型的应用场景就是游戏娱乐。在游戏行业 Tair 也有非常多的最佳实践，包括排行榜，用户登录，聊天室，消息，购物，商城以及装备列表等。 Tair 的性能增强型提供了两倍于社区版 Redis 的性能，很好的增强了洪峰承接和热点承接的能力。同时， Tair Doc/Tair Bloom filter 也在很多游戏场景中得到了应用。同时针对游戏客户的一个重点需求数据归档，比如误操作删除数据需要恢复，版本发布异常回滚。我们提供了数据归档的功能，可以让恢复时间从数小时降低到分钟级别。在游戏场景下， Tair 提供了低延迟压毫秒级别的响应。分区分服可以使用主动版，全区全服可以使用集成版，无感扩容可以实现过程中用户不掉线，极致的高考用服务保障了稳定性。备份归档，实现了数据备份和回档的需求。

3.6 Tair 应用场景：生活服务

第三个典型的场景就是生活服务，Tair 及时的设计结构，提供了电子围栏的解决方案，通过判断点和面的关系，比如儿童安全可以判断孩子是否在区域内，判断共享单车是否在禁停区内等。应用的场景适合更新频率快查询量大的场景，比如儿童每次的位置都是变化的，不容易以 Catch等。频繁的去更新写度压力大，使用 Tair GIS 可以替代 PostGIS + Cache 的场景，实现多倍的性能提升。同时还提供了轨迹漫游的功能，通过判断线和面的关系。比如疫情期间判断是否经过或路过疫情区域。

04. 线上活动与权益

最后介绍一下 Tair 的线上优惠与权益，数据库上云首选 Redis 开源版低至399元每年： Tair 企业版首购一年六折。

我的分享到此结束，谢谢大家。