一、前言

在使用阿里云数据库RDS(Relational Database Service)(简称RDS)前,请先评估RDS实例所需要配置的规格,评估参考标准有:CPU、内存、连接数、IOPS、存储空间等资源指标。本文根据实际测试结果和结合用户场景模拟,提供了相对通用的评估方法,您可以参考本文的内容,对RDS实例规格的选择进行相对准确的规划评估,并以此为依据来组建您的业务系统。

二、注意事项

  • 由于不同用户在数据结构、查询复杂度、数据量大小、性能以及数据变化等方面的需求是不同的,所以本文的评估不一定适用于所有的用户,建议您在条件允许的情况下,通过实际的数据和使用场景按照测试出适合自己的RDS实例规格容量规划。
  • Redis 可能因为存在大key 进而影响实例流量、QPS等性能指标,因此Redis 大key
    场景不在本文讨论范围内,同时建议业务上尽量避免存在大key。
  • Redis 不同产品实例类型单节点目前的理论压测QPS上限存在一定差异,因此在做Redis
    应用水位容量需要考虑到所选用的Redis产品实例类型。
  • 云Redis集群版会存在部分命令受限的情况,因此在使用云Redis集群版前,请确认业务中是否有使用集群受限命令,具体请参考《集群实例的命令限制》

三、Redis 产品系列类型选择

redis 容灾方案 redis容量估算_redis


redis 容灾方案 redis容量估算_redis 容灾方案_02

  • 目前云数据库Redis版单副本实例已下线,单副本实例在HA场景下会丢失数据,不承诺数据可靠性保障,因此建议生产业务环境使用双副本实例类型,在性能指标上单副本与双副本并无差异,因此本文主要以Redis双副本实例为例,如您明确了解单副本实例特性,需要在不要求数据持久化的场景中使用,可以提交工单开通。
  • 区分使用Redis标准版、Redis集群版、Redis 读写分离版本很重要两个参考指标为Key 数量 以及读写QPS量,当Key数量过多,主从版实例已无法满足存储需要key需要,建议使用Redis集群版,当读QPS请求压力比较大时,建议选择Redis读写分离版本,当读QPS压力的只读节点不够满足于现有业务压力或业务权重占比以写为主时,建议使用Redis集群版。
  • 在读QPS请求压力较大场景,虽然使用Redis集群版一样可以通过扩展节点提升读QPS能力,当时由于集群版Redis会在部分命令受限的情况,可能会导致业务存在一定不兼容的情况,建议您结合实际业务请求进行综合分析,判断需要使用Redis实例产品系列类型。

四、Redis 实例规格选择

redis 容灾方案 redis容量估算_云计算_03

  • 企业版Redis实例由于采用了多线程模型,性能约为同规格社区版实例的3倍,在高QPS场景下,性价比优于社区版实例。
  • 混合存储实例采用内存加磁盘的存储模式,能够在业务高峰期后对冷热数据进行弹性分离,既保障了热数据的内存访问速度,又提供了远超社区Redis的存储容量,实现了性能与成本的平衡。
  • 在存在多个热点Key的场景下,如果最大节点的读写分离版本依然无法满足读QPS要求,可以考虑使用Redis集群版甚至Redis读写分离集群版本并通过对热点key进行命名调整,将热点key分布在不同分片上以达到分散热点key访问进而提高整个读QPS请求处理能力。

五、Redis 产品规格容量评估

在使用阿里云Redis产品前,建议提前进行Redis规格选择与容量规划,通常需要考虑的维度有QPS、带宽、内存、连接数等,低于实际需求的Redis规格可能会出现请求RT波动导致业务请求超时,高于实际需求的Redis规格会存在资源浪费与成本问题,如何结合业务需求选择评估最合适的实例规格尤为重要,本文根据实际测试结果和用户使用场景模拟,提供了相对通用的评估方法。您可以参考本文中的内容,对Redis的规格容量进行初始规划。Redis容量前期规划主要分为内存容量评估规划、QPS容量评估规划、连接数容量评估规划。

5.1 内存资源容量规划:

由于云Redis对内存、连接数、流量等资源与规格进行强绑定,因此一旦某一类资源例如内存,在用量确认的情况下所需的Redis规格一般也会相应确认下来。

