用Redis数据闪回按时间点恢复数据

阿里云数据库具有数据闪回功能，可以按时间点恢复数据。开启数据闪回功能后，在备份文件的保存期内，您可以恢复指定时间点的Redis数据，从而避免误操作带来的数据损失，或者在频繁回档的业务场景快速完成数据切换。
在传统关系型数据库中（如Oracle）提供了数据闪回功能，帮助客户完成数据的按时间恢复。而在主流的高速缓存产品Redis、Memcached上却鲜有类似的功能，原因主要是考虑到作为缓存产品，其中的数据可以丢失，而通过背后配备的持久化、事务性的关系型数据库可以对缓存进行重新加载。但是，随着大量客户对于低延迟的业务应用性能要求不断的提高，对于一些对延迟要求极高的场景下，例如游戏行业，越来越多的客户选择化简架构，将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'   hset userprofile foo$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'   hkeys userprofile | wc -l
     120
% redis-cli -h hosts -a 'username:password'   hkeys userprofile | 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'   hkeys userprofile | wc -l
62
 
% redis-cli -h hosts -a 'username:password'   hkeys userprofile | sort -n
foo0803202709
…
foo0803202810

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