数据恢复方法和装置与流程

本申请涉及互联网技术领域，特别是涉及一种数据恢复方法和装置。

背景技术：

随着互联网技术的发展，传统的服务器端数据库在应对海量数据访问处理时面临巨大的挑战。在众多的数据库技术中，键-值(key-value)数据库是业界流行的一种，通过提供多种键-值数据类型来适应不同场景下的存储需求。其中，在用户使用键-值数据库过程中，服务器可能需要对用户的历史数据进行恢复。

技术实现要素：

本申请的目的在于提供一种数据恢复方法和装置，可以将数据库中的数据按指定的键进行恢复，而且可以恢复到存档的任意时间点。

本申请实施例提供了一种数据恢复方法，包括：

查找存档时间距离指定的恢复时间最近的、不晚于所述指定的恢复时间的数据库文件，从中解析出业务数据，并将其加载到一个临时实例中；查找与所述数据库文件对应的流水文件；

从所述流水文件中确定不晚于所述指定的恢复时间记录的流水记录，并从确定出的流水记录中解析出更新数据；

在所述临时实例中，用所述更新数据更新所述业务数据；

将更新后的业务数据恢复到对应的业务实例中。

本申请实施例提供了一种数据恢复装置，包括：

业务数据处理模块，用于查找存档时间距离指定的恢复时间最近的、不晚于所述指定的恢复时间的数据库文件，从中解析出业务数据，并将其加载到一个临时实例中；

流水文件查找模块，用于查找与所述数据库文件对应的流水文件；

更新数据确定模块，用于从所述流水文件中确定不晚于所述指定的恢复时间记录的流水记录，并从确定出的流水记录中解析出更新数据；

更新模块，用于在所述临时实例中，用所述更新数据更新所述业务数据；

恢复模块，用于将更新后的业务数据恢复到对应的业务实例中。

本申请的数据恢复方法和装置，用户可以指定存档时间段内的任意时间点和要恢复的键进行恢复，具有较好的系统可靠性和便利性，数据恢复方式比较灵活。

附图说明

为了更清楚的说明本申请中的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。

图1为根据本申请实施例的数据恢复方法的流程图；

图2为根据本申请实施例的数据恢复用户界面示意图；

图3为根据本申请实施例的流水文件和备份RDB文件关系示意图；

图4为根据本申请实施例的数据恢复方法的流程图；

图5为根据本申请实施例的用于数据恢复的流水记录内容示意图；

图6为根据本申请实施例的数据恢复方法示意图；

图7为根据本申请实施例的用于设置要恢复的键的用户界面示意图；

图8为根据本申请实施例的数据恢复装置示意图；

图9为根据本申请实施例的数据恢复装置的示意图；

图10为根据本申请实施例的数据恢复装置示意图；

图11为根据本申请实施例的数据恢复装置的硬件结构示意图。

具体实施方式

以下结合说明书附图及具体实施例进一步说明本申请。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

网络游戏服务器通常包括游戏服务器(例如用于网页、账号登陆验证等)、数据库服务器(例如用于环境参数、角色资料等)、备份服务器(例如包括数据备份服务器及游戏大区备用服务器)等。其中，备份服务器的数据库通常具有一个备份机制，例如：每隔第一段时间，将游戏中的所有游戏数据进行备份，这个第一段时间以天为单位；每隔第二段时间做一次差异备份，即把第二段时间内与完整备份的所有游戏数据相比发生变化的游戏数据进行备份，这个第二段时间以小时为单位。当需要恢复游戏数据时，先调取离恢复时间最近的差异备份，通过差异备份对离恢复时间最近的完整备份进行修改，就得到恢复的数据。这样的备份服务器可以使用Redis(Remote Dictionary Server(远程字典服务器))存储系统。

Redis存储系统是一种键-值(key-value)数据库。键-值数据库是一种字典式或哈希(Hash)式数据库。字典中包含有对象或者记录的集合，而记录中有多个不同的域(Filed)，每个域包含有数据。这些记录是使用键进行存储和获取的，每个键唯一标识一条记录，可以用于在数据库中迅速找到数据。通常，每个键是一个字符串对象。键值则是包括字符串、列表、哈希表、集合或者有序集在内的任意一种Redis类型对象。在Redis系统中，键有一些相关的命令，例如“DEL key”是删除一个键；“DUMP key”是序列化给定的key，并返回被序列化的值。可以通过键来添加、查询或者删除数据。

