云服务器内容精选

华为云首页用户手册

数据库

云数据库 GEMINIDB-管理自动备份:自动备份策略

自动备份策略系统按照自动备份策略，对数据库进行自动备份，备份将以压缩包的形式存储在对象存储服务中，以保证用户数据的机密性和持久性。建议您定期对数据库进行备份，当数据库故障或数据损坏时，可以通过备份恢复数据库。由于开启备份会损耗数据库读写性能，建议您选择业务低峰时间段启动自动备份。创建数据库实例时，系统默认开启自动备份策略，默认开启的自动备份策略设置如下：图1 开启备份策略保留天数：自动备份可保留天数默认为7天。新的全量备份未超过保留天数前系统会一直保留，直至新的全量备份超过保留天数后才会删除。增加保留天数，可提升数据可靠性，请根据需要设置。减少保留天数，会针对已有的备份文件生效，即超出备份保留天数的已有备份文件（包括全量备份和增量备份）会被自动删除，但手动备份不会自动删除，请您谨慎选择。保留天数小于7天，系统每天都会进行自动备份。系统会自动检测已有的自动备份文件，若备份文件超过用户自定义的数据保留天数，则将其删除。备份时间段：默认为24小时中，间隔一小时的随机的一个时间段，例如04:00～05:00。备份时间段以GMT时区保存。如果碰到夏令时或冬令时切换，备份时间段会因时区变化而改变。假如保留天数设置为“2”，表示超过两天的全量备份和增量备份会被自动删除。即周一产生的备份会在周三删除，同理，周二产生的备份会在周四删除。全量备份文件自动删除策略：已有备份文件超出备份天数后会自动删除，考虑到数据完整性，自动删除时仍然会保留最近的一次超过保留天数的全量备份，保证在保留天数内的数据可正常恢复。假如备份周期选择“周一”、“周二”，保留天数设置为“2”，备份文件的删除策略如下：本周一产生的全量备份，会在本周四当天自动删除。原因如下：本周二的全量备份在本周四当天超过保留天数，按照全量备份文件自动删除策略，会保留最近的一个超过保留天数的全量备份（即本周二的备份会被保留），因此周四当天删除本周一产生的全量备份文件。本周二产生的全量备份，会在下周三当天自动删除。原因如下：下周一产生的全量备份在下周三超过保留天数，按照全量备份文件自动删除策略，会保留最近的一个超过保留天数的全量备份（即下周一的备份会被保留），因此下周三当天删除本周二产生的全量备份。备份周期：默认为全选。全选：选择一周内的每一天。系统每天都会进行自动备份。选择周期：选择一周内的一天或几天。系统会在所选时间进行自动备份。备份周期对应的备份开始时间1小时内，系统会自动触发全量备份。备份所需时间由备份数据量决定，备份数据量越大，备份所需时间越长。实例创建成功后，您可根据业务需要设置自动备份策略。系统将按照您设置的自动备份策略对数据库进行备份。关闭自动备份策略后，自动备份将会立即停止。

云数据库 GEMINIDB 数据备份
云数据库 GEMINIDB-管理映射规则:注意事项

注意事项目前仅支持MySQL到GeminiDB Redis接口Hash类型的转换。新规则的Redis键前缀+键分隔符不能是已有规则的Redis键前缀+键分隔符的子前缀，反之亦然。例如新规则的前缀为 "pre1:"，键分隔符为 "," ，老规则前缀为 "pre1"，分隔符为":"，这种情况不允许创建新规则。如果修改映射规则中MySQL实例的表名后，则需要重新配置映射规则。暂不支持对MySQL实例表的TRUNCATE TABLE、DROP TABLE、DROP DATABASE等语句的识别及同步。暂不支持ENUM、SET、JSON三种数据类型的同步。如果对映射规则中键（Key）字段中的一个或多个字段执行改名、删除等操作时，会使映射规则失效。

云数据库 GEMINIDB 内存加速
云数据库 GEMINIDB-广告频控业务exHash方案:应用场景

