内存数据的持久化方法及装置、存储介质、计算机设备与流程

1.本申请涉及计算机技术领域，尤其是涉及到一种内存数据的持久化方法及装置、存储介质、计算机设备。


背景技术：

2.随着互联网技术的高速发展，数据处理的复杂性和密集型急剧增加，使得数据的处理量成倍增长，因此对数据处理速度提出了更高的要求。目前，通常采用redis数据库来提高数据的处理效率，通过将数据存储在内存中，处理完成后再将处理结果存储到磁盘中，减少了内存与磁盘在数据交互过程中的频繁i/o操作，大大提高了数据的处理效率。
3.由于redis是一个内存数据库，内存中的数据都是临时存储的，当发生故障时，容易导致数据丢失。因而，如何确保内存数据的安全性是内存数据库需要解决的问题，redis数据库提供了快照文件rdb(即快照，snapshot)和增量文件aof(append only file)两种方式确保数据的安全性。rdb快照是周期性的将内存中的数据保存到磁盘中，然而，由于数据是周期性保存的，一旦发生故障，从上次数据保存到发生故障这段时间的数据将全部丢失，可见rdb快照并不能够很好的保证数据的安全性，仍然存在丢失部分数据的风险。增量文件aof是将redis数据库的每次写操作都保存到一个aof文件，由于aof文件中保存了每次的写操作，可以很好地确保数据的安全性，然而，aof文件是不断地累积redis数据库的写操作，随着时间的推移，aof文件会变得越来越大，占用大量的存储空间。
4.然而，在现有技术中，只能由技术人员指定其中的一种持久化策略进行数据持久化。这就导致了在使用rbd策略时，如果数据库发生故障可能会丢失一个时间节点的重要数据。使用aof策略时，如果数据库内的数据集过大，生成的文件体积过大，占用存储空间大，并且恢复时间长。


技术实现要素：

