云服务器内容精选

  • 入门实践 本文介绍DCS常见的应用实践,帮助您更好的使用DCS。 实践 描述 使用DCS实现热点资源顺序访问 在互联网场景,如商品秒杀中,随着整个系统的并发飙升,需要多台机器并发运行,假设此时两个用户的请求同时到来,但落在了不同的机器上,虽然这两个请求可以同时执行,但是因为两个机器运行在两个不同的Java虚拟机里面,其加的锁只对属于自己Java虚拟机里面的线程有效,对于其他Java虚拟机的线程是无效的。使用DCS服务Redis缓存实例实现分布式加锁,用加锁的方式对热点资源进行顺序访问控制,能够避免出现库存超卖及无序访问等现象。该实践介绍如何使用Redis对分布式应用加锁。 使用Nginx实现公网访问Redis Redis 4.0及以上版本Redis默认不支持公网访问,该实践主要介绍通过跳板机访问VPC内Redis实例,实现公网访问Redis。 Redis客户端通过CCE连接DCS 随着容器技术的普及,越来越多的应用程序部署在容器环境中。该实践介绍如何将Redis客户端部署到云容器引擎CCE的集群容器中,通过CCE连接DCS。
  • 创建Redis实例 进入购买缓存实例页面。 选择“计费模式”,此处以创建“按需计费”Redis为例。 在“区域”下拉列表中,选择靠近您应用程序的区域,可降低网络延时、提高访问速度。 “项目”保持默认即可。 选择实例配置,配置详情请参考表1 选择实例配置。 表1 选择实例配置 参数 配置说明 缓存类型 默认为“Redis”。 产品类型 选择“基础版”。 CPU架构 默认为“x86”。 版本号 选择“5.0”。 实例类型 选择“单机”。 可用区 保持默认的可用区即可。 实例规格 此处以选择“规格”为“128 MB”的实例规格为例。 虚拟私有云 选择已准备的VPC和子网。 通过弹性云服务器ECS访问Redis实例时,请选择与ECS相同的虚拟私有云。 IP地址 支持选择“自动分配IP地址”或“手动分配地址”,支持输入自定义端口,当不输入端口时,为默认的6379端口。 为简单起见,此处保持默认的“自动分配IP地址”和默认6379端口即可。 安全组 Redis 5.0不支持配置安全组,建议创建实例后配置实例白名单。 名称 实例名称。 创建时会默认会生成一个随机的名称,请根据需要自定义。 企业项目 默认的企业项目为“default”。 如果没有可选的企业项目,请参考创建DCS时选择不到需要的企业项目。 访问方式 连接实例方式可选择“密码访问”或“免密访问”。 如选择“密码访问”,请输入“密码”和“确认密码”。 参数配置 选择“系统默认”的参数模板即可。 数量 设置购买的实例数量,默认创建1个实例。 更多配置(可选) 单击展开“更多配置”,可根据需要设置实例的“描述”、“命令重命名”、“维护时间窗”和“标签”。 为简单起见,此处无需配置。您也可以在实例创建完成后,根据需要在控制台对实例进行命令重命名、管理标签、或修改实例维护时间窗。 配置费用 页面左下角为当前实例配置的参考价格,如需了解更多价格详情,单击“了解计费详情”。 单击“立即购买”。 确认实例信息无误后,单击“提交”。 当实例“状态”为“运行中”,实例创建成功。 缓存实例创建成功后,您可以在“缓存管理”页面,查看并管理自己的缓存实例。
  • 不同实例类型的副本和分片数 单机实例:单机实例只有1个节点,1个Redis进程,当Redis进程故障后,DCS为实例重新拉起一个新的Redis进程。 主备/读写分离实例:分片数为1,包含一个主节点,一个或多个备节点。当主节点出现故障时,会进行主备倒换,恢复业务。副本数(备节点)越多,保障性更强,对实例的性能没有影响。 集群实例:集群实例由多个分片组成,每个分片默认是一个双副本的主备实例。例如一个3分片,3副本的集群实例,则每个分片都有3个节点(1个主节点,2个备节点)。 实例类型 分片数 副本数 负载均衡 占用IP数 单机 单分片 单副本,不支持多副本 - 1个 主备 单分片 默认双副本 Redis 4.0/5.0版本主备实例支持2-10副本,其他版本仅支持2副本 不支持 占用IP个数=副本数 读写分离 单分片 默认双副本,支持2-6副本 支持 1个 Proxy集群 多分片 双副本,不支持其他副本数 支持 1个 Cluster集群 多分片 默认双副本 Redis 4.0/5.0版本Cluster集群支持1-5副本,Redis 6.0版本支持1-2副本 不支持 占用IP个数=副本数*分片数
  • 命令使用规范 原则 原则说明 级别 备注 谨慎使用O(N)复杂度的命令 时间复杂度为O(N)的命令,需要特别注意N的值。避免N过大,造成Redis阻塞以及CPU使用率冲高。 强烈建议 例如:hgetall、lrange、smembers、zrange、sinter这些命令都是做全集操作,如果元素很多,会消耗大量CPU资源。可使用hscan、sscan、zscan这些分批扫描的命令替代。 禁用高危命令 禁止使用flushall、keys、hgetall等命令,或对命令进行重命名限制使用。 强烈建议 请参考命令重命名的内容。 慎重使用select Redis多数据库支持较弱,多业务用多数据库实际还是单线程处理,会有干扰。最好是拆分使用多个Redis。 建议 - 使用批量操作提高效率 如果有批量操作,可使用mget、mset或pipeline,提高效率,但要注意控制一次批量操作的元素个数。 建议 mget、mset和pipeline的区别如下: mget和mset是原子操作,pipeline是非原子操作。 pipeline可以打包不同的命令,mget和mset做不到。 使用pipeline,需要客户端和服务端同时支持。 避免在lua脚本中使用耗时代码 lua脚本的执行超时时间为5秒钟,建议不要在lua脚本中使用比较耗时的代码。 强烈建议 比如长时间的sleep、大的循环等语句。 避免在lua脚本中使用随机函数 调用lua脚本时,建议不要使用随机函数去指定key,否则在主备节点上执行结果不一致,从而导致主备节点数据不一致。 强烈建议 - 遵循集群实例使用lua的限制 遵循集群实例使用lua的限制。 强烈建议 使用EVAL和EVALSHA命令时,命令参数中必须带有至少1个key,否则客户端会提示“ERR eval/evalsha numkeys must be bigger than zero in redis cluster mode”的错误。 使用EVAL和EVALSHA命令时,DCS Redis集群实例使用第一个key来计算slot,用户代码需要保证操作的key是在同一个slot。 对mget,hmget等批量命令做并行和异步IO优化 某些客户端对于MGET,HMGET这些命令没有做特殊处理,串行执行再合并返回,效率较低,建议做并行优化。 建议 例如Jedis对于MGET命令在集群中执行的场景就没有特殊优化,串行执行,比起lettuce中并行pipeline,异步IO的实现,性能差距可达到数十倍,该场景建议使用Jedis的客户端自行实现slot分组和pipeline的功能。 禁止使用del命令直接删除大Key 使用del命令直接删除大Key(主要是集合类型)会导致节点阻塞,影响后续请求 强烈建议 Redis 4.0后的版本可以通过UNLINK命令安全地删除大Key,该命令是异步非阻塞的。 对于Redis 4.0之前的版本: 如果是Hash类型的大Key,推荐使用hscan + hdel 如果是List类型的大Key,推荐使用ltrim 如果是Set类型的大Key,推荐使用sscan + srem 如果是SortedSet类型的大Key,推荐使用zscan + zrem
  • SDK使用规范 原则 原则说明 级别 备注 使用连接池和长连接 短连接性能差,推荐使用带有连接池的客户端。 建议 连接的频繁创建和销毁,会浪费大量的系统资源,极限情况会造成宿主机宕机。请确保使用了正确的Redis客户端连接池配置。 客户端需要对可能的故障和慢请求做容错处理 由于Redis服务可能因网络波动或基础设置故障的影响,引发主备倒换,命令超时或慢请求等现象,需要在客户端内设计合理的容错重试机制。 建议 参考Redis客户端重试指南。 合理设置重试时间和次数 合理设置容错处理的重试时间,根据业务要求设置,避免过短或者过长。 强烈建议 如果超时重试时间设置的非常短(例如200毫秒以下),可能引发重试风暴,极易引发业务层雪崩。 如果重试时间设置得较长或者重试次数设置得较大,则可能导致在主备倒换情况下业务恢复较慢。 避免使用Lettuce客户端 Lettuce客户端在默认配置下有一定性能优势,并且是spring的默认客户端,但是Jedis客户端在面对连接异常,网络抖动等场景下的异常处理和检测能力明显强于Lettuce,可靠性更强,建议使用Jedis。 建议 Lettuce存在几个方面的问题: Lettuce默认未配置集群拓补刷新的配置,会导致Cluster集群在发生拓补信息变化(主备倒换,扩容缩容)时,无法识别新的节点信息,导致业务失败。可参考使用Lettuce连接Cluster集群实例时的扩容异常处理。 Lettuce没有连接池校验的功能,无法检测连接池中的连接是否仍然有效,获取失效连接之后会导致业务失败。
  • 数据设计规范 分类 原则 原则说明 级别 备注 Key相关规范 使用统一的命名规范。 一般使用业务名(或数据库名)为前缀,用冒号分隔。Key的名称保证语义清晰。 建议 例如,业务名:子业务名:id 控制Key名称的长度。 在保证语义清晰的情况下,尽量减少Key的长度。有些常用单词可使用缩写,例如,user缩写为u,messages缩写为msg。 建议 建议不要超过128字节(越短越好)。 禁止包含特殊字符(大括号“{}”除外)。 禁止包含特殊字符,如空格、换行、单双引号以及其他转义字符。 强烈建议 由于大括号“{}”为Redis的hash tag语义,如果使用的是集群实例,Key名称需要正确地使用大括号避免分片不均的情况。 Value相关规范 设计合理的Value大小。 设计合理的Key中Value的大小,推荐小于10 KB。 建议 过大的Value会引发分片不均、热点Key、实例流量或CPU使用率冲高等问题,还可能导致变更规格和迁移失败。应从设计源头上避免此类问题带来的影响。 设计合理的Key中元素的数量。 对于集合和列表类的数据结构(例如Hash,Set,List等),避免其中包含过多元素,建议单Key中的元素不要超过5000个。 建议 由于某些命令(例如HGETALL)的时间复杂度直接与Key中的元素数量相关。如果频繁执行时间复杂度为O(N)及以上的命令,且Key中的子Key数量过多容易引发慢请求、分片流量不均或热点Key问题。 选择合适的数据类型。 合理地选择数据结构能够节省内存和带宽。 建议 例如存储用户的信息,可用使用多个key,使用set u:1:name "X"、set u:1:age 20存储,也可以使用hash数据结构,存储成1个key,设置用户属性时使用hmset一次设置多个,同时这样存储也能节省内存。 设置合理的过期时间。 合理设置Key的过期时间,将过期时间打散,避免大量Key在同一时间点过期。 建议 设置过期时间时,可以在基础值上增减一个随机偏移值,避免在同一个时间点大量Key过期。大量Key过期会导致CPU使用率冲高。
  • 运维管理规范 原则 原则说明 级别 备注 生产开启密码保护 生产系统中需要开启Redis密码保护机制。 强烈建议 - 现网操作安全 禁止开发人员私自连到线上Redis服务。 强烈建议 - 验证业务的故障处理能力或容灾逻辑 在测试环境或者预生产环境中组织演练,验证在Redis主备倒换、宕机或者扩缩容场景下业务的可靠性。 建议 主备倒换可以自行在页面上触发。强烈建议使用Lettuce客户端的应用进行相关的演练。 监控实践 关注Redis负载,在过载前提前扩容。 强制 根据告警基线配置告警:配置节点cpu、内存、带宽等告警。 日常巡检 例行检查各个节点的内存使用率,查看主节点内存使用率是否有不均衡的状态。 建议 内存使用率不均衡说明存在大Key问题,需要进行大Key拆分及优化。 开启热Key例行分析,并分析是否有Key频繁调用。 建议 - 例行诊断Redis实例的命令,分析O(N)类命令是否存在隐患。 建议 针对O(N)命令,即使耗时很小,建议开发分析业务增长,N是否会增长。 例行巡检Redis慢日志命令。 建议 针对慢日志分析隐患,并尽快从业务上进行修复。
  • 业务使用规范 原则 原则说明 级别 备注 就近部署业务,避免时延过大 如果部署位置过远(非同一个region)或者时延较大(例如业务服务器与Redis实例通过公网连接),网络延迟将极大影响读写性能。 强烈建议 如果对于时延较为敏感,请避免创建跨AZ Redis实例。 冷热数据区分 建议将热数据加载到 Redis 中。低频数据可存储在 Mysql或者ElasticSearch中。 建议 Redis将低频数据存入内存中,并不会加速访问,且占用Redis空间。 业务数据分离 避免多个业务共用一个Redis。 强烈建议 一方面避免业务相互影响,另一方面避免单实例膨胀,并能在故障时降低影响面,快速恢复。 禁止使用select功能在单Redis实例做多db区分。 强烈建议 Redis单实例内多DB隔离性较差,Redis开源社区已经不再发展多DB特性,后续不建议依赖该特性。 设置合理的内存淘汰(逐出)策略 合理设置淘汰策略,可以在Redis内存意外写满的时候,仍然正常提供服务。 强烈建议 DCS默认的逐出策略为volatile-lru,请根据业务需求选择。Redis支持的数据逐出策略 以缓存方式使用Redis Redis事务功能较弱,不建议过多使用。 建议 事务执行完后,不可回滚。 数据异常的情况下,支持清空缓存进行数据恢复。 强烈建议 Redis本身没有保障数据强一致的机制和协议,业务不能强依赖Redis数据的准确性。 以缓存方式使用Redis时,所有的key需设置过期时间,不可把Redis作为数据库使用。 强烈建议 失效时间并非越长越好,需要根据业务性质进行设置。 防止缓存击穿 推荐搭配本地缓存使用Redis,对于热点数据建立本地缓存。本地缓存数据使用异步方式进行刷新。 建议 - 防止缓存穿透 非关键路径透传数据库,建议对访问数据库进行限流。 建议 - 从Redis获取数据未命中时,访问只读数据库实例。可通过域名等方式对接多个只读实例。 建议 核心是未命中的缓存数据不会打到主库上。 用域名对接多个只读数据库实例,一旦出现问题,可以增加只读实例应急。 不用作消息队列 发布订阅场景下,不建议作为消息队列使用。 强烈建议 如没有非常特殊的需求,不建议将 Redis 当作消息队列使用。 Redis 当作消息队列使用,会有容量、网络、效率、功能方面的多种问题。 如需要消息队列,可使用高吞吐的Kafka或者高可靠的RocketMQ。 合理选择规格 如果业务增长会带来Redis请求增长,请选择集群实例(Proxy集群和Cluster集群) 强烈建议 单机和主备扩容只能实现内存、带宽的扩容,无法实现计算性能扩容。 生产实例需要选择主备或者集群实例,不能选用单机实例 强烈建议 - 主备实例,不建议使用过大的规格。 建议 Redis在执行RewriteAOF和BGSAVE的时候,会fork一个进程,过大的内存会导致卡顿 具备降级或容灾措施 缓存访问失败时,具备降级措施,从DB获取数据;或者具备容灾措施,自动切换到另一个Redis使用。 建议 -
  • 应用场景 电商秒杀是一种网上竞拍活动,通常商家会在平台释放少量稀缺商品,吸引大量客户,平台会收到平时数十倍甚至上百倍的下单请求。但是只有少数客户可以下单成功。电商秒杀系统的分流过程可以分为以下几个步骤: 用户请求进入系统:当用户发起秒杀请求时,请求会首先进入负载均衡服务器。 负载均衡:负载均衡服务器会根据一定的算法将请求分发给后端多台服务器,以达到负载均衡的目的。负载均衡算法可以采用轮询、随机、最少连接数等方式。 业务逻辑处理:后端服务器接收到请求后,进行业务逻辑处理,并根据请求的商品数量、用户身份等信息进行校验。 库存扣减:如果库存充足,后端服务器会进行库存扣减操作,并生成订单信息,返回给用户秒杀成功的信息;如果库存不足,则返回给用户秒杀失败的信息。 订单处理:后端服务器会将订单信息保存到数据库中,并进行异步处理,例如发送消息通知用户订单状态。 缓存更新:后端服务器会更新缓存中的商品库存信息,以便处理下一次秒杀请求。 秒杀过程中多次访问数据库,下单通常是利用行级锁进行访问限制,抢到锁才能查询数据库和下单。但是秒杀时的大量订单请求,往往使数据库访问阻塞。
  • 通过访问控制,保护数据安全性 正确的使用DCS提供的访问控制能力,可以有效预防您的数据被异常窃取或者破坏。 建议对不同角色的IAM用户仅设置最小权限,避免权限过大导致数据泄露或被误操作。 为了更好的进行权限隔离和管理,建议您配置独立的IAM管理员,授予IAM管理员IAM策略的管理权限。IAM管理员可以根据您业务的实际诉求创建不同的用户组,用户组对应不同的数据访问场景,通过将用户添加到用户组并将IAM策略绑定到对应用户组,IAM管理员可以为不同职能部门的员工按照最小权限原则授予不同的数据访问权限,详情请参见DCS权限管理。 建议配置白名单或安全组访问控制,保护您的数据不被异常读取和操作。 租户创建DCS实例后,可以通过配置白名单或安全组的方式进行访问控制。租户配置IP白名单或安全组的入方向、出方向规则限制,可以控制连接实例的网络范围,避免DCS暴露给不可信第三方。 Redis 4.0、Redis 5.0和Redis 6.0基础版通过白名单控制,请参考配置白名单。 Redis 6.0企业版通过配置安全组访问规则控制,请参考配置安全组。安全组入方向规则的“源地址”应避免设置为0.0.0.0/0。 建议不使用高危命令,避免攻击者直接对Redis进行致命性破坏。 为避免攻击者直接对Redis进行致命性破坏,如果业务没有使用场景,建议通过命令重命名的方式对其进行禁用, 相关列表请参见默认禁用的命令列表,支持重命名的命令列表。 建议使用非默认端口,避免端口被扫描攻击。 Redis Server监听的端口默认为6379,容易被扫描攻击,建议将端口设置为非默认端口。支持修改的端口范围:1~65535之间的其它端口号。详情请参见自定义或修改端口。 建议限制Redis客户端最大连接数,通过限制使用的资源,降低资源耗尽和拒绝服务风险。 Redis的maxclients参数决定了实例最大支持同时连接的客户端个数,默认值为10000,设置范围为1000~50000。如果超过自定义的连接数阈值,新的连接请求将被拒绝。 建议根据应用的具体使用场景设置合适的客户端最大连接数,限制资源耗尽和拒绝服务的可能性。修改maxclients参数请参见修改配置参数。 建议限制Redis连接闲置等待时间,根据业务实际场景来设置具体时间。 为避免client空闲连接长时间占用资源,可在控制台界面配置闲置等待时间(timeout参数),设置超时阈值后,将在连接空闲指定的秒数后关闭客户端连接。timeout默认值为0,表示服务端不会主动断开客户端的空闲连接。设置范围为0~7200,单位:秒。 建议根据应用的具体使用场景设置实际闲置等待时间,不建议将timeout设置为0。例如,可以将timeout设置为3600秒。避免出现资源耗尽和拒绝服务的可能性。修改timeout参数请参见修改配置参数。 建议将访问DCS实例方式设置为密码访问,防止未经认证的客户端误操作实例。达到对客户端进行认证访问的目的,提高实例使用的安全性。 您可以在购买Redis实例时进行设置访问密码,也可以对已创建的免密实例进行密码重置。 建议为DCS实例配置ACL访问控制权限。 DCS管理员可以为实例创建只读账号或者读写账号,用于不同业务场景下访问DCS的精细管控。 建议不同的业务使用不同的DCS实例,避免实例故障影响多个业务。
  • 审计是否存在异常数据访问 开启云审计服务,记录DCS的所有访问操作,便于事后审查。 云审计服务(Cloud Trace Service,CTS),是华为云安全解决方案中专业的日志审计服务,提供对各种云资源操作记录的收集、存储和查询功能,可用于支撑安全分析、合规审计、资源跟踪和问题定位等常见应用场景。 您开通云审计服务并创建和配置追踪器后,CTS可记录DCS的管理事件和数据事件用于审计。详情请参见云审计服务支持的关键操作。 使用云监控服务对安全事件进行实时监控和告警。 您在使用DCS的过程中会也可能会遇到服务端返回的错误响应,为使您更好地掌握DCS实例状态,华为云提供了云监控服务(Cloud Eye)。您可使用该服务监控自己的DCS实例,执行自动实时监控、告警和通知操作,帮助您实时掌握DCS实例中所产生的请求、流量和错误响应等信息。 云监控服务不需要开通,会在用户创建DCS实例后自动启动。相关文档请参见支持的监控指标、必须配置的监控告警。
  • 构建数据的恢复和容灾能力 预先构建数据的容灾和恢复能力,可以有效避免异常数据处理场景下数据误删、破坏的问题。 建议开启实例自动备份,获得异常场景数据快速恢复能力。 DCS提供自动备份和手动备份两种备份操作。自动备份默认未开启,需要租户选择是否开启,备份存储期限最多7天。同时,开启自动备份后,允许对实例执行备份文件的恢复。自动备份请参见设置备份策略。 说明:手动备份是租户手动触发的实例全量备份,这些备份数据存储在华为OBS桶中,当租户删除实例时,会同步删除OBS桶中的快照。 建议使用跨AZ复制构建数据容灾能力。 DCS的主备和集群实例支持部署高可用实例,租户可选择在单可用区或多可用区中部署实例。 当租户选择跨AZ实例时,DCS实例会主动建立和维护Redis同步复制。在实例主节点故障的情况下,缓存实例会自动将备实例升为主节点,从而达到高可用的目的。
  • 如何优化大Key和热Key 类别 方法 大Key 进行大Key拆分。 分为以下几种场景: 该对象为String类型的大Key:可以尝试将对象分拆成几个Key-Value, 使用MGET或者多个GET组成的pipeline获取值,分拆单次操作的压力。如果是集群实例,由于集群实例包含多个分片,拆分后的Key会自动平摊到集群实例的多个分片上,从而降低对单个分片的影响。 该对象为集合类型的大Key,并且需要整存整取:在设计上严格禁止这种场景的出现,因为无法拆分。有效的方法是将该大Key从Redis去除,单独放到其余存储介质上。 该对象为集合类型的大Key,每次只需操作部分元素:将集合类型中的元素分拆。以Hash类型为例,可以在客户端定义一个分拆Key的数量N,每次对HGET和HSET操作的field计算哈希值并取模N,确定该field落在哪个Key上,实现上类似于Redis Cluster的计算slot的算法。 将大Key单独转移到其余存储介质。 无法拆分的大Key建议使用此方法,将不适用Redis能力的数据存至其它存储介质,如SFS或者其余NoSQL数据库,并在Redis中删除该大Key。 注意: 禁止使用DEL直接删除大Key,可能会造成Redis阻塞,甚至主备倒换。 合理设置过期时间并对过期数据定期清理。 合理设置过期时间,避免历史数据在Redis中大量堆积。由于Redis的惰性删除策略,过期数据可能并不能及时清理,如果发现Redis过期Key清理较慢,建议配置过期Key扫描。 热Key 使用读写分离。 如果热Key主要是读流量较大,则可以在客户端配置读写分离,降低对主节点的影响。还可以增加多个副本以满足读需求,但是备机较多也有相应的影响,DCS主备节点之间使用的是星型复制,即所有的备节点都直接和主节点保持同步,这样能保证备节点之间相互独立,且复制延迟较小。缺点是在备节点数量较多的情况下,主节点的CPU和网络负载会较高。 使用客户端缓存/本地缓存。 该方案需要提前了解业务的热点Key有哪些,设计客户端/本地和远端Redis的两级缓存架构,热点数据优先从本地缓存获取,写入时同时更新,这样能够分担热点数据的大部分读压力。缺点是需要修改客户端架构和代码,改造成本较高。 设计熔断/降级机制。 热Key极易造成缓存击穿,高峰期请求都直接透传到后端数据库上,从而导致业务雪崩。因此热Key的优化一定需要设计系统的熔断/降级机制,在发生击穿的场景下进行限流和服务降级,保护系统的可用性。
  • 大Key和热Key的影响 类别 影响 大Key 造成规格变更失败。 Redis集群变更规格过程中会进行数据rebalance(节点间迁移数据),单个Key过大的时候会触发Redis内核对于单Key的迁移限制,造成数据迁移超时失败,Key越大失败的概率越高,大于512MB的Key可能会触发该问题。 造成数据迁移失败。 数据迁移过程中,如果一个大Key的元素过多,则会阻塞后续Key的迁移,后续Key的数据会放到迁移机的内存Buffer中,如果阻塞时间太久,则会导致迁移失败。 容易造成集群分片不均的情况。 各分片内存使用不均。例如某个分片占用内存较高甚至首先使用满,导致该分片Key被逐出,同时也会造成其他分片的资源浪费。 各分片的带宽使用不均。例如某个分片被频繁流控,其他分片则没有这种情况。 客户端执行命令的时延变大。 对大Key进行的慢操作会导致后续的命令被阻塞,从而导致一系列慢查询。 导致实例流控。 对大Key高频率的读会使得实例出方向带宽被打满,导致流控,产生大量命令超时或者慢查询,业务受损。 导致主备倒换。 对大Key执行危险的DEL操作可能会导致主节点长时间阻塞,从而导致主备倒换。 热Key 容易造成集群分片不均的情况。 造成热Key所在的分片有大量业务访问而同时其他的分片压力较低。这样不仅会容易产生单分片性能瓶颈,还会浪费其他分片的计算资源。 使得CPU冲高。 对热Key的大量操作可能会使得CPU冲高,如果表现在集群单分片中就可以明显地看到热Key所在的分片CPU使用率较高。这样会导致其他请求受到影响,产生慢查询,同时影响整体性能。业务量突增场景下甚至会导致主备切换。 易造成缓存击穿。 热Key的请求压力过大,超出Redis的承受能力易造成缓存击穿,即大量请求将被直接指向后端的数据库,导致数据库访问量激增甚至宕机,从而影响其他业务。 对于如何避免产生大Key和热Key,需要在业务设计阶段就考虑。参考Redis使用规范。
  • 大Key和热Key的定义 名词 定义 大Key 大Key可以分为两种情况: Key的Value较大。一般单个String类型的Key大小达到10KB,或者集合类型的Key总大小达到50MB,则定义其为大Key。 Key的元素较多。一般定义集合类型的Key中元素超过5000个,则认为其为大Key。 热Key 通常以一个Key被操作的频率和占用的资源来判定其是否为热Key,例如: 某个集群实例一个分片每秒处理10000次请求,其中有3000次都是操作同一个Key。 某个集群实例一个分片的总带宽使用(入带宽+出带宽)为100Mbits/s,其中80Mbits是由于对某个Hash类型的Key执行HGETALL所占用。 说明:大Key和热Key场景较多,没有非常明确的边界,需要根据实际业务判断。