通常Redis数据存储在服务器的内存中，然后通过例如RDB(Redis DataBase(Redis数据库))和AOF(Append-only file(只追加操作的文件))机制持久化到磁盘中。RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘中的二进制文件中。例如，可以配置在几秒(例如N秒)内如果超过一定数目的(例如M个)key被修改就自动做快照，保存一次数据集。Redis允许设置不同的保存点来控制保存RDB文件的频率。而AOF机制是记录一段时间内，数据的变更命令。通过AOF机制，Redis将每一个收到的写命令通过写函数(write)追加到文件中。AOF文件为文本文件。例如，服务器每隔一秒或者两秒进行一次同步，将内存中的AOF文件同步到磁盘中。

在恢复数据时，将RDB文件和AOF文件加载到内存中，完成数据恢复。AOF文件的加载的过程相当于历史重放，而RDB文件因为是二进制格式，直接进行加载。

但是，在现有技术中，当进行数据恢复时，不能指定某个键来恢复，而且在恢复时也是只能恢复到特定时间点，不能恢复到存档的任意时间点。

本申请实施例提供了一种新的数据恢复方法和装置，可以将数据库中的数据按指定的键进行恢复，而且可以恢复到存档的任意时间点。

图1为根据本申请实施例的一种数据恢复方法的流程图。该数据恢复方法应用于服务器上，包括以下步骤：

步骤101：查找存档时间距离指定的恢复时间最近的、不晚于所述指定的恢复时间的数据库文件，从中解析出业务数据，并将其加载到一个临时实例中。

根据本申请实施例，服务器可以根据用户的设置，定期将业务数据(例如游戏客户端的用户在游戏中的操作数据)的数据集快照存档为一个RDB文件。RDB文件中的数据集快照中包括键和键对应的值。每个RDB文件有一个存档时间。即一个RDB文件是对在一个存档时间的已有的业务数据的数据集快照。可以用这个存档时间作为RDB文件的文件名，例如：1474462444000.rdb。对于一个持续写入的数据库，服务器使用一个fork命令的copy on write机制。在生成数据集快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的业务数据，将业务数据写成为RDB文件。

在对业务数据进行恢复时，用户可以在一个用户界面中设置指定的恢复时间。图2为本申请实施例的数据恢复用户界面示意图。通过图2的用户界面，用户可以设置指定的恢复时间，包括：日期和具体时间。例如，恢复日期为2016年9月20日，具体时间为00时：00分：00秒。

在用户输入指定的恢复时间之后，服务器比较RDB文件的存档时间和用户指定的恢复时间，判断存档时间是否距离指定的恢复时间最近且不晚于所述指定的恢复时间。如果是，则选择使用这个RDB文件作为用于业务数据恢复的RDB文件。然后从这个RDB文件中解析出游戏的操作数据，即业务数据，将其加载到一个临时实例中。所述业务数据包括键和键对应的值。

步骤102：查找与所述数据库文件对应的流水文件。

服务器通常在对一个RDB文件完成存档时，同时创建一个流水文件，用于记录从RDB文件的存档时间开始产生的业务的更新数据，例如，服务器执行的业务的所有写操作命令。在恢复时，通过重新执行这些写操作命令便可以恢复数据。这个流水文件例如是AOF格式的。流水文件和RDB文件可以使用相同的文件名，表示它们的对应关系。

图3为根据本申请实施例的流水文件和备份RDB文件关系示意图。

如图3所示，1474458844000.water流水文件中记录了从1474458844000(2016年09月21日19时54分04秒)到1474462444000(2016年09月21日20时54分04秒)的时间段内的业务命令流水，1474462444000.rdb文件中记录了1474462444000时间点的内存数据，1474462444000.water流水文件记录了从1474462444000开始的业务命令流水记录。

根据本申请实施例，示例的流水文件1474458844000.water的格式和一部分内容如下：