应用场景频控场景频控指的是对用户在一定时间内（例如一天、一周、一个月）进行某种操作的次数进行限制，可以控制特定广告或信息在一定时间内在特定平台上的展示次数，以避免过度曝光和广告疲劳，同时优化广告效果和用户体验；对于广告来说，也可以提高广告的效果和转化率。此外，频控还可以避免恶意行为，如刷流量、刷评论、刷点赞等。频控的3个要素包含用户ID、广告ID、触发次数；以用户ID为key，广告ID为field，指定时间内的触发次数为value，恰好构成频控的三要素。先配置好各个广告的指定频控策略，如下图所示即可根据如下的方式来实现频控：图1 频控Hash方案最左边通过Hash类型来实现，通过expire命令设置User_1的过期时间为一天，每推送一次通过hincrby来增加指定广告的推送次数，每次推送指定广告前在一天内的推送次数则可以通过hget获取进行判断，一天后该用户的数据自动过期无需手动清理，这样便可以简单地实现频控。但这个方案的缺点在于对于每个用户（即每个key）只能设置一个过期时间，无法做到例如8小时3次这样指定时间段内的灵活的频控策略。为了做到对每个广告都配置指定时间段内的灵活频控，如中间图所示可以通过将时间戳拼接在value里的方式用Hash类型来实现，但这种方案无疑是增加了业务侧开发的工作量。如最右图所示，支持给field设置过期时间的exHash类型可以很完美地解决Hash类型面对频控场景的缺点。由于Field支持过期时间设置，那么该场景下，平台可以给每个广告都配置不同时间段内的频次要求，假设此时给AD_2配置的频控策略为8小时内2次，那么如图所示在下一次再准备给User_1推送AD_2广告前，先通过exhget User_1 AD_2命令获取到了该值已经是2时，便可以判断出此时根据平台频控策略，不应该再给User_1推送AD_2广告了。而当8小时一过，User_1的AD_2这个field过期后，exhget无法再获取到这个field的信息，则可以继续给User_1推送AD_2广告了。购物车场景双十一期间，相信很多同学购物车里都填满了各种想要清空的宝贝，这里就以购物车场景为例介绍该场景的几种不同Redis类型的实现，并比较这几种实现方案的优缺点。基于String实现购物车功能如图图2所示，基于String可以轻松地实现各个用户的购物车功能，该方案需要将用户ID与商品ID进行拼接作为key，例如User_1#Earphones_1，key对应的value为购物车中用户准备购买的数量，其中可能有部分商品为限时特购，所以有过期时间，为key对应的过期时间。图2 String方案涉及命令如下： incrby User_N#Product_N [Number] # 增加商品数量 set User_N#Product_N [Number] # 设置商品数量 expire User_N#Product_N Time_N # 设置指定用户购物车中指定物品的过期时间 get User_N#Product_N # 获取商品数量 scan 0 match User_N* # 查找所有User_N下的所有商品 del User_N#Product_N # 删除指定用户购物车中的指定商品该方案会存在如下问题：额外拼接增加编、解码开发工作量。某个用户获取自己的购物车清单时还需要通过scan命令前缀匹配扫描所有key，并通过get命令去获取对应的值。想要直接获取清单长度时，仍然需要遍历整个前缀key的数目，方法复杂。存在大量重复的用户名前缀，浪费存储空间。基于Hash实现购物车功能可以根据如图3所示的Hash类型来实现购物车的管理，用户ID作为key，商品ID作为field，value为购物车中对应商品的数量。其中对于部分限时特购的商品，其过期时间通过拼接的方式放到field对应的value里。图3 Hash方案涉及命令如下： hset User_N Product_N [Number#Time_N] # 设置指定用户购物车中指定商品的数量和过期时间 hincrby User_N Product_N [Number] # 增加指定用户购物车中的指定商品数量 hgetUser_N Product_N # 获取指定用户购物车中指定商品的信息 hgetall User_N # 获取指定用户的所有商品信息 hlen User_N # 获取指定用户购物车中的总商品数量 hdel User_N Product_N # 删除指定用户购物车中的指定商品该方案相对于String类型的方案有了不少优化：获取某个用户购物车中的所有商品清单仅需要一个hgetall命令即可。获取某个用户的清单长度时直接hlen获取即可。不存在大量重复的用户名前缀问题。然而该方案仍存在一个明显的缺点，即对于部分限时特购的商品处理起来复杂：对于User_1的Keyboard_1商品，如果要再加一个数量，不能直接使用hincrby，而是需要先hget获取Keyboard_1商品的值并解码，再加上指定的数量再编码后hset对应的值。基于exHash实现购物车功能根据如图4所示的exHash类型来实现购物车的管理，同Hash类型一样，用户ID作为key，商品ID作为field，value为购物车中对应商品的数量。其中对于部分限时特购的商品，由于exHash类型可以为Field设置过期时间，其过期时间可通过hset命令直接设置。图4 exHash方案涉及命令如下： exhset User_N Product_N ex Time_N # 设置指定用户购物车中指定商品的数量和过期时间 exhincrby User_N Product_N [Number] keepttl # 增加指定用户购物车中的指定商品数量,保留原先过期时间exhget User_N Product_N # 获取指定用户购物车中指定商品的信息 exhgetall User_N # 获取指定用户的所有商品信息 exhlen User_N # 获取指定用户购物车中的总商品数量 exhdel User_N Product_N # 删除指定用户购物车中的指定商品 del User_N # 清空指定用户的购物车该方案相对于Hash类型的优化主要体现在可以直接为各field设置过期时间，使业务侧使用起来简单又高效。可以看到exHash类型相关的命令和Hash类型是类似的，使用起来学习成本很低，业务侧改造成本相对也比较低。

