阿里云数据库Redis具有数据闪回功能，可以按时间点恢复数据。开启数据闪回功能后，在备份文件的保存期内，您可以恢复指定时间点的Redis数据，从而避免误操作带来的数据损失，或者在频繁回档的业务场景快速完成数据切换。

在传统关系型数据库中（如Oracle）提供了数据闪回功能，帮助客户完成数据的按时间恢复。而在主流的高速缓存产品Redis、Memcached上却鲜有类似的功能，原因主要是考虑到作为缓存产品，其中的数据可以丢失，而通过背后配备的持久化、事务性的关系型数据库可以对缓存进行重新加载。但是，随着大量客户对于低延迟的业务应用性能要求不断的提高，对于一些对延迟要求极高的场景下，例如游戏行业，越来越多的客户选择化简架构，将Redis直接作为内存数据库来使用，这便对Redis的数据安全可恢复提出了更大的挑战。阿里云Redis作为行业内的领军产品，拥有国内强大的Redis产品系列，在托管社区Redis版本的同时大力发展自主研发、兼容Redis协议增强型键值存储产品Tair（阿里云Redis企业版）。

“更安全”是阿里云Redis向广大客户提供服务的重要部分，阿里云在Tair中的性能增强版上特别推出了数据闪回功能，帮助客户实现在其指定时间点上恢复指定Redis实例数据的能力，提前为客户可能出现的风险准备好一剂“后悔药”。功能示意如下图所示：

使用这个能够帮助用户穿越数据变迁的黑科技只需简单几步。

• 开通阿里云Redis企业版性能增强版实例
• 开启数据闪回功能
• 正常读写Redis数据库
• 一旦发生即时数据恢复要求，选择对应实例和欲恢复的时间点，产生新实例
• 切换应用连接的实例地址

下面以一个简单的示例演示：
首先，我们先对一个阿里云Tair实例写入一些数据，写入脚本如下：

% cat preparerepldata.sh

#!/bin/bash

echo “started at: `date +%m%d%H%M%S`”

for i in `seq -f “%010g” 1 $1`

do

namerand=$[ $RANDOM % 3 ]

timerand=`date +%m%d%H%M%S`

nationrand=$[ $RANDOM % 3 ]

redis-cli -h   r-t4nq2viog3z4rshoxxpd.redis.singapore.rds.aliyuncs.com -a ‘gnuhpc:Pa$$w0rd’   hsetuserprofilefoo$timerand $namerand

    sleep 0.75 #consider the   latency for connection establish

done

echo “ended at:   `date +%m%d%H%M%S`”

我们运行上述脚本以大约一秒的速率写入带时间戳的KV到一个叫做userprofile的hash结构中，一共写入120个Key，代表业务写入。

% bash preparerepldata.sh   120

OK

OK

…

% redis-cli -h hosts -a ‘username:password’   hkeysuserprofile | wc -l

     120

% redis-cli -h hosts -a ‘username:password’   hkeysuserprofile | sort -n

foo0803202709

…

foo0803202909

如命令执行所示，我们是在08月03日20：27：09 –08月03日 20：29：09 写入了120条数据。

随后在业务运行中，发现08月03日20：28：10之后，上述业务运行中发生数据风险，我们需要将新创建一个数据库，将原数据库在此时间点之前的数据恢复到这个新的数据库实例中。

我们到阿里云Redis控制台的备份恢复功能，选择数据闪回功能，点击“马上闪回”按钮，选择克隆源类型是“过去时间点”，然后选择要恢复的时间点：

新建的实例就是我们要将指定时间点数据恢复到的目标实例，这里值得一提的数据闪回只要求目标实例容量大于等于源实例，而架构则可以与源实例不同，也就是说用户可以自由选择目标实例为标准主从、集群或者读写分离架构的任何一个。

点击支付后等待片刻后实例创建完毕并完成数据恢复。

我们连接新创建的实例，看看究竟数据恢复的情况如何？

% redis-cli -h hosts -a ‘username:password’   hkeysuserprofile | wc -l

62

% redis-cli -h hosts -a ‘username:password’   hkeysuserprofile | sort -n

foo0803202709

…

foo0803202810

可以看到，我们已经成功的恢复数据到了08月03日 20：28：10的数据，在此时间点之后的数据修改均没有生效，用户完美地规避了指定的时间点之后发生的数据风险。