注:Redis不同数据类型在不同数据量情况下可能使用不同的数据结构进行存储,因此准确的评估方式会比较复杂, 本文进行了一定的抽象,假设在key 数不同的情况下,单个key 的平均大小恒定,因此本文会考虑到一定冗余空间, 依据适用于大部分业务场景。

假设:
业务预估每秒处理的读请求峰值为Q
业务预估每秒处理的写请求峰值为W
业务预估总保有key 的数量为N
业务预估key平均大小为X (单位:KB)
业务预估最大并发连接数为Z
业务预估总连接数为Y

预估Redis规格的内存大小(单位GB) = W * N / 0.8 (内存 容量水位,考虑到Rehash、部分大key等场景建议此值为0.8) / 1024 / 1024

• 通过容量公式计算出的内存大小后,请至少选择高于预估内存大小的Redis实例规格,不要选择低于低于预估内存大小的Redis实例规格;
• 此公式仅仅预估了Redis内存规格选择,实际规格选择还需要考虑到QPS压力等因素,请综合参考后续的QPS资源评估方案等,但内存资源评估是基础,请率先评估;

例如某业务,预计云Redis保存500W个key , 平均key大小为1KB

预估Redis规格的内存大小(单位GB) =  5000000 * 1 / 0.8 / 1024 /1024 = 5.96

即需要约6G内存,由于云Redis没有6G的实例规格,因此需要选择8G的实例规格,具体是选择社区版还是企业版,亦或者是标准版双副本还是集群版双副本,就需要结合业务对其他资源方面的需求决定。

5.2 QPS资源容量规划:

在经过内存规格评估确认Redis实例内存大小后,还面临如何选择实例类型的问题,是使用集群版还是主从版?是使用社区版还是企业版?要不要用读写分离版本等问题,因此接下来我们需要进行QPS资源容量规划。
不同Redis规格对应的QPS处理能力参考值、带宽上限与连接数上限参考值不尽相同,详细的参考对应列表请参考官网介绍,依照之前进行的内存容量评估,本文先以8G
Redis为例进行不同场景下的实例类型选择说明;

redis 容灾方案 redis容量估算_云计算_04

• 表中不同规格的QPS处理能力仅为参考值,Redis不同请求复杂度、执行成本不尽相同,实际评估时可以结合压测数据与参考值进行综合评估;
• Redis 混合存储实例类型由于没有8G规格,因此表中选择了混合存储版本支持的最小规格,混合存储实例在有大量冷数据的情况下有明显性价比优势,但是整体QPS容量评估不会有太大差异,需要您结合实际情况进行选择,本文不再针对混合存储型实例进行单独对比。

场景一: 读请求与写请求相对均衡或者写请求远大于读请求(即 W > Q )

1.1、 读写请求总量不大,在单分片节点能支撑的QPS内

以社区版本Redis主从版为例,业务总预估QPS小于10W

(Q + W) * 0.8 (考虑到一定的性能冗余空间,建议参考系数为0.8 )  < 10W

则可以选择Redis社区主从版来满足业务需求,假如内存评估需要8G,则建议选择Redis 8G社区主从版

注: 如果希望使用云Redis企业版性能增强型实例或者混合存储型实例,计算方式相似,只需将10W 替换为对应期望Redis规格参考QPS值进行计算即可

1.2、 写请求总量大,超过单分片节点能支撑的QPS

所需分片节点数 = RoundUP( (Q+W)/ 0.8(考虑到一定的性能冗余空间,建议参考系数为0.8 )/ 10W , 0 )

例如业务预估读QPS为 5W,写QPS为30W,使用Redis社区集群版本, 则

所需分片节点数  :  RoundUP( (5W+30W)/ 0.8/ 10W , 0 ) = 5

假设之前评估需要的内存为8G, 则此时满足容量评估后的云Redis规格为 “社区版8G集群版(8节点)”

注: 如果希望使用云Redis企业版性能增强型实例或者混合存储型实例,计算方式相似,只需将10W 替换为对应期望Redis 规格参考QPS值进行计算即可。

场景二: 读请求远大于写请求(即 Q > W )

1.1、 内存评估在64G以内并选择使用Redis 读写分离版本

所需实例节点数 = RoundUP( (Q + W )/ 0.8(考虑到一定的性能冗余空间,建议参考系数为0.8 )/ 10W , 0 )