云数据库 GEMINIDB 客户案例
云数据库 GEMINIDB-GeminiDB Redis多租户管理解决方案:方案优势

方案优势关于权限控制，开源Redis虽然在新版本有权限控制列表（Acess Control List，简称ACL），但只能设置为只读、读写权限，每个账号还是可以看到所有的DB，这个设计跟数据库多租户的原理背道而驰。例如，业务开发小王应该用DB1，但有天不小心清库了小张的DB0，导致发生生产事故。而GeminiDB Redis的权限隔离就可以解决此问题，如小王被设置为只有DB1的权限而没有DB2的权限，那么即使误操作也不会对DB0的数据产生影响。此外，开源Redis的多租户功能只有单机才可以使用，一旦业务量增加需要集群，多DB功能反而就不可用了，只剩一个DB0。GeminiDB Redis基于自身的集群架构做了多DB增强，支持DB 1000+，同时可创建200+个ACL子账号，满足多种业务场景的需要。表1 开源Redis和GeminiDB Redis所具备的权限管理能力比较 Redis产品是否支持账户读写权限控制是否支持账户权限隔离多DB是否支持集群可支持DB数量开源Redis 支持支持不支持默认16 GeminiDB Redis 支持支持支持默认1000

云数据库 GEMINIDB
云数据库 GEMINIDB-GeminiDB Redis多租户管理解决方案:应用场景

应用场景多租户是数据库用户的常用功能。例如，企业中有两个业务部门A和B，都需要使用Redis来存储各自的数据，如果不使用多租户权限功能，那么A和B的数据就会混在一起，这样就会存在数据泄露和误操作的风险。使用了多租户管理功能后，就可以将A和B的数据分别存储在不同的Redis实例或DB中，并且对这些实例或DB进行权限控制，从而保障数据的安全性和可靠性。在数据库领域，多租户技术往往有一些标准属性：比如读写权限控制、跨DB鉴权隔离等。而GeminiDB Redis实例就具备完善的多租户管理技术，实现了读写权限控制和数据库（DB）隔离这两大特性的完美融合。

云数据库 GEMINIDB
云数据库 GEMINIDB-美柚一站式迁移华为云数据库案例:业务痛点

业务痛点美柚日活跃用户数量破千万，并保持持续上升趋势。然而，在快速发展的过程中，美柚的业务拓展却因IT架构和数据库频受限制。美柚原本采用自建数据库的方式，在女性健康、社区、电商等业务中，根据不同业务类型，使用MySQL、MongoDB、Codis（分布式Redis解决方案）等开源服务。但这些自建组件的稳定性差，维护难度高且维护工作量大，导致美柚急需对数据库进行改造和迁移。云数据库 GeminiDB团队通过对美柚实际业务场景进行深入调研，精准识别了现有业务迁移过程中的问题，主要体现在以下四个方面。美柚使用的部分开源组件版本较低，升级操作复杂且伴随较高风险。同时，开源服务稳定性差，缺乏必要的问题修复或规避能力。开源服务自动化运维能力差、备份不及时、缺乏增量备份机制，极大地增加了数据丢失的风险。系统在面对故障时，无法自动恢复，可用性不足，导致业务恢复时间长。开源数据库服务在资源扩容和缩容能力方面，具有耗时长、稳定性差、成本高昂等缺点。