1 1474458844000

2 $12

3 INCREMENT_ID

4 *2

5 $4

6 INCR

7 $$

在上述的1-7行各行之前的序号只是为了进行说明，在实际的AOF文件中一般是没有的。

第1行：记录了一个业务请求的时间戳“1474458844000”。该时间戳是按照big-edian(大字节序)的方式存储的整数，是一个Unix时间戳，对应的时间是2016年9月21日19点54分04秒。这个时间戳可用于在恢复时和恢复时间进行比较。

第2行：“$”表示一个字符串的开始，$后面的数值代表后面字符串的长度。在该例子中，字符串的长度为12。当该流水文件被读取时(例如在恢复时)，先读取字符串的长度，然后回车换行，读取12个字符，即第3行中的“INCREMENT_ID”，作为字符串的值或内容。

第3行：第2行的“$”涉及的字符串的值或内容。这里第2、3行一起表示业务请求的操作命令所涉及的键，在该示例中，涉及的键是“INCREMENT_ID”。

第4行：从这行开始是一个完整的Redis multi协议的命令，其中，“*”表示命令的开始，“*”后面的“2”表示命令的组成部分的数目，当前命令由2部分组成。

第5行：“$”表示一个字符串的开始，“4”表示字符串的长度为4。

第6行：是第5行的“$”所涉及的字符串的值或内容，“INCR”，是一个自增命令。

第7行：第一个“$”表示字符串的开始，第二个“$”表示是之前的键，即“INCREMENT_ID”。第6行和第7行结合起来，即是将“INCREMENT_ID”的值加1。

如果直接使用AOF流水文件，在Redis运行了较长时间的情况下，需要处理的AOF流水文件会比较大，耗时非常长，因此，需要减少处理AOF流水文件的数量。根据本申请实施例，每隔一段时间，将内存中的AOF流水文件的数据，全量存储到一个文件中，文件格式使用Redis自带的RDB格式，这个文件有存档的时间点。恢复时，将RDB文件加载到内存中，就可以将数据恢复到存档的时间点，再以这个时间点为基础，依次处理流水记录。

步骤103：从所述流水文件中确定不晚于所述指定的恢复时间记录的流水记录，并从确定出的流水记录中解析出更新数据。

如步骤102中的流水文件1474458844000.water所示，在本申请实施例的流水文件中，每条流水记录有相应的时间戳。通过比较这个时间戳和指定的恢复时间，判断这个时间戳是否小于等于所述指定的恢复时间，如果是，便可以确定流水记录不晚于所述指定的恢复时间。如果是不晚于，则从确定出的流水记录中解析出更新数据。

例如，通过解析流水文件1474458844000.water，更新数据包括操作：对“INCREMENT_ID”的值增加1。这个“INCREMENT_ID”的键有可能也出现在一个与这个流水文件对应的RDB文件中。

步骤104：在所述临时实例中，用所述更新数据更新所述业务数据。

根据本申请实施例，依次执行流水记录中的键对应的更新命令，对所述业务数据进行更新。例如通过用流水文件中包含的操作命令，即对“INCREMENT_ID”加1，和对应的RDB文件进行比较，对RDB文件中的“INCREMENT_ID”加1。

步骤105：将更新后的业务数据恢复到对应的业务实例中。

需要恢复的流水执行完成后，临时实例中的数据就是需要恢复时间点的数据，这时，将业务请求切换到临时实例，回收正式实例。即在更新后，通过将更新后的业务数据加载到对应的业务实例中，进行运行，便可以恢复业务数据。例如，从临时实例中把需要恢复的键(INCREMENT_ID)通过dump命令读取出来，然后通过restore命令带上replace参数将INCREMENT_ID对应的值恢复到业务实例中。

通过本申请实施例的数据恢复方法，用户可以指定存档时间段内的任意时间点进行恢复，具有较好的系统可靠性和便利性。

另外，根据本申请实施例，为了避免服务器本地文件破损带来的数据丢失，可以将备份的RDB和流水文件存入到分布式文件集群中。Redis的写入速度较快，分布式文件系统适合批量写入。

另外，根据本申请实施例，所述流水文件是存储在大数据组件中，例如HBase中，这样可以加快数据的恢复。