例如业务预估读QPS为 30W,写QPS为5W,使用Redis社区集群版本, 则

所需分片节点数  :  RoundUP( (30W+5W)/ 0.8/ 10W , 0 ) = 5

假设之前评估需要的内存为8G,则此时满足容量评估的云Redis规格为“社区版读写分离8G版(1节点每节点5只读)"

注:
如果业务中不存才集群版受限命令,除了选择读写分离版本来提高读请求处理能力,当然也可以通过云集群版多节点的方式来增加读处理能力,计算方式不变,性价比需要对比不过规格类型进行对比综合考虑

1.2、 内存评估大于64G,选择Redis集群版本或者读写分离集群版本

所需实例节点数 = RoundUP( (Q + W )/ 0.8(考虑到一定的性能冗余空间,建议参考系数为0.8 )/ 10W , 0 )
  1. 例如业务预估读QPS为 30W,写QPS为5W,使用Redis社区集群版本, 则
所需分片节点数  :  RoundUP( (30W+5W)/ 0.8/ 10W , 0 ) = 5

假设之前评估需要的内存为128G,则此时满足容量评估的云Redis规格为“社区版128G集群版(8节点)”

  1. 例如业务预估读QPS为 120W,写QPS为5W,使用Redis社区集群版本, 则
所需分片节点数  :  RoundUP( (120W+5W)/ 0.8/ 10W , 0 ) = 16

假设之前评估需要的内存为128G,则此时满足容量评估的云Redis规格为“社区版读写分离128G版(16节点,每节点1只读)”

注: 如果希望使用云Redis企业版性能增强型实例或者混合存储型实例,计算方式相似,只需将10W 替换为对应期望Redis规格参考QPS值进行计算即可.

5.3 带宽资源容量规划:

由于云Redis不同规格中的带宽资源不同,在做完内存容量评估和QPS容量评估后,还需要加入考虑带宽资源的评估。

以上述QPS容量评估中例子来说明,读QPS为 30W,写QPS为5W,内存评估需要128G,第一阶段我们评估是需要的是“社区版128G集群版(8节点)”,假设此时经过压测发现,由于业务中存在的key 平均大小较大且QPS较高,预估需要的带宽为1000MB/s ,“社区版128G集群版(8节点)”对应的带宽为768MB/s ,不满足要求,因此需要增加节点升高规格提供带宽处理能力,因此需要建议使用“128G集群版(16节点)”,此规格对应的带宽为1536MB/s。

5.4 连接数资源容量规划:

在做完上述内存、QPS、带宽资源容量评估后,剩下需要考虑的因素为连接数,通常连接数不会成为瓶颈,但是在一些业务场景,例如高并发访问的PHP业务,由于PHP使用的是短链接请求,因此连接数使用率可能较高并可能会存在潜在瓶颈。

以上述QPS容量评估中例子来说明,读QPS为 30W,写QPS为5W,内存评估需要128G,第一阶段我们评估是需要的是“社区版128G集群版(8节点)”,此时业务评估需要每秒连接数为4W,总连接数数为10W,即(Z = 4W,Y = 10W)

社区版128G集群版(8节点) 规格对应的每秒新建连接数上限为5W,连接数总数上限为8W
则 
Z < 5W (满足要求)
Y > 8W (不满足要求)
此规格不满足需求

在这种情况下,需要考虑使用满足内存、QPS、带宽三者要求的更大连接数的Redis 规格,例如 “128G集群版(16节点)” ,此规格对应的每秒连接数为5W,总连接数数为16W满足需求。

连接数计算规则

• 每秒新建连接数上限即每秒内可新增的连接数量。例如,实例的每秒新建连接数为上限为10000,连接数上限为50000,实例运行后的第n秒的实际连接数为12000,则第n+1秒时,实际连接数最大为22000(即12000+10000),即使22000并没有超过实例的连接数上限50000。
• 每秒新建连接数上限和连接数上限都是实例中所有分片或节点相应值的总和。实例连接数上限不超过500000,达到该值后,即使分片或节点数增加,连接数上限也不会提高。

六、用户场景模拟