云数据库 GEMINIDB
云数据库 GEMINIDB-美柚一站式迁移华为云数据库案例:解决方案

解决方案一站式迁移解决方案，保障客户多种类型数据库平滑迁移云数据库团队根据美柚的业务特性，定制了基于“GeminiDB Redis接口+RDS+DDS”的数据库迁移方案。DRS提供多种数据库类型全量和增量的平滑迁移能力，支持美柚不同类型业务搬迁。DRS迁移过程中会显示当前迁移的对象类型、迁移进度、剩余时间评估等，可以帮助用户做好布置规划，避开业务高峰期，业务分钟级中断，中断过程中进行数据一致性校验，在保证数据零丢失的基础上，最大程度减少对业务的影响。智能运维，助力客户轻松、便捷管理数据库美柚的Codis版本比较低，在版本升级过程中需要投入大量的DBA，且会出现业务中断较长时间的情况。云数据库 GeminiDB 100%兼容Redis 6.2版本，具备稳定的低时延和诸多增强功能的优势，比如，支持版本的一键升级功能，可以确保美柚在版本升级过程中业务稳定、流畅地运行。同时，相对美柚原有自建数据库，华为云数据库具有SQL/Key限流等运维能力，防止异常情况下的流量突增。具有紧急结束会话能力，便于紧急运维操作。支持秒级监控能力，避免业务受到影响。美柚可以根据业务需要配置指标告警及事件告警，在收到系统触发的告警通知后，及时介入处理，轻松实现数据库便捷管理，并降低运维成本。三副本存储策略+多节点跨AZ部署+自动故障修复，让数据库稳定可靠面对故障处理能力不足带来的挑战，GeminiDB Redis实例的独立资源部署、数据三副本存储策略和多节点跨AZ部署方案，保证了美柚数据库的稳定性和数据的一致性、高可靠性。GeminiDB Redis提供的大Key诊断功能，帮助DBA第一时间发现业务高危风险，及时实施整改，避免风险扩大。高压缩比节约存储成本，精准控制资源使用在美柚的推荐业务中，核心特征库选用GeminiDB Redis接口，借助其内存引擎稳定的性能表现，实现在线系统业务24小时高效运行，给用户带来最佳浏览体验。GeminiDB Redis接口不仅具备独有的增强能力（exHash）和精细化频次控制，让用户不会刷到同一片信息流，大幅提升使用体验。而且凭借强大的数据压缩能力，降低了美柚业务的TB级数据存储成本。云数据库团队严格把控初始资源规格配置成本，利用GeminiDB Redis接口的存储容量扩容/缩容、添加/删除节点等功能，可以根据业务实际需求进行操作，帮助美柚精准控制资源使用成本。同时，存储资源的扩缩容都是秒级闪断，减小对业务的影响。

云数据库 GEMINIDB
云数据库 GEMINIDB-GeminiDB Redis广告投放业务RTA解决方案:方案优势