5.有鉴于此，本申请提供了一种内存数据的持久化方法及装置、存储介质、计算机设备。
6.根据本申请的一个方面，提供了一种内存数据的持久化方法，包括：
7.获取目标时间对应的业务数据持久化方式，其中，所述业务数据持久化方式与所述目标时间对应的历史参照时间的业务数据特征匹配；
8.若所述业务数据持久化方式为所述快照文件方式，则调用分叉函数fork创建子进程，以及通过所述子进程将内存中已有的业务数据写入所述快照文件中，得到与所述目标时间对应的持久化文件；
9.若所述业务数据持久化方式为所述增量文件方式，则当有更新数据写入内存时，将所述更新数据对应的写入指令顺序添加至所述增量文件中，得到与所述目标时间对应的持久化文件。
10.具体地，所述获取目标时间对应的业务数据持久化方式之前，所述方法还包括：
11.获取与所述目标时间对应的所述历史参照时间，以及与所述历史参照时间对应的所述业务数据特征，其中，所述业务数据特征存储于区块链中，所述业务数据特征包括但不限于所述历史参照时间内产生的业务数据对应的重要数据占比、读写次数以及数据集大小；
12.基于预设数据持久化特征规则，确定与所述业务数据特征匹配的所述业务数据持久化方式，其中，所述预设数据持久化特征规则包括与所述快照文件方式对应的第一特征规则以及与所述增量文件方式对应的第二特征规则。
13.具体地，当所述业务数据特征包括所述重要数据占比时，所述获取与所述历史参照时间对应的所述业务数据特征，具体包括：
14.分别获取所述历史参照时间内的每一条业务数据的业务类型标识，并统计所述历史参照时间内全部业务数据中预设重要业务类型的数据量，其中，所述业务类型标识包括但不限于所述每一条业务数据的key值；
15.基于所述预设重要业务类型的数据量，确定所述预设重要业务类型的业务数据占所述全部业务数据的比重，将所述比重作为所述重要数据占比。
16.具体地，所述得到持久化数据文件之后，所述方法还包括：
17.接收业务数据恢复指令，其中，所述业务数据恢复指令包括恢复时间；
18.获取与所述恢复时间对应的待恢复的持久化数据文件；
19.按照与所述待恢复的持久化数据文件对应的时间先后顺序，依次恢复所述待恢复的持久化数据文件。
20.具体地，所述确定与所述业务数据特征匹配的所述持久化方式，具体包括：
21.若所述业务数据特征与所述第一特征规则以及所述第二特征规则均不匹配，则确定所述业务数据持久化方式为混合方式；
22.所述获取目标时间对应的业务数据持久化方式之后，所述方法还包括：
23.若所述目标时间对应的所述业务数据持久化方式为所述混合方式，则当有更新数据需要写入内存时，将所述更新数据对应的写入指令顺序添加至增量文件中；
24.当所述增量文件的大小大于或等于预设阈值时，将所述内存中已有的数据添加至快照文件中，并清空所述增量文件。
25.根据本申请的另一方面，提供了一种内存数据的持久化装置，包括：
26.持久化方式获取模块，用于获取目标时间对应的业务数据持久化方式，其中，所述业务数据持久化方式与所述目标时间对应的历史参照时间的业务数据特征匹配；
27.第一持久化模块，用于若所述业务数据持久化方式为所述快照文件方式，则调用分叉函数fork创建子进程，以及通过所述子进程将内存中已有的业务数据写入所述快照文件中，得到与所述目标时间对应的持久化文件；
28.第二持久化模块，用于若所述业务数据持久化方式为所述增量文件方式，则当有更新数据写入内存时，将所述更新数据对应的写入指令顺序添加至所述增量文件中，得到与所述目标时间对应的持久化文件。
29.具体地，所述装置还包括：
30.数据特征获取模块，用于所述获取目标时间对应的业务数据持久化方式之前，获取与所述目标时间对应的所述历史参照时间，以及与所述历史参照时间对应的所述业务数
据特征，其中，所述业务数据特征存储于区块链中，所述业务数据特征包括但不限于所述历史参照时间内产生的业务数据对应的重要数据占比、读写次数以及数据集大小；
31.持久化方式确定模块，用于基于预设数据持久化特征规则，确定与所述业务数据特征匹配的所述业务数据持久化方式，其中，所述预设数据持久化特征规则包括与所述快照文件方式对应的第一特征规则以及与所述增量文件方式对应的第二特征规则。
32.具体地，所述数据特征获取模块，具体包括：
33.业务类型统计单元，用于当所述业务数据特征包括所述重要数据占比时，分别获取所述历史参照时间内的每一条业务数据的业务类型标识，并统计所述历史参照时间内全部业务数据中预设重要业务类型的数据量，其中，所述业务类型标识包括但不限于所述每一条业务数据的key值；
34.重要数据占比确定单元，用于基于所述预设重要业务类型的数据量，确定所述预设重要业务类型的业务数据占所述全部业务数据的比重，将所述比重作为所述重要数据占比。
35.具体地，所述装置还包括：
36.恢复指令接收模块，用于所述得到与所述目标时间对应的持久化文件之后，接收业务数据恢复指令，其中，所述业务数据恢复指令包括恢复时间；
37.持久化文件获取模块，用于获取与所述恢复时间对应的待恢复的持久化数据文件；
38.数据恢复模块，用于按照与所述待恢复的持久化数据文件对应的时间先后顺序，依次恢复所述待恢复的持久化数据文件。
39.具体地，所述持久化方式确定模块，具体用于：若所述业务数据特征与所述第一特征规则以及所述第二特征规则均不匹配，则确定所述业务数据持久化方式为混合方式；
40.所述装置还包括：
41.增量文件添加模块，用于若所述目标时间对应的所述业务数据持久化方式为所述混合方式，则当有更新数据需要写入内存时，将所述更新数据对应的写入指令顺序添加至增量文件中；
42.快照文件写入模块，用于当所述增量文件的大小大于或等于预设阈值时，将所述内存中已有的数据添加至快照文件中，并清空所述增量文件。
43.依据本申请又一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述内存数据的持久化方法。
44.依据本申请再一个方面，提供了一种计算机设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述内存数据的持久化方法。
45.借由上述技术方案，本申请提供的一种内存数据的持久化方法及装置、存储介质、计算机设备，通过获取目标时间对应的业务数据持久化方式，从而按照相应的业务数据持久化方式对数据库中相应目标时间对应的业务数据进行持久化得到持久化数据文件，实现对内存数据的持久化处理，其中，业务数据持久化方式基于目标时间相应的历史参考时间的业务数据特征确定，使得对目标时间的业务数据持久化方式与历史参考时间对应的业务数据特征相匹配。本申请实施例相比于现有技术中技术人员指定一种持久化策略的方式，
通过对历史参照时间的业务数据的数据特征进行统计分析从而确定目标时间对应的业务数据持久化方式，使得目标时间的业务数据持久化方式与该时间段对应的业务数据的数据特征相匹配，从而自动选择一种更贴近目标时段业务数据特征的持久化方式，解决了持久化方式需要人工确定缺乏理论依据、持久化方式与业务数据特征不匹配从而导致的业务数据丢失、持久化数据文件过大等问题。
46.上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。
附图说明
47.此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
48.图1示出了本申请实施例提供的一种内存数据的持久化方法的流程示意图；
49.图2示出了本申请实施例提供的另一种内存数据的持久化方法的流程示意图；
50.图3示出了本申请实施例提供的一种内存数据的持久化装置的结构示意图；
51.图4示出了本申请实施例提供的另一种内存数据的持久化装置的结构示意图。
具体实施方式
52.下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
53.在本实施例中提供了一种内存数据的持久化方法，如图1所示，该方法包括：
54.步骤101，获取目标时间对应的业务数据持久化方式，其中，业务数据持久化方式与目标时间对应的历史参照时间的业务数据特征匹配；
55.步骤102，若业务数据持久化方式为快照文件方式，则调用分叉函数fork创建子进程，以及通过子进程将内存中已有的业务数据写入快照文件中，得到与目标时间对应的持久化文件；
56.步骤103，若业务数据持久化方式为增量文件方式，则当有更新数据写入内存时，将更新数据对应的写入指令顺序添加至增量文件中，得到与目标时间对应的持久化文件。
57.本申请实施例用于持久化redis数据库中的数据，redis数据库是一种内存数据库，redis数据库将数据存储在内存中，直接在内存中读取数据进行相应的操作处理，由于内存的数据读写速度要高出磁盘几个数量级，redis数据库通过将数据存储在内存能够极大地提高数据的处理效率。内存数据具有断电丢失的特性，一旦机器发生故障或重启时，内存中的数据将全部丢失。
58.在上述实施例中，redis数据库中业务数据的持久化方式与业务数据的产生时间相关，目标时间为数据库中业务数据的产生时间，目标时间为一个或多个时间段，例如，目标时间为0：00
‑
1：00，或者目标时间为0：00
‑
1：00、1：00
‑
3：00
……
等等。目标时间对应的历史参照时间具体可以基于预先约定的业务数据持久化规则来确定，在预设的业务数据持久化规则中预先约定了目标时间内对应的redis内存数据在进行持久化时应参考哪个历史时间段对应的业务数据来制定持久化策略，例如，预先对历史业务数据进行大数据统计分析
发现，某业务平台对应的业务数据的数据特征呈周期性变化，且变化周期为一天，即该业务平台可能在每一天中的同一个时间段产生的业务数据的数据特征都非常相近，那么目标时间0：00
‑
1：00可以参考前一天0：00
‑
1：00的业务数据的数据特征来制定持久化策略，即目标时间(0：00
‑
1：00)对应的历史参照时间为前一天的同一时间段(0：00
‑
1：00)或者前一周每天的同一时间段(0：00
‑
1：00)。进一步，确定目标时间对应的历史参照时间之后，可以根据该历史参照时间对应的业务数据特征来确定目标时间的业务数据持久化方式。例如，业务数据中写操作次数较多可以采用增量文件方式实现对内存数据中的每一次写操作进行记录，以使恢复数据时可以保持较高的数据一致性。又例如，业务数据中数据量巨大可以采用快照文件方式实现对内存数据的持久化，使得产生的持久化数据文件占用内存较小。
59.进而，确定了目标时间对应的业务数据持久化方式之后，可以按照相应的业务数据持久化方式对目标时间对应的redis数据库中的业务数据进行持久化，生成持久化文件，以便在故障时或其他情况需要进行数据恢复时利用持久化文件对业务数据进行恢复。另外，业务数据持久化方式除了包含持久化策略(rdb或aof)外，还可以包含具体的快照文件方式对应的持久化周期，即多久进行一次rdb持久化存储，或者增量文件方式对应的具体策略，比如是每次修改同步还是每秒同步等等。
60.在具体的应用场景中，若业务数据持久化方式为快照文件方式，则使用fork函数复制一份当前进程的副本(子进程)，父进程继续处理客户端请求，fork进程负责把内存的数据同步到磁盘的临时文件，当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。若业务数据持久化方式为增量文件方式，则内存通常会对同一个数据进行不断的更新操作，每一次的更新操作都对应一个写入指令，将每次更新操作对应的写入指令按顺序添加至增量文件中，先添加至增量文件的写入指令排在后添加至增量文件的写入指令的前面。
61.通过应用本实施例的技术方案，通过获取目标时间对应的业务数据持久化方式，从而按照相应的业务数据持久化方式对数据库中相应目标时间对应的业务数据进行持久化得到持久化数据文件，实现对内存数据的持久化处理，其中，业务数据持久化方式基于目标时间相应的历史参考时间的业务数据特征确定，使得对目标时间的业务数据持久化方式与历史参考时间对应的业务数据特征相匹配。本申请实施例相比于现有技术中技术人员指定一种持久化策略的方式，通过对历史参照时间的业务数据的数据特征进行统计分析从而确定目标时间对应的业务数据持久化方式，使得目标时间的业务数据持久化方式与该时间段对应的业务数据的数据特征相匹配，从而自动选择一种更贴近目标时段业务数据特征的持久化方式，解决了持久化方式需要人工确定缺乏理论依据、持久化方式与业务数据特征不匹配从而导致的业务数据丢失、持久化数据文件过大等问题。
62.进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的具体实施过程，提供了另一种内存数据的持久化方法，如图2所示，该方法包括：
63.步骤201，获取与目标时间对应的历史参照时间，以及与历史参照时间对应的业务数据特征，其中，业务数据特征存储于区块链中，业务数据特征包括但不限于历史参照时间内产生的业务数据对应的重要数据占比、读写次数以及数据集大小；
64.本申请实施例基于目标时间对应的历史参照时间内产生的业务数据的数据特征来确定目标时间的业务数据持久化方式，因此为确定目标时间对应的业务数据持久化规
则，应先获取与目标时间对应的历史参照时间，以及与历史参照时间对应的业务数据特征。其中，业务数据特征包括但不限于以下几个方面：该时段产生的业务数据中重要数据的占比、该时段产生的业务数据的读、写次数以及该时段内产生的业务数据的数据集大小，从而对业务数据特征进行分析，并根据业务数据特征确定相应的目标时间对应的业务数据持久化方式。需要强调的是，为进一步保证上述业务数据的数据特征的私密和安全性，上述业务数据特征还可以存储于一区块链的节点中。
65.其中，步骤201中业务数据特征中的重要数据占比基于以下方式确定：
66.步骤201
‑
1，分别获取历史参照时间内的每一条业务数据的业务类型标识，并统计历史参照时间内全部业务数据中预设重要业务类型的数据量，其中，
67.业务类型标识包括但不限于每一条业务数据的key值；
68.步骤201
‑
2，基于预设重要业务类型的数据量，确定预设重要业务类型的业务数据占全部业务数据的比重，将比重作为重要数据占比。
69.在上述实施例中，统计历史参照时间内对应的每一条业务数据的业务类型，其中，通过业务数据的业务类型标识确定业务数据的业务类型，具体若数据库中存储的业务数据为key
‑
value数据(键值对数据)，可以通过key(关键字)值来确定具体的业务数据的业务类型，并在确定每条业务数据的业务类型后，对属于预设重要业务类型的业务数据的数据量进行统计，将重要业务类型的业务数据的数据量占该时段全部业务数据的数据量的比重作为上述的重要数据占比，从而将该重要数据占比作为业务数据特征的一项分析因素。
70.步骤202，基于预设数据持久化特征规则，确定与业务数据特征匹配的业务数据持久化方式，其中，预设数据持久化特征规则包括与快照文件方式对应的第一特征规则以及与增量文件方式对应的第二特征规则。
71.在上述实施例中，通过预先设定不同持久化方式的选择条件，形成预设数据持久化特征规则，从而在获取业务数据对应的业务数据特征之后，确定业务数据特征命中情况，具体的，如果业务数据特征命中第一特征规则，那么可以确定该业务数据特征对应的业务数据持久化方式为快照文件方式，相应的，若命中第二特征规则，则为增量文件方式。在具体的应用场景中，本领域技术人员可以按照实际需要设定第一特征规则和第二特征规则，在此不做具体限定。例如，第一特征规则可以为重要数据占比大于50％，读操作次数大于写操作次数100万次，数据集大小大于1g，那么当业务数据特征满足上述条件时确定业务数据特征匹配的业务数据持久化方式为快照文件方式，否则确定增量文件方式为业务数据持久化方式。
72.另外，在本申请实施例中，具体地，若业务数据特征与第一特征规则以及第二特征规则均不匹配，则确定业务数据持久化方式为混合方式。
73.在上述实施例中，业务数据持久化方式还可以包括一种rdb和aof混合的方式，当业务数据特征未命中第一特征规则，也未命中第二特征规则时，确定业务数据持久化方式为该混合方式，具体如何利用该方式进行数据持久化在下文中详细描述。
74.需要说明的是，本申请实施例的步骤201和步骤202可以是在需要对目标时间对应的业务数据进行持久化时执行。例如，可以在9月6号0：00到来前，通过获取9月1号至5号每天0：00
‑
1：00对应的业务数据特征从而确定9月6号至10号0：00
‑
1：00对应的业务数据持久化方式。也可以是产生业务数据后立即执行，从而对后续时间段对应的业务数据持久化方
式进行预测以便预测的时间段到来时直接按照相应持久化方式执行，具体地，设置定时任务，定时任务自动统计分析已产生业务数据的数据特征，并制定相应时间的业务数据持久化方式。例如，在9月5号1：00之后，通过统计9月1号至5号每天0：00
‑
1：00的业务数据特征，确定9月6号至10号0：00
‑
1：00的业务数据持久化方式，从而在9月6号0：00到来时直接按照相应方式进行数据持久化即可，另外，为了减少定时任务的执行次数，若9月1号至5号每天0：00
‑
1：00的数据特征变大不大，可以将定时任务由每5天统计一次改为每10天统计一次，即从原来的用前5天的业务数据特征确定后5天的业务数据持久化方式，变为用前10天的业务数据特征确定后10天的业务数据持久化方式，提高统计效率。
75.步骤203，获取目标时间对应的业务数据持久化方式，其中，业务数据持久化方式与目标时间对应的历史参照时间的业务数据特征匹配；
76.步骤204，基于业务数据持久化方式对目标时间对应的内存数据进行持久化处理，得到持久化数据文件。
77.在本申请实施例中，按照业务数据持久化方式的不同，上述步骤204具体包括以下3种实施例：
78.实施例1、
79.当业务数据持久化方式为快照文件方式时，步骤204，具体包括：
80.步骤204a1，调用分叉函数fork创建子进程；
81.步骤204a2，通过子进程将内存中已有的业务数据写入快照文件中。
82.在上述实施例中，使用fork函数复制一份当前进程的副本(子进程)，父进程继续处理客户端请求，fork进程负责把内存的数据同步到磁盘的临时文件，当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。
83.实施例2、
84.当业务数据持久化方式为增量文件方式时，步骤204，具体包括：
85.步骤204b1，当有更新数据写入内存时，将更新数据对应的写入指令顺序添加至增量文件中。
86.在上述实施例中，内存通常会对同一个数据进行不断的更新操作，每一次的更新操作都对应一个写入指令，将每次更新操作对应的写入指令按顺序添加至增量文件中，先添加至增量文件的写入指令排在后添加至增量文件的写入指令的前面。
87.实施例3、
88.若目标时间对应的业务数据持久化方式为混合方式，步骤204，具体包括：
89.步骤204c1，当有更新数据需要写入内存时，将更新数据对应的写入指令顺序添加至增量文件中；
90.步骤204c2，当增量文件的大小大于或等于预设阈值时，将内存中已有的数据添加至快照文件中，并清空增量文件。
91.在上述实施例中，混合方式对应的数据持久化过程具体为，先按照增量文件方式持久化业务数据，每次数据更新都将更新数据对应的写入指令添加至增量文件中，写入增量文件中的写入指令将会越来越多，增量文件的大小将变得越来越大，所占用的存储空间也越来越大，当增量文件的大小大于或等于预设阈值时，可以将内存中已有的数据添加至快照文件，其中，本领域技术人员可以根据实际需要设定预设阈值的大小，本申请实施例对
此不做限定，另外，将内存中已有的数据添加至快照文件中后，可以将该时段对应的增量文件情况，删除增量文件中已经保存的写入指令。
92.步骤205，接收业务数据恢复指令，其中，业务数据恢复指令包括恢复时间；
93.步骤206，获取与恢复时间对应的待恢复的持久化数据文件；
94.步骤207，按照与待恢复的持久化数据文件对应的时间先后顺序，依次恢复待恢复的持久化数据文件。
95.在上述实施例中，目标时间对应的业务数据完成持久化之后，若因故障或其他原因需要对相应时段对应的业务数据进行恢复，即接收到业务数据恢复指令之后，应先基于业务数据恢复指令对应的恢复时间，找出与该恢复时间对应的待恢复的持久化数据文件，恢复时间为需要将业务数据回溯到的时间，例如恢复时间为9月2号0：30，那么应恢复截止到9月2号0：30的业务数据，从而基于找出的待恢复文件进行业务数据恢复。其中，持久化数据文件对应有该文件中所存储数据的业务时间，可以每个持久化数据文件对应的业务时间查找与恢复时间匹配的持久化数据文件，例如恢复时间为9月2号1：30，基于持久化文件对应的业务时间查找到当天0：00
‑
1：00对应的rdb快照文件以及1：00
‑
2：00对应的aof增量文件，那么可以先对rdb快照文件进行恢复，然后再恢复aof增量文件中0：30之前的数据。
96.具体地，若持久化数据文件为rdb快照文件，则恢复方式为：调用rdb load函数，提取rdb快照文件中的业务数据，并将提取的业务数据写入内存中，从而将快照文件rdb中的数据恢复至内存。若持久化数据文件为aof增量文件，则恢复方式为：提取增量文件中的写入指令，根据写入指令将写入指令对应的数据恢复至内存中。
97.进一步的，作为图1方法的具体实现，本申请实施例提供了一种内存数据的持久化装置，如图3所示，该装置包括：
98.持久化方式获取模块31，用于获取目标时间对应的业务数据持久化方式，其中，业务数据持久化方式与目标时间对应的历史参照时间的业务数据特征匹配；
99.第一持久化模块32，用于若业务数据持久化方式为快照文件方式，则调用分叉函数fork创建子进程，以及通过子进程将内存中已有的业务数据写入快照文件中，得到与目标时间对应的持久化文件；
100.第二持久化模块33，用于若业务数据持久化方式为增量文件方式，则当有更新数据写入内存时，将更新数据对应的写入指令顺序添加至增量文件中，得到与目标时间对应的持久化文件。
101.在具体的应用场景中，如图4所示，该装置还包括：
102.数据特征获取模块34，用于获取目标时间对应的业务数据持久化方式之前，获取与目标时间对应的历史参照时间，以及与历史参照时间对应的业务数据特征，其中，业务数据特征存储于区块链中，业务数据特征包括但不限于历史参照时间内产生的业务数据对应的重要数据占比、读写次数以及数据集大小；
103.持久化方式确定模块35，用于基于预设数据持久化特征规则，确定与业务数据特征匹配的业务数据持久化方式，其中，预设数据持久化特征规则包括与快照文件方式对应的第一特征规则以及与增量文件方式对应的第二特征规则。
104.在具体的应用场景中，如图4所示，数据特征获取模块34，具体包括：
105.业务类型统计单元341，用于当业务数据特征包括重要数据占比时，分别获取历史
参照时间内的每一条业务数据的业务类型标识，并统计历史参照时间内全部业务数据中预设重要业务类型的数据量，其中，业务类型标识包括但不限于每一条业务数据的key值；
106.重要数据占比确定单元342，用于基于预设重要业务类型的数据量，确定预设重要业务类型的业务数据占全部业务数据的比重，将比重作为重要数据占比。
107.在具体的应用场景中，如图4所示，该装置还包括：
108.恢复指令接收模块36，用于得到与目标时间对应的持久化数据文件之后，接收业务数据恢复指令，其中，业务数据恢复指令包括恢复时间；
109.持久化文件获取模块37，用于获取与恢复时间对应的待恢复的持久化数据文件；
110.数据恢复模块38，用于按照与待恢复的持久化数据文件对应的时间先后顺序，依次恢复待恢复的持久化数据文件。
111.在具体的应用场景中，如图4所示，持久化方式确定模块31，具体用于：若业务数据特征与第一特征以及第二特征均不匹配，则确定业务数据持久化方式为混合方式；
112.在具体的应用场景中，如图4所示，该装置还包括：
113.增量文件添加模块39，用于若目标时间对应的业务数据持久化方式为混合方式，则当有更新数据需要写入内存时，将更新数据对应的写入指令顺序添加至增量文件中；
114.快照文件写入模块30，用于当增量文件的大小大于或等于预设阈值时，将内存中已有的数据添加至快照文件中，并清空增量文件。
115.需要说明的是，本申请实施例提供的一种内存数据的持久化装置所涉及各功能单元的其他相应描述，可以参考图1至图2方法中的对应描述，在此不再赘述。
116.基于上述如图1至图2所示方法，相应的，本申请实施例还提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述如图1至图2所示的内存数据的持久化方法。
117.基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd
‑
rom，u盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。
118.基于上述如图1至图2所示的方法，以及图3至图4所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种计算机设备，具体可以为个人计算机、服务器、网络设备等，该计算机设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1至图2所示的内存数据的持久化方法。
119.可选地，该计算机设备还可以包括用户接口、网络接口、摄像头、射频(radio frequency，rf)电路，传感器、音频电路、wi
‑
fi模块等等。用户接口可以包括显示屏(display)、输入单元比如键盘(keyboard)等，可选用户接口还可以包括usb接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如蓝牙接口、wi
‑
fi接口)等。
120.本领域技术人员可以理解，本实施例提供的一种计算机设备结构并不构成对该计算机设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。
121.存储介质中还可以包括操作系统、网络通信模块。操作系统是管理和保存计算机设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与该实体设备中其它硬件和软件之间
通信。
122.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现通过获取目标时间对应的业务数据持久化方式，从而按照相应的业务数据持久化方式对数据库中相应目标时间对应的业务数据进行持久化得到持久化数据文件，实现对内存数据的持久化处理，其中，业务数据持久化方式基于目标时间相应的历史参考时间的业务数据特征确定，使得对目标时间的业务数据持久化方式与历史参考时间对应的业务数据特征相匹配。本申请实施例相比于现有技术中技术人员指定一种持久化策略的方式，通过对历史参照时间的业务数据的数据特征进行统计分析从而确定目标时间对应的业务数据持久化方式，使得目标时间的业务数据持久化方式与该时间段对应的业务数据的数据特征相匹配，从而自动选择一种更贴近目标时段业务数据特征的持久化方式，解决了持久化方式需要人工确定缺乏理论依据、持久化方式与业务数据特征不匹配从而导致的业务数据丢失、持久化数据文件过大等问题。
123.本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
124.上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。