图4为根据本申请实施例的数据恢复方法的流程图。在图1的基础上，步骤103包括以下步骤：

步骤401：逐条读取所述流水文件中按时间顺序记录的流水记录。

根据本申请实施例，流水文件中的流水记录是按时间顺序记录的。

步骤402：每读取一条流水记录，判断该流水记录中包括的时间戳是否小于等于所述指定的恢复时间。

根据本申请实施例，流水记录中包括有相应的时间戳。通过比较流水记录的时间戳是否小于等于指定的恢复时间，便可以选择到指定的恢复时间为止、在对应的RDB文件基础上进行的操作命令的流水记录。

步骤403：如果否，则停止从所述流水文件中读取流水记录。

根据本申请实施例，如果一条流水记录中包括的时间戳大于指定的恢复时间，则表示该条流水记录中的操作命令是在指定的恢复时间之后进行的，不是到指定的恢复时间为止的历史操作，不能用于恢复。因此，便不再处理该条流水记录中的操作命令。由于流水记录是按时间顺序记录的，其之后的流水记录也不满足恢复要求。在这种情况下，可以停止从所述流水文件中读取流水记录。

步骤404：如果是，则确定读取的流水记录是不晚于所述指定的恢复时间的流水记录，并从中解析出更新数据。

如果一条流水记录中包括的时间戳小于等于指定的恢复时间，则表示这条流水记录是在RDB存档时间之后、在指定的恢复时间之前进行的操作，可以用于恢复。因此，从该流水记录中解析出更新数据。

图5为根据本申请实施例的用于数据恢复的流水记录内容示意图。可以结合上述实施例给出的流水文件来理解。

如图5所示，在流水文件中，每条流水记录包括固定长度的时间戳、紧邻所述时间戳的用于指示键的指示、所述键及其键对应的命令。

在上述的流水文件1474458844000.water中，时间戳为1474458844000，长度为13个字符；键为“INCREMENT_ID”；命令为“INCR”。

则根据本申请实施例的数据恢复方法中的从确定出的流水记录中解析出更新数据包括：

在判断读取的流水记录中包括的时间戳小于等于所述指定的恢复时间时，在读取所述时间戳之后读取键和键对应的更新命令。

在本申请实施例中，将键放置在时间戳之后，因为时间戳的长度是固定的，只需要内存操作一次即可解析出时间戳和键长度，然后读取键的内容。这样，提升了键的查找效率。

图6为根据本申请实施例的数据恢复方法示意图。其中，用户可以设置特定的键来恢复。图7是根据本申请实施例的用于设置要恢复的键的用户界面示意图。其中，可以在一个窗口701输入要恢复的键，然后可以通过下拉式菜单在输入框702输入键的编码格式，例如UTF-8(8-bit Unicode Transformation Format)。这个用户界面例如是在图2的用户界面设置完成之后显示的。

如图6所示，按指定的键进行数据恢复的流程如下：

步骤601：查找存档时间距离指定的恢复时间最近的、不晚于所述指定的恢复时间的数据库文件，从中解析出要恢复的键的第一键数据，并将其加载到一个临时实例中。

根据本申请实施例，在收到用户设置的指定的恢复时间和指定的键之后，服务器比较RDB文件的存档时间和用户指定的恢复时间，判断存档时间是否距离指定的恢复时间最近且不晚于所述指定的恢复时间。如果是，则选择使用这个RDB文件作为用于业务数据恢复的RDB文件。然后从这个RDB文件中解析出要恢复的键的第一键数据，将其加载到一个临时实例中。所述数据库文件例如为RDB文件：a.rdb。所述临时实例是一个临时的Redis进程。

步骤602：查找与所述数据库文件对应的流水文件。

例如，服务器查找并读取同一时间点的流水文件：a.water。这个流水文件和RDB文件的名称相同。

步骤603：从所述流水文件中确定不晚于所述指定的恢复时间记录的流水记录，并从确定出的流水记录中解析出要恢复的键的第二键数据。