方案优势 FastLoad极速数据导入，效率提升5-10倍传统数据库只能通过标准协议逐条写入数据，先经过计算层复杂结算，再写入存储层。因此，大数据平台定期导入的数百GB乃至数TB的画像数据，通常需要数小时或者数天，且对在线业务影响比较大。 GeminiDB Redis提供的FastLoad企业级特性，依托RTA业务场景大数据平台的高并发处理能力和自身存储引擎的数据编排能力，将海量数据通过专属高速持久化通道直接传入存储引擎，数据导入速度提升5-10倍，并降低对在线业务的影响。提供百万级并发和亚毫秒级延迟，无惧业务洪峰云数据库 GeminiDB Redis采用存储计算分离架构，通过分布式高性能存储池实现三副本、强一致的数据存储，所有节点高效读/写访问，支持算力水平和垂直扩展，能够轻松应对业务规模和数据量的爆炸式增长。通过采用多线程架构和高性能存储池，配合内存数据结构和访问算法的深度优化，GeminiDB Redis能够实现亚毫秒级的数据请求响应。这种超低时延的性能，对需要实时数据处理和分析的应用场景，如在线游戏、金融科技、广告系统和实时推荐系统，提供了强大的数据支持。因此，GeminiDB Redis成为处理大规模实时交互和高频交易等场景的理想选择。根据现网的案例经验，在百万+QPS流量下，GeminiDB可稳定保持平均时延1ms，p99时延2ms。高效数据压缩存储，效率与成本并行 GeminiDB Redis使用“逻辑数据+块数据”双重压缩机制，在不影响性能的前提下，大幅度降低数据的存储占用。同时，采用存储计算分离架构，将算力和数据存储解耦，支持独立弹性扩展。可以使企业以更低的成本存储更多的数据，极大地优化资源利用效率，降低整体的使用成本。根据现网案例经验，GeminiDB Redis的数据压缩比通常为4:1，即实际12TB数据，在GeminiDB Redis中仅占用3TB左右的存储空间。

云数据库 GEMINIDB
云数据库 GEMINIDB-GeminiDB Redis广告投放业务RTA解决方案:应用场景

应用场景广告投放是企业宣传营销不可或缺的一部分。尤其是在新媒体发展白热化的当下，不仅广告渠道多样化，投放模式也更细节化和个性化。随着客户广告投放产出比意识的加强，以短视频平台为例，在投放目标选择上，广告主通常需要通过配置年龄、性别、学历等规则，才能将广告投放给满足标签的受众。广告投放中这一灵活性不足的限制，常常会让广告主难以抉择，导致投放效果不佳。广告主企业往往每年需花费数亿甚至数十亿广告费，却依然难以准确触达目标用户，造成大量资金浪费。那该如何解决“让广告主对每一条广告请求，有投递或者拒绝的自主权”这一问题，广告RTA应运而生！ RTA（Realtime API），是一种用于满足广告主实时、个性化的投放需求的技术手段。

云数据库 GEMINIDB
云数据库 GEMINIDB-GeminiDB Redis广告投放业务RTA解决方案:业务挑战

业务挑战广告主的RTA系统，是从核心的画像数据库读取数据并进行投放决策的，数据越新，投放效果越好。因此，大数据平台生成的最新数据，需要及时写入画像数据库。综合来看，广告RTA业务面临高并发、超低时延、超大数据量等实际特性需求。因此，对核心画像数据库有如下诉求：海量数据快速导入，确保决策精准性需要定期将成百GB甚至数TB全量画像数据导入画像数据库；全量数据导入越快，模型越精准，广告投放效果越好。承载高并发访问 RTA系统要承接大量的实时竞价请求。以电商、金融客户的RTA系统为例，日常数据库QPS在几十万到数百万之间。保持稳定的低时延媒体侧要求广告主在40-100ms内返回决策结果，数据库需要在个位数毫秒内执行完请求。降低业务成本为了追求极致的性能体验，RTA业务通常使用开源自建Redis，然而TB级别数据存储成本非常昂贵，成本也是广告主选型的重要考虑因素。在广告RTA中，通常选用以下数据库作为画像数据库： MySQL：难以满足数十万至百万QPS并发和低时延的要求。 MongoDB/Hbase：可以存储TB级数据，成本便宜，但无法满足稳定低时延诉求，超时率高，容易导致停投，影响商业利益。内存数据库：能提供高并发、低时延极致性能，如开源自建Redis，是业界选用比较多的方案。但存在着稳定性差，数据丢失等风险。对于TB级用户画像数据，存在导入速断慢和成本高的痛点。而云数据库GeminiDB Redis接口完全具备稳定低时延、高性价比、FastLoad离线数据极速导入等核心能力。

云数据库 GEMINIDB
云数据库 GEMINIDB-某金融科技企业广告RTA业务实践:云数据库 GeminiDB Redis解决方案