为了让各位对云产品Redis的版本、实例架构等软硬件资源有更清晰的了解,结合阿里云团队在云端面对各业务线用户的需求,提炼出相对经典的案例,让各位对云产品redis有更深一步的了解。

6.1 场景描述:某业务线客户提出需求16G redis 主从 10WQPS已经满了,但其目标是想达到100WQPS ,并且现在REDIS CPU也已经打满,问有什么解决思路?

6.2 解决思路:

首先会导致cpu满的原因可能有以下几点原因造成:

  1. redis连接数过高
  2. 数据持久化导致的阻塞
  3. 主从存在频繁全量同步
  4. value值过大
  5. reids慢查询

6.3 分析流程:

  1. 登录管理平台,通过提供实例ID信息,进入实例诊断界面,观察connection相关指标信息,找出cpu打满时间点是否有高频连接进入导致超出redis
    连接配额上线导致。
  2. 通过Redis_CpuDetail指标观察是sys指标还是user指标对cpu的占用率偏高,是否是某一个节点引起的高,还是全部节点高于平常均值。
  3. 观察Redis_Keys_Monitor是否有高耗能命令导致慢查询,结合上述CPU出现爆满时间点发现同时也有慢查询,基本可以初步定位问题发生点。
  4. 再结合UsedQPS+QPSUsage 两个指标通过时间点关联慢查询时间点观察是否出现慢查询的同时导致QPS数量骤增。
  5. 最后通过QuotaQPS 指标观察本redis实例是否能满足达到100Wqps的数量,可以采取增加分片部署或变更配置的方式突破线程性能瓶颈;

针对上述末尾如何采取分片部署或变更配置的方式突破线程性能瓶颈,实现方法以下来逐一进行介绍:根据目前客户16gredis的主从架构,是无法满足QPS100W的需求,甚至随着业务量增长会产生更多性能问题并发,我们可以通过考虑变配内存大小或者更换架构形式来满足客户需求。

6.4 客户要求Redis在使用16GB内存的情况下,云产品Redis应该如何满足100W的QPS需求?

版本选择: 因客户的硬性需求,redis社区版虽满足高性能要求,但5.0和6.0的社区版本目前是无法满足100W的QPS消耗,而社区版更偏重于适合中小型或验证型应用,适用于标准化Redis使用场景,所以更建议推荐使用云产品的redis集群版。

类型选择: 云数据库redis支持四种实例类型的选择,根据云产品类型和问题需求进行初步评审,推荐使用云数据库企业版的“性能增强型”或者社区版的集群单副本类型,首选推荐“性能增强型”该类型对比其他三种类型主要优势在于适合并发量大、读写热点多,对性能的要求超过云Redis社区版实例的场景,并且采用性能增强型(集群架构)实例后,集群规模缩到原来的三分之一,管理维护成本大幅降低,接下来介绍部署架构。

