请求示例 URI样例 PUT https://gaussdb-nosql.cn-north-4.myhuaweicloud.com/v3.1/375d8d8fad1f43039e23d3b6c0f60a19/configurations/e02e76567ae04662a2753492b77f965bpr06 修改参数模板参数 请求体参数中，至少有一个非空，否则会下发失败。 { "name" : "configuration_test", "description" : "configuration_test", "values" : { "concurrent_reads" : "64" } }

请求示例 URI样例 PUT https://gaussdb-nosql.cn-north-4.myhuaweicloud.com/v3/375d8d8fad1f43039e23d3b6c0f60a19/configurations/e02e76567ae04662a2753492b77f965bpr06 修改参数模板参数 请求体参数中，至少有一个非空，否则会下发失败。 { "name" : "configuration_test", "description" : "configuration_test", "values" : { "concurrent_reads" : "64" } }

云数据库 GeminiDB授权项说明 表1 实例管理 权限 对应API接口 授权项(Action) IAM 项目(Project) 企业项目(Enterprise Project) 创建数据库实例 POST /v3/{project_id}/instances nosql:instance:create √ √ 删除数据库实例 DELETE /v3/{project_id}/instances/{instance_id} nosql:instance:delete √ √ 查询数据库实例列表 GET /v3/{project_id}/instances?id={id}&name={name}&mode={mode}&datastore_type={datastore_type}&vpc_id={vpc_id}&subnet_id={subnet_id}&offset={offset}&limit={limit} nosql:instance:list √ √ 扩容实例存储容量 POST /v3/{project_id}/instances/{instance_id}/extend-volume nosql:instance:modifyStorageSize √ √ 扩容集群实例的节点数量 POST /v3/{project_id}/instances/{instance_id}/enlarge-node nosql:instance:extendNode √ √ 缩容集群实例的节点数量 POST /v3/{project_id}/instances/{instance_id}/reduce-node nosql:instance:reduceNode √ √ 变更实例规格 PUT /v3/{project_id}/instances/{instance_id}/resize nosql:instance:modifySpecification √ √ 修改实例管理员密码 PUT /v3/{project_id}/instances/{instance_id}/password nosql:instance:modifyPasswd √ √ 修改实例名称 PUT /v3/{project_id}/instances/{instance_id}/name nosql:instance:rename √ √ 变更实例安全组 PUT /v3/{project_id}/instances/{instance_id}/security-group nosql:instance:modifySecurityGroup √ √ 数据库补丁升级 POST /v3/{project_id}/instances/{instance_id}/db-upgrade nosql:instance:upgradeDatabaseVersion √ √ 批量数据库补丁升级 /v3/{projectId}/instances/db-upgrade nosql:instance:batchUpgradeDatabaseVersion √ √ 创建冷数据存储 POST /v3/{project_id}/instances/{instance_id}/cold-volume nosql:instance:modifyStorageSize √ √ 扩容冷数据存储 PUT /v3/{project_id}/instances/{instance_id}/cold-volume nosql:instance:modifyStorageSize √ √ 绑定/解绑弹性公网IP POST /v3/{project_id}/instances/{instance_id}/nodes/{node_id}/public-ip nosql:instance:bindPublicIp √ √ 切换SSL开关 POST /v3/{project_id}/instances/{instance_id}/ssl-option nosql:instance:switchSSL √ √ 重启数据库实例 POST /v3/{project_id}/instances/{instance_id}/restart nosql:instance:restart √ √ 设置磁盘自动扩容策略 PUT /v3/{project_id}/instances/disk-auto-expansion nosql:instance:modifyStorageSize √ √ 修改高危命令 PUT /v3/{projectId}/instances/{instanceId}/high-risk-commands nosql:instances:modifyHighRiskCommands √ √ 设置实例可维护时间段 PUT /v3/{project_id}/instances/{instance_id}/maintenance-window nosql:instance:modifyMaintenanceWindow √ √ 获取GeminiDB Redis的免密配置 Get /v3/{project_id}/instances/{instance_id}/passwordless-config nosql:instance:getPasswordlessConfig √ √ 支持修改GeminiDB Redis的免密配置 PUT /v3/{project_id}/instances/{instance_id}/passwordless-config nosql:instance:setPasswordlessConfig √ √ 表2 备份与恢复 权限 对应API接口 授权项(Action) IAM项目(Project) 企业项目(Enterprise Project) 查询自动备份策略 GET /v3.1/{project_id}/instances/{instance_id}/backups/policy nosql:backup:list √ √ 设置自动备份策略 PUT /v3/{project_id}/instances/{instance_id}/backups/policy nosql:instance:modifyBackupPolicy √ √ 查询可恢复的实例列表 GET /v3/{project_id}/backups/{backup_id}/restorable-instances nosql:instance:list √ √ 查询实例可恢复的时间段 GET /v3/{project_id}/instances/{instance_id}/backups/restorable-time-periods nosql:backup:list √ √ 创建手动备份 POST /v3/{project_id}/instances/{instance_id}/backups nosql:backup:create √ √ 删除手动备份 DELETE /v3/{project_id}/backups/{backup_id} nosql:backup:delete √ √ 恢复到已有实例 POST /v3/{project_id}/instances/{instance_id}/recovery nosql:backup:refreshInstanceFromBacku √ √ 表3 参数模板管理 权限 对应API接口 授权项(Action) IAM项目(Project) 企业项目(Enterprise Project) 获取参数模板列表 GET /v3/{project_id}/configurations nosql:param:list √ √ 创建参数模板 POST /v3/{project_id}/configurations nosql:param:create √ √ 修改参数模板的参数 PUT /v3.1/{project_id}/instances/{instance_id}/configurations nosql:param:modify √ √ 应用参数模板 PUT /v3.1/{project_id}/configurations/{config_id}/apply nosql:instance:modifyParameter √ √ 修改指定实例的参数 PUT /v3/{project_id}/instances/{instance_id}/configurations nosql:instance:modifyParameter √ √ 获取指定实例的参数 GET /v3/{project_id}/instances/{instance_id}/configurations nosql:param:list √ √ 获取指定参数模板的参数 GET /v3/{project_id}/configurations/{config_id} nosql:param:list √ √ 删除参数模板 DELETE /v3/{project_id}/configurations/{config_id} nosql:param:delete √ √ 查询参数模板可应用的实例列表 GET /v3/{project_id}/configurations/{config_id}/applicable-instances nosql:instance:list √ √ 查询实例参数的修改历史 GET /v3/{project_id}/instances/{instance_id}/configuration-histories nosql:param:list √ √ 查询参数模板应用历史 GET /v3/{project_id}/configurations/{config_id}/applied-histories nosql:param:list √ √ 表4 标签管理 权限 对应API接口 授权项(Action) IAM项目(Project) 企业项目(Enterprise Project) 查询资源实例 POST /v3/{project_id}/instances/resource_instances/action nosql:instance:list nosql:tag:list √ √ 批量添加或删除资源标签 POST /v3/{project_id}/instances/{instance_id}/tags/action nosql:instance:tag √ √ 查询资源标签 GET /v3/{project_id}/instances/{instance_id}/tags nosql:instance:list nosql:tag:list √ √ 表5 日志管理 权限 对应API接口 授权项(Action) IAM项目(Project) 企业项目(Enterprise Project) 查询数据库慢日志 GET /v3/{project_id}/instances/{instance_id}/slowlog?start_date={start_date}&end_date={end_date} nosql:instance:list √ √ 表6 配额管理 权限 对应API接口 授权项(Action) IAM项目(Project) 企业项目(Enterprise Project) 查询配额 GET /v3/{project_id}/quotas nosql:instance:list √ √ 表7 容灾管理 权限 对应API接口 授权项(Action) IAM项目(Project) 企业项目(Enterprise Project) 查询实例可搭建双活关系的Region GET /v3/{project_id}/instances/{instance_id}/disaster-recovery/regions nosql:instance:list √ √ 表8 任务管理 权限 对应API接口 授权项(Action) IAM项目(Project) 企业项目(Enterprise Project) 查询实例可维护时间段 GET /v3/{project_id}/instances/{instance_id}/ops-window nosql:instance:maintenanceWindow √ √ 取消定时任务 DELETE /v3/{project_id}/scheduled-jobs/{job_id} nosql:instance:cancleScheduleJob √ √ 查询定时任务列表 GET /v3/{projectId}/scheduled-jobs nosql:task:list √ √ “√”表示支持，“x”表示暂不支持。 父主题： 权限策略和授权项