根据本申请实施例，依次解析每条流水记录，判断流水记录的时间戳是否小于等于指定的恢复时间，如果小于等于，再判断流水记录的键是否为需要恢复的键，如果是，继续加载命令(例如，Restore)，将命令协议(即，记录的incr INCREMENT_ID)写入临时实例，继续处理下一条流水记录；如果流水时间大于需要恢复的时间，完成流水处理。

步骤604：在所述临时实例中，用所述第二键数据更新所述第一键数据。

根据本申请实施例，在临时实例中，依次执行流水记录中的键对应的更新命令(第二键数据)，对所述要恢复的键的第一键数据进行更新。

步骤605：将更新后的第一键数据恢复到对应的业务实例中。

从临时实例中把需要恢复的键通过dump命令读取出来，然后通过restore命令带上replace参数将键对应的值恢复到实例中。

图6的步骤和图1的步骤中，有类似的处理，可以参考图1的描述。

通过本申请实施例，可以根据用户设置的要恢复的键进行数据恢复，恢复方式更为灵活。

图8为本申请实施例的数据恢复装置示意图。如图8所示，数据恢复装置800包括：

业务数据处理模块801，用于查找存档时间距离指定的恢复时间最近的、不晚于所述指定的恢复时间的数据库文件，从中解析出业务数据，并将其加载到一个临时实例中。

根据本申请实施例，服务器可以根据用户的设置，定期将业务数据(例如游戏客户端的用户在游戏中的操作数据)的数据集快照存档为一个RDB文件。RDB文件中的数据集快照中包括键和键对应的值。每个RDB文件有一个存档时间。即一个RDB文件是对在一个存档时间的已有的业务数据的数据集快照。可以用这个存档时间作为RDB文件的文件名，例如：1474462444000.rdb。对于一个持续写入的数据库，服务器使用一个fork命令的copy on write机制。在生成数据集快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的业务数据，将业务数据写成为RDB文件。

在对业务数据进行恢复时，用户可以在一个用户界面中设置指定的恢复时间。图2为本申请实施例的数据恢复用户界面示意图。通过图2的用户界面，用户可以设置指定的恢复时间，包括：日期和具体时间。例如，恢复日期为2016年9月20日，具体时间为00时：00分：00秒。

在用户输入指定的恢复时间之后，服务器中的业务数据处理模块801比较RDB文件的存档时间和用户指定的恢复时间，判断存档时间是否距离指定的恢复时间最近且不晚于所述指定的恢复时间。如果是，则选择使用这个RDB文件作为用于业务数据恢复的RDB文件。然后从这个RDB文件中解析出游戏的操作数据，即业务数据，将其加载到一个临时实例中。所述业务数据包括键和键对应的值。

流水文件查找模块802，用于查找与所述数据库文件对应的流水文件。

服务器通常在对一个RDB文件完成存档时，同时创建一个流水文件，用于记录从RDB文件的存档时间开始产生的业务的更新数据，例如，服务器执行的业务的所有写操作命令。在恢复时，通过重新执行这些写操作命令便可以恢复数据。这个流水文件例如是AOF格式的。流水文件和RDB文件可以使用相同的文件名，表示它们的对应关系。根据本申请实施例，流水文件查找模块802查找与数据库文件名称相同的流水文件。

更新数据确定模块803，用于从所述流水文件中确定不晚于所述指定的恢复时间记录的流水记录，并从确定出的流水记录中解析出更新数据。

如流水文件1474458844000.water所示，在本申请实施例的流水文件中，每条流水记录有相应的时间戳。通过比较这个时间戳和指定的恢复时间，判断这个时间戳是否小于等于所述指定的恢复时间，如果是，便可以确定流水记录不晚于所述指定的恢复时间。如果是不晚于，则从确定出的流水记录中解析出更新数据。

例如，通过解析流水文件1474458844000.water，更新数据包括操作：对“INCREMENT_ID”的值增加1。这个“INCREMENT_ID”的键有可能也出现在一个与这个流水文件对应的RDB文件中。

更新模块804，用于在所述临时实例中，用所述更新数据更新所述业务数据。

根据本申请实施例，依次执行流水记录中的键对应的更新命令，对所述业务数据进行更新。例如通过用流水文件中包含的操作命令，即对“INCREMENT_ID”加1，和对应的RDB文件进行比较，对RDB文件中的“INCREMENT_ID”加1。