云数据库 GeminiDB Redis解决方案云数据库 GeminiDB Redis是基于自主研发计算存储分离架构的多模NoSQL数据库（如图1所示），将计算节点与数据存储解耦，解决自建开源Redis的痛点问题，有效帮助客户降本增效。图1 GeminiDB Redis 近年来，GeminiDB Redis产品团队基于开源生态额外做了诸多的特性增强，提供诸多企业级特性，如：解决了fork问题使性能更平滑、支持秒级自动无感扩容、指定时间点原地PITR回档、跨Region容灾、增强的Hash类型（exHash）、离线快速大批量数据导入（FastLoad）等，在帮助用户解决业务痛点的同时，不断提高业务使用效率和体验。针对该企业在开源Redis使用中遇到的几个痛点问题，GeminiDB Redis接口提供了完善的配套解决方案： FastLoad企业级特性，提供离线海量数据导入的极致体验传统Redis只能通过标准协议导入，导入速度慢；且在线业务运行期间进行批量数据导入时，由于单线程架构，会出现慢时延、分片不均、甚至OOM等情况，影响在线业务。 GeminiDB Redis接口提供FastLoad企业级特性，依托RTA业务场景大数据平台的高并发处理能力和自身存储引擎的数据编排能力，将海量数据高并发转换成数据库底层持久化文件。同时避开离散数据写入长链路，通过专属高速持久化通道直接将持久化文件导入存储引擎，实现数据的高效导入，并降低对在线业务的影响。存储计算分离架构，算力、存储独立扩展；支持自动扩容，对业务零干扰；强数据压缩比，节约存储成本 GeminiDB Redis采用业界领先的存储计算分离架构，将算力与数据存储解耦，计算节点、数据存储可独立扩容，扩容体验在行业里是遥遥领先的。 GeminiDB Redis支持GB粒度的存储扩容能力，同时支持全自动扩容，无需人工干预，且扩容过程平滑无感，秒级完成，优化运维体验。 GeminiDB Redis同时提供强数据压缩能力，采用逻辑+物理块压缩技术，数据压缩比可达30%-50%，能够有效降低存储成本开销。独享容器部署，分片带宽充足开源Redis的部署往往是多个租户共用一个容器，为降低租户间干扰，不得不对各个租户进行流控限制。分片的流控会产生“木桶效应”，只有采用独立容器部署Redis才能解决。 GeminiDB Redis接口每个分片都采用独立容器部署，分片带宽不受额外限制，独立容器带宽全部提供给业务程序使用。

云数据库 GEMINIDB
云数据库 GEMINIDB-某金融科技企业广告RTA业务实践:业务痛点

业务痛点 RTA业务系统的海量数据、超高并发、低时延等特点，对存储海量用户特征数据的特征数据库带来了巨大的挑战，特征数据库要在低成本的基础上，提供高稳定性、高性能的能力，满足业务诉求。该金融科技企业RTA业务在上云前使用开源Redis集群作为特征数据库，近年来随着业务增长，其自建开源Redis集群在业务使用中遇到几个明显的痛点：海量用户特征数据，导入效率低。数据持续增长，开源Redis成本逐渐增加；扩展性差，升配期间影响业务。开源Redis经常被流控，稳定性差，影响在线业务。

云数据库 GEMINIDB
云数据库 GEMINIDB-某金融科技企业广告RTA业务实践:业务场景

业务场景某金融科技企业基于云数据库 GeminiDB Redis自主研发的RTA定向获客系统，利用海量数据打造高精确的用户特征画像，最大化地利用广告平台，实现精准的定向广告投放，提高转化率。其业务场景可简要分为以下几个步骤：大数据平台根据自身分析数据及对接的多个第三方数据服务商进行综合建模，匹配每个活跃用户的多维度模型，分析得到目标用户的高精细融合特征数据画像，并将海量特征画像数据存入云数据库 GeminiDB Redis中，以提供在线业务的高并发访问。 RTA业务平台对接多个流量巨头媒体推广平台。用户浏览社交媒体时，各媒体推广平台发起广告请求，RTA业务与GeminiDB实时交互，获取目标用户的特征画像信息，基于投放策略分析并竞价返回。媒体推广平台基于各广告主RTA业务平台返回的竞价结果，选择合适广告并精准投放给目标人群，实现广告的定向精准投放。该企业RTA业务平台与媒体推广平台深度合作，通过对媒体推广平台的用户特征数据，与GeminiDB Redis存储的自研分析数据进行匹配分析，提高定向投放和筛选能力。