请求示例 URI样例 PUT https://gaussdb-nosql.cn-north-7.myhuaweicloud.com/v3/054e292c9880d4992f02c0196d3ea468/instances/392850e624504e1490901d50b585a60din06/configurations 修改指定实例的参数 { "values" : { "request_timeout_in_ms" : "10000" } }

方案优势 关于权限控制，开源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

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

企业级特性介绍 GeminiDB Redis接口基于云原生分布式架构，实现了计算与存储分离，完全兼容社区版Redis7.0、6.2(包含6.2.x)、5.0及以下版本，提供了更多的企业级特性。 资源独享，分片不限流 计算节点部署在独享容器，租户隔离，稳定性高。面对高并发流量，节点不被限流。 内置独享型负载均衡器，转发性能和稳定性更高。 计算节点支持绑定公网IP，方便用户迁移上云和远程调试。 秒级弹性伸缩，轻松应对业务峰谷 支持存储和计算各自独立伸缩。单实例最大支持千万级QPS和36TB容量。 数据量增长场景，容量的扩容只需一键即可秒级完成，业务应用无感知。 业务量突增的场景（比如游戏、电商的活动期间，临时有更高的QPS诉求），可通过增加节点和提升规格两种方式进行扩容，后续可轻松缩容，对业务的影响仅为秒级连接重连。 一库替代多库，简化业务架构 基于高性能存储池，实例自动加载高频访问的热数据在计算节点的内存中，内部自动完成冷热数据交换，业务优先从内存中读取热数据，兼顾数据的高可靠和低时延。 GeminiDB Redis接口适合存储持续增长的重要业务数据（比如游戏玩家数据、用户画像、行为日志、文章资讯等），相比使用Redis+MySQL的架构场景，架构更简洁、数据存储更可靠，同时还具备更高的综合性能和性价比。 支持3AZ部署 3AZ实例支持将计算和存储资源都会均匀分布在3个可用区，部署规则严格遵循反亲和组，实例具备超高可靠性。 支持故障节点秒级接管，在独有的存算分离架构下，即使发生N-1节点同时故障的极端场景，依然可以秒级恢复业务访问，超高可用。 账号管理，支持DB级权限控制 支持使用65536个DB，支持创建200个子账号。 用户不但可以为子账号设置只读或读写权限，还可为子账号配置可访问的DB列表，从根本上避免多租户之间数据误操作风险。 支持为Hash key的Field单独设置过期时间 开源Redis只支持为Hash key整体设置过期时间。GeminiDB Redis接口新增了一组hash命令，这一新功能让用户可以为一个Hash key中的指定Field单独设置过期时间，将业务层面的淘汰逻辑下沉到数据库中实施，简化业务架构。 exHash最佳实践详见GeminiDB Redis广告频控业务exHash方案。 数据强一致，不会发生脏读 开源Redis采用异步复制，数据副本间弱一致。在计数器、限流器、分布式锁等常见业务场景中，会带来脏读隐患，可能会导致业务逻辑错乱。 GeminiDB Redis接口将数据副本下沉到高性能存储池中，一旦写入成功，将保障数据3副本强一致存储，后续业务访问不会发生脏读。 增强版事务功能 支持事务功能，即MULTI/EXEC。相比开源Redis的伪事务，GeminiDB Redis接口实现了真事务，即支持ACID，在底层实现了对回滚的支持，满足了事务的原子性。 增强版前缀扫描 当用户对实例执行Scan类扫描命令时，如指定前缀匹配（match prefix*），则此时的扫描性能将远远超越开源Redis。这是因为GeminiDB Redis接口将该场景下达命令复杂度优化到了O(logN + M)，其中N是整体数据量，M是匹配的数据量。而开源Redis的扫描复杂度则是更慢的O(N)。 父主题： 产品介绍