恢复模块805，用于将更新后的业务数据恢复到对应的业务实例中。

需要恢复的流水执行完成后，临时实例中的数据就是需要恢复时间点的数据，这时，将业务请求切换到临时实例，回收正式实例。即在更新后，通过恢复模块805将更新后的业务数据加载到对应的业务实例中，进行运行，便可以恢复业务数据。例如，从临时实例中把需要恢复的键(INCREMENT_ID)通过dump命令读取出来，然后通过restore命令带上replace参数将INCREMENT_ID对应的值恢复到业务实例中。

通过本申请实施例的数据恢复装置，用户可以指定存档时间段内的任意时间点进行恢复，具有较好的系统可靠性和便利性。

图9为根据本申请实施例的数据恢复装置的示意图，其中，在图8所示的装置的基础上，所述更新数据确定模块803包括：

流水记录读取模块901，用于逐条读取所述流水文件中按时间顺序记录的流水记录。

根据本申请实施例，流水文件中的流水记录是按时间顺序记录的。流水记录读取模块901逐条读取所述流水文件中按时间顺序记录的流水记录。

流水记录判断模块902，用于每读取一条流水记录，判断该流水记录中包括的时间戳是否小于等于所述指定的恢复时间；如果否，则停止从所述流水文件中读取流水记录；如果是，则确定读取的流水记录是不晚于所述指定的恢复时间的流水记录，并从中解析出更新数据。

根据本申请实施例，流水记录中包括有相应的时间戳。通过比较流水记录的时间戳是否小于等于指定的恢复时间，便可以选择到指定的恢复时间为止、在对应的RDB文件基础上进行的操作命令的流水记录。

根据本申请实施例，如果一条流水记录中包括的时间戳大于指定的恢复时间，则表示该条流水记录中的操作命令是在指定的恢复时间之后进行的，不是到指定的恢复时间为止的历史操作，不能用于恢复。因此，便不再处理该条流水记录中的操作命令。由于流水记录是按时间顺序记录的，其之后的流水记录也不满足恢复要求。在这种情况下，可以停止从所述流水文件中读取流水记录。

如果一条流水记录中包括的时间戳小于等于指定的恢复时间，则表示这条流水记录是在RDB存档时间之后、在指定的恢复时间之前进行的操作，可以用于恢复。因此，从该流水记录中解析出更新数据。

根据本申请实施例的数据恢复装置，其中，在所述流水文件中，每条流水记录包括固定长度的时间戳、紧邻所述时间戳的用于指示键的指示、所述键及其键对应的命令；

从确定出的流水记录中解析出更新数据包括：

在判断读取的流水记录中包括的时间戳小于等于所述指定的恢复时间时，在读取所述时间戳之后读取键和键对应的命令。

在本申请实施例中，将键放置在时间戳之后，因为时间戳的长度是固定的，只需要内存操作一次即可解析出时间戳和键长度，然后读取键的内容。这样，提升了键的查找效率。

图10为根据本申请实施例的数据恢复装置示意图。其中，在前述实施例的数据恢复装置的基础上，进一步包括：设置模块806，用于：响应于用户界面元素上的输入操作，设置所述指定的恢复时间；响应于用户界面元素上的输入操作，设置要从所述数据库文件和所述流水文件中恢复的指定的键。

根据本申请实施例的数据恢复装置，其中所述数据库文件是对在存档时间的已有的业务数据的数据集快照；所述流水文件是响应于所述数据库文件的创建而创建，用于记录从所述存档时间开始产生的业务的更新数据。

根据本申请实施例的数据恢复装置，其中，所述解析出业务数据例如包括：解析出指定的键及其对应的值；所述解析出更新数据例如包括：解析出指定的键及其对应的更新命令。

根据本申请实施例，所述数据恢复装置可以按指定的键进行数据恢复。例如，在这种情况下，各模块的处理如下：

业务数据处理模块801可以查找存档时间距离指定的恢复时间最近的、不晚于所述指定的恢复时间的数据库文件，从中解析出要恢复的键的第一键数据，并将其加载到一个临时实例中。