云数据库 GEMINIDB
云数据库 GEMINIDB-金智教育业务数字化降本增效案例:业务痛点

业务痛点金智教育有很多核心业务系统，其中大量使用了Redis。近年来随着业务量持续增长，其原先采用的自建开源Redis在使用上遇到几个明显的痛点：开源Redis主备倒换引起“丢Key”，只能人工补数据由于开源Redis主备采用的是异步复制，一旦发生故障倒换，将会丢失大量数据。在金智教育业务中，APP登录验证会使用Redis存储Token，一旦主从切换，会导致大量用户重复验证登录，这也是开源Redis常见的问题。此外，在学生报表业务中，数据的完整性非常重要。一旦发生数据丢失，系统中有一部分学生的信息将无法查看，此时不得不通过人工来补录数据，非常耗时。开源Redis分片经常“被流控”，影响业务业务访问模型往往会存在一些热点，开源Redis集群虽然整体带宽高，但由于每个分片带宽小，因此经常触发分片流控，导致业务受损。在金智教育的业务中，流控触发就意味着业务受损，因此非常需要一款不流控的Redis服务。数据持续增长，开源Redis升级配置费用高，且影响业务在海量数据处理的场景下，需要Redis长期保存数据。开源Redis扩容操作意味着加分片，耗时久而且影响业务。此外，随着数据增长，开源Redis的使用成本也会随之增加，会给公司带来较高的成本开销，因此金智教育急需要一款成本可控的KV数据库。

云数据库 GEMINIDB 客户案例
云数据库 GEMINIDB-金智教育业务数字化降本增效案例:云数据库 GeminiDB Redis解决方案

云数据库 GeminiDB Redis解决方案云数据 GeminiDB Redis的设计目的，就是为了解决开源Redis的痛点问题，有效实现降本增效。近年来，GeminiDB Redis产品团队基于开源生态额外做了诸多的特性增强，例如：解决了fork问题使性能更平滑、支持自动无感扩容（秒级完成）、指定时间点原地PITR回档、跨Region容灾等等。针对金智教育在Redis使用中遇到的几大核心痛点，GeminiDB Redis接口提供了完善的配套解决方法：数据可靠性显著提升试想在10000 QPS的写入流量下，开源Redis即使配置秒粒度的AOF下刷（影响性能，往往不适合在线上环境开启），主备倒换也会引起10000条业务数据的丢失，损失很大。因此，开源Redis的“丢数据”是先天的痛点，并不适合用在数据重要的业务场景下。 GeminiDB Redis存储数据的可靠性非常高，用户数据在GeminiDB Redis默认存储3个副本，成本上仅按1个副本计费，不会带来额外费用。计算节点使用预写日志WAL实现了命令级的可靠存储，即使分片发生故障倒换，由于有存储池保障全量数据的可靠性，也能保障业务数据的完整和安全。切换到GeminiDB Redis后，金智教育线上业务的稳定性得到了大幅度提升，而不再需要消耗人工精力去补数据了。采用独享容器部署，分片带宽充足，不担心流控开源Redis的部署往往是多租户共用一个容器，因此不得不做流控，否则会发生租户间相互干扰的情况。分片的流控会时常发生，这会产生“木桶效应”，只有采用独立容器部署Redis才能解决。 GeminiDB Redis的每个分片都采用独立容器，带宽不做额外限流，分片（独立容器）带宽全部提供给业务程序使用，即使业务访问存在一定倾斜，也不担心被某个分片流控。支持自动扩容，且对业务零干扰；强数据压缩比，存数据成本节约30%+ GeminiDB Redis的扩容体验在行业里是领先的，目前已经支持全自动扩容，无需人工干预，且扩容平滑无感，秒级完成。对业务来说，连接不会被中断，也不会引起时延抖动，随着业务增长，扩容可以放心交给服务端自动化完成。此外，金智教育在迁移数据时，发现100GB的数据迁入到GeminiDB Redis只占用了不到50GB的空间，从长远来看存储成本非常有优势。这是由于GeminiDB Redis通过高效压缩技术对数据进行了逻辑+物理块压缩，能够有效降低存储开销。

云数据库 GEMINIDB 客户案例