方案优势 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左右的存储空间。

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

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

Redis-py import redis from redis.retry import Retry from redis.exceptions import ConnectionError from redis.backoff import ExponentialBackoff from redis.client import Redis from redis.exceptions import ( BusyLoadingError, ConnectionError, TimeoutError ) # Run 3 retries with exponential backoff strategy retry_strategy = Retry(ExponentialBackoff(), 3) # Redis client with retries client = redis.Redis( host = 'localhost', port = 6379, retry = retry_strategy, # Retry on custom errors retry_on_error = [BusyLoadingError, ConnectionError, TimeoutError], # Retry on timeout retry_on_timeout = True ) try: client.ping() print("Connected to Redis!") except ConnectionError: print("Failed to connect to Redis after retries.") try: client.set('key', 'value') print("Set key and value success!") except ConnectionError: print("Failed to set key after retries.")

Go-redis package main import ( "context" "fmt" "time" "github.com/redis/go-redis/v9" ) var ctx = context.Background() func main() { client := redis.NewClient(&redis.Options{ Addr: "localhost:6379", Password: "", // no password set DB: 0, // use default DB MaxRetries: 3, // set max retry times MinRetryBackoff: time.Duration(1) * time.Second, // set retry interval MaxRetryBackoff: time.Duration(2) * time.Second, // set retry interval }) // Execute command err := client.Set(ctx, "key", "value", 0).Err() if err != nil { panic(err) } // Test pong, err := client.Ping(ctx).Result() if err != nil { fmt.Println("Failed:", err) return } fmt.Println("Success:", pong) }

应用场景 频控场景 频控指的是对用户在一定时间内（例如一天、一周、一个月）进行某种操作的次数进行限制，可以控制特定广告或信息在一定时间内在特定平台上的展示次数，以避免过度曝光和广告疲劳，同时优化广告效果和用户体验；对于广告来说，也可以提高广告的效果和转化率。此外，频控还可以避免恶意行为，如刷流量、刷评论、刷点赞等。 频控的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类型是类似的，使用起来学习成本很低，业务侧改造成本相对也比较低。

方案总览 PITR（Point-in-Time Recovery），是指数据库的“时间点恢复”功能。它是一种数据库恢复技术，通常用于恢复误删除的数据或者误操作导致损坏的数据，将其恢复到一个指定时间点的数据状态。 以游戏场景为例，在游戏运行期间，有玩家利用游戏漏洞复制装备、货币，使游戏公平性遭到破坏。传统数据库备份频率一般是一天全备一次，备份间隔即一整天，不仅恢复时间长、时间粒度大，甚至无法恢复到想要时间点等。而GeminiDB Redis接口新增的PITR特性能够让游戏数据快速回档，可根据客户自定的备份粒度，最低支持5分钟粒度，自行选择需要恢复的时间点，实现数据的快速恢复。

方案优势 GeminiDB Redis接口的PITR技术执行数据快照业务无感，通常可在5分钟以内恢复到指定时间点，尤其是在业务异常时可以快速回退，降低损失，有效解决传统备份方案时间长、可恢复时间粒度大等痛点问题。因此，GeminiDB Redis接口在游戏、金融等行业有着广泛应用。 备份任务无感，业务更平稳 GeminiDB Redis接口的PITR功能不涉及数据的复制，备份任务业务无感知，不影响数据访问，让客户业务更加平稳。 GeminiDB Redis接口快照原理是通过记录文件系统的状态来实现的，是瞬时生成，而不是通过复制文件本身来实现的。快照存储当前时刻的底层数据的元数据信息，比如数据块信息、寻址信息等，形成快照。因此，当打数据快照时，业务可以继续运行，而不会受到任何影响。 支持分钟级快速恢复，恢复时长与数据大小无关 PITR数据快照文件可以在本地保存，不用上传到冷存储介质，因此，不涉及数据的复制搬迁，还可支持随时数据恢复。 PITR恢复，数据恢复时长与数据大小无关，能快速恢复数百GB数据，通常可在5分钟以内恢复数据，保证客户业务可靠性。除此以外，PITR还可多次前后恢复，恢复到指定时间点后，既可向前，也可向后，让客户使用更省心。 比开源Redis数据备份性能更优 开源Redis使用多进程写时复制机制来实现快照的持久化。在持久化过程中，调用fork()产生一个子进程，fork()会阻塞Redis长达数百毫秒，对业务产生抖动。fork()的写时复制技术（COW）会造成内存过度使用，如果fork()期间产生大量的写操作，会导致内存严重浪费甚至OOM，通常内存利用率不足50%。而GeminiDB Redis接口的PITR特性不涉及数据的复制搬迁，因此对业务基本无影响，且具有快照速度快、数据稳定、安全等特点。