根据本申请实施例，在收到用户设置的指定的恢复时间和指定的键之后，业务数据处理模块801可以比较RDB文件的存档时间和用户指定的恢复时间，判断存档时间是否距离指定的恢复时间最近且不晚于所述指定的恢复时间。如果是，则选择使用这个RDB文件作为用于业务数据恢复的RDB文件。然后从这个RDB文件中解析出要恢复的键的第一键数据，将其加载到一个临时实例中。所述数据库文件例如为RDB文件：a.rdb。所述临时实例是一个临时的Redis进程。

流水文件查找模块802可以查找与所述数据库文件对应的流水文件。

例如，查找并读取同一时间点的流水文件：a.water。这个流水文件和RDB文件的名称相同。

更新数据确定模块803可以从所述流水文件中确定不晚于所述指定的恢复时间记录的流水记录，并从确定出的流水记录中解析出要恢复的键的第二键数据。

根据本申请实施例，更新数据确定模块803可以依次解析每条流水记录，判断流水记录的时间戳是否小于等于指定的恢复时间，如果小于等于，再判断流水记录的键是否为需要恢复的键，如果是，继续加载命令(例如，Restore)，将命令协议(即，记录的incr INCREMENT_ID)写入临时实例，继续处理下一条流水记录；如果流水时间大于需要恢复的时间，完成流水处理。

更新模块804可以在所述临时实例中，用所述第二键数据更新所述第一键数据。

根据本申请实施例，在临时实例中，依次执行流水记录中的键对应的更新命令(第二键数据)，对所述要恢复的键的第一键数据进行更新。

恢复模块805可以将更新后的第一键数据恢复到对应的业务实例中。

从临时实例中把需要恢复的键通过dump命令读取出来，然后通过restore命令带上replace参数将键对应的值恢复到实例中。

通过本申请实施例，可以根据用户设置的要恢复的键进行数据恢复，恢复方式更为灵活。

图11所示为根据本申请实施例的数据恢复装置的硬件结构示意图。

参照图11，该数据恢复装置可以包括：处理器1101(例如CPU)、通信总线1102、接口1103、存储器1104。其中，通信总线1102用于实现该数据恢复装置中各组成部件之间的连接通信。接口1103包括用户接口和网络接口。用户接口可以包括显示器、键盘、鼠标等外设，用于接收用户输入的信息，并将接收的信息发送至处理器1101进行处理。显示器可以为LCD显示器、LED显示器，也可以为触摸屏，用于显示需要显示的数据。可选的用户接口还可以包括标准的有线接口、无线接口等。网络接口可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1104可以是高速RAM存储器，也可以是稳定的或非易失性存储器，例如磁盘存储器。存储器1104可选的还可以是独立于前述处理器1101的存储装置。如图11所示，作为一种计算机存储介质的存储器1104中可以存储有图8中的各个模块。在图11中，仅示出了模块801-805用于示例。这些模块例如为指令模块。处理器1101执行存储于存储器1104中的模块，用于完成这些模块的指定功能。作为一种计算机存储介质的存储器1104中还可以存储计算机程序指令，用于当由处理器1101执行时，执行图1、图4、图6中的方法。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的，应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

另外，在本发明各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述各实施例的功能模块可以位于一个终端或网络节点，或者也可以分布到多个终端或网络节点上。

另外，本申请的每个实例可以通过由数据处理设备如计算机执行的数据处理程序来实现。显然，数据处理程序构成了本申请。此外，通常存储在一个存储介质中的数据处理程序通过直接将程序读取出存储介质或者通过将程序安装或复制到数据处理设备的存储设备(如硬盘和或内存)中执行。因此，这样的存储介质也构成了本申请。存储介质可以使用任何类型的记录方式，例如纸张存储介质(如纸带等)、磁存储介质(如软盘、硬盘、闪存等)、光存储介质(如CD-ROM等)、磁光存储介质(如MO等)等。

因此，本申请还提供了一种非易失性存储介质，其中存储有内容分级程序，该内容分级程序用于执行本申请上述实施例方法中的任何一种实例。

以上所述仅为本申请的实例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。