部署架构: 根据上述类型选择,这里推荐考虑云数据库redis企业版的集群版双副本、读写分离版和社区版的集群单副本架构供客户选择。

  1. 集群版单副本版架构: 更适合纯缓存类型的业务场景,如客户对数据存储没有过高的持久化要求,且对备份策略无硬性条件的前提下,该架构能同时满足数据量较大、QPS压力较大的使用场景,因此可考虑采用此架构;该架构简单介绍由Proxy服务器、分片服务器、配置服务器组成,proxy服务器主要用于负载均衡、转发等服务,分片服务器采用的是单节点架构,没有备用节点实时同步数据,不提供数据持久化和备份策略,数据节点故障之后,系统会在30秒内重新拉起一个Redis进程保证服务高可用,但是该节点的数据将会丢失掉。而配置服务器用于存储集群配置信息及分区策略等信息,采用双副本架构,保证高可用;目前该架构只支持社区版。
  2. 集群版多副本架构: 该架构是基于单副本架构的升级版,在数据分片处理上进行了迭代,每个数据分片均为双副本(分别部署在不同机器上)高可用架构,主节点发生故障后,系统会自动进行主备切换保证服务高可用;并且由原来单副本代理模式新增了“直连模式”(因所有请求都要通过代理服务器转发,代理模式在降低业务开发难度的同时也会小幅度影响Redis服务的响应速度。如果业务对响应速度的要求非常高,您可以使用直连模式,绕过代理服务器直接连接后端数据分片,从而降低网络开销和服务响应时间。)而且用户可以选择直连模式和代理模式同时使用,在数据存储方面也显示出量级的提升,从单副本数据量256G的扩容容量提升到最大可达4098G可支持的扩容容量,能有效满足业务的扩展需求。目前该架构支持社区版和企业版。
  3. 读写分离版: 该版本对比集群多副本架构来说,更针对于读取请求更大的压力场景,读写分离版主要由主备节点、只读节点、Proxy(代理)节点和高可用系统组成;主节点承担写请求的处理,同时和只读节点共同承担读请求的处理;备节点作为数据备份使用,不对外提供服务;只读节点承担读请求的处理。只读节点采取链式复制架构,扩展只读节点个数可使整体实例性能呈线性增长。同时,采用优化后的binlog执行数据同步,可最大程度地规避全量同步;proxy节点在于客户端建立连接后,会自动识别客户端发起的请求类型,按照权重负载均衡(暂不支持自定义权重),将请求转发到不同的数据节点中。例如将写请求转发给主节点,将读请求转发给主节点或只读节点;HA高可用系统自动监控各节点的健康状态,异常时发起主备切换或重搭只读节点,并更新相应的路由及权重信息;但当一个只读节点发生故障时,请求会转发到其他节点;如果所有只读节点均不可用,请求会全部转发到主节点。只读节点异常可能导致主节点负载提高、响应时间变长,因此在读负载高的业务场景建议使用多个只读节点,所以根本的使用条件还需看用户QPS的分布和主观需求来选择使用,目前该架构支持企业版和社区版。

实例规格: 以上三种部署架构企业版或社区版都会有各种实例规格组成,而在云产品redis方向更是分为社区版(本地盘)、企业版(本地盘)、社区版(云盘)、企业版(云盘)等四大类实力规格供需所求,在云产品众多的Redis实例规格中,结合客户需求推荐考虑采用“企业版(Tair)性能增强型16GB集群版实例规格”,首先该云产品在redis内核线程处理方式上进行了新版本的突破,由单一线程处理改为多线程处理方式,在秉持的redis原来有协议的前提下,更高效更快速的接收请求、处理请求等流程,而每个数据分片均为主从双副本架构,性能约为同规格社区版实例的3倍。内存容量上限按上述架构描述可达4096GB,支持高达61440000GPS性能压测,能更好的满足客户目前现有需求,也能为客户未来业务扩容做好充分的基础架构准备;而所推荐的16GB集群性能增强版每个节点支持4条线程、2分片,同时保证5W的新建连接数、24W的连接数上线并且能保持高达768MB/S的带宽网络和高达192W的QPS量,基本上该款实例规格结合物理和逻辑架构都比较符合该问题的需求。

配置变更: 根据上述问题回答串联,可以考虑对现有产品规格进行变配,如目前规格是0到1的建立,可以参考官方协助文档按照对应的步骤建立即可;
https://help.aliyun.com/document_detail/54592.html?spm=a2c4g.11186623.6.628.6f3d2c3fsxb5tL 如是采取变更配置,云数据库Redis的集群架构与非集群架构可相互切换,如需变配到较低规格的另一种架构,要先变配到另一架构的同一规格,再降配;详细操作可参考官方协助文档。
https://help.aliyun.com/document_detail/26353.html?spm=a2c4g.11186623.6.691.2d0c254bDASiZ5

场景小结: 结合客户的需求与密切的沟通,协助客户梳理了整个云产品Redis软硬件体系架构,针对整个处理流程简单的描述下,以客户需求角度来看就是100W的QPS,但前提是需要先去判断这个QPS总量是以读为主还是写为主还是读写均衡为主,可以通过后台管理平台去查询相应指标,并且因为100WQPS 一个节点的Redis肯定撑不住,肯定要多节点,如果业务侧以读为主,且读占大头,可以考虑采用读写分离版本(注意,这个版本有只读节点个数限制),如果只读节点不够、满足不了或者是以写请求为主,推荐使用云产品集群版,而这里又分为社区版集群和企业版集群,以及单节点版本和集群版多副本版本,通常在满足客户需求抉择云产品实例架构时,通常会建议客户采用企业级多副本版本,因为更加安全、而且对Redis原生协议更契合,也是对社区版Redis的一种全新迭代。