数据持久化方法、移动终端及计算机可读存储介质

技术领域

本申请涉及数据持久化领域，特别是涉及一种数据持久化方法、移动终端及计算机可读存储介质。

背景技术

在关系型数据库领域，数据的原子性(Atomicity，A)、一致性(Consistency，C)、隔离性(Isolation，I)以及持久性(Durability，D)是数据库管理系统在写入或更新资料过程中，为保证事务的正确可靠所必须具有的四个特性(ACID)。

在操作系统中，往往保存在内存中的数据是处于瞬时状态的，而保存在存储设备中的数据是处于持久状态的。数据持久化就是将内存中的瞬时数据保存到存储设备中，因为存储设备上设置有数据库，数据持久化实际也就是把数据从内存保存到数据库中，以保证即使在手机或电脑关机的情况下，防止数据丢失，使得在应用程序或机器重启后可以继续访问之前保存的数据。

目前，在把数据从内存保存到数据库的过程中，瞬时数据从内存冲刷到存储设备上需要时间，而数据库处理能力有限，在对同一目标文件持久化请求数量非常多的情况下，数据库在对持久化请求进行处理的时候往往存在还来不及处理前一个持久化请求的情况，从而导致内存中的数据和/或数据对应的索引关系丢失，进而使得无法对数据进行持久化保存。

发明内容

本申请实施例的第一方面提供了一种数据持久化方法，该方法包括：获取第一数据持久化请求以及与第一数据持久化请求相关联的第二数据持久化请求，其中，相关联的多个数据持久化请求用于请求对同一目标文件进行持久化操作；将获取的第一数据持久化请求以及第二数据持久化请求加入到请求队列中；在确定第一数据持久化请求和第二数据持久化请求相关联时，对第一数据持久化请求和第二数据持久化请求进行合并，得到第三数据持久化请求；对第三数据持久化请求进行处理。

本申请实施例的第二方面提供了一种移动终端，包括：获取模块，用于获取第一数据持久化请求以及与第一数据持久化请求相关联的第二数据持久化请求，其中，相关联的多个数据持久化请求用于请求对同一目标文件进行持久化操作；加入模块，连接获取模块，用于将获取的第一数据持久化请求以及第二数据持久化请求加入到请求队列中；处理模块，连接加入模块，用于在确定第一数据持久化请求和第二数据持久化请求相关联时，对第一数据持久化请求和第二数据持久化请求进行合并，得到第三数据持久化请求；处理模块还用于对第三数据持久化请求进行处理。

本申请实施例的第三方面提供了一种移动终端，包括：处理器和存储器，存储器中存储有计算机程序，处理器用于执行所述计算机程序以实现本申请实施例第一方面以及本申请实施例第二方面的定制方法。

本申请实施例的第四方面提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，计算机程序能够被处理器执行时实现本申请实施例第一方面以及本申请实施例第二方面提供的方法。

本申请的有益效果是：区别于相关技术的情况，本申请针对将内存中的数据保存至数据库的过程中可能丢失数据的情况，将获取同一目标文件相关联的多个数据持久化请求加入到请求队列中；并对请求队列中的多个数据持久化请求进行合并处理，以将与数据持久化请求对应的同一目标文件保存至数据库中。通过上述方式，本申请能够有效地将多个数据持久化请求对应的同一目标文件保存至数据库中，从而降低了数据和/或数据对应的索引关系丢失风险。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请数据持久化方法第一实施例的流程示意图；

图2是图1中步骤S13一具体实施例的流程示意图；

图3是图1中步骤S14一具体实施例的流程示意图；

图4是图3中步骤S31一具体实施例的流程示意图；

图5是图3中步骤S32一具体实施例的流程示意图；

图6是普通数据库事务持久化方法以及本申请数据持久化方法对比示意图；

图7是本申请数据持久化方法的异步合并过程中的一致性保证示意图；

图8是本申请的移动终端一实施例的示意框图；

图9是本申请的移动终端另一实施例的示意框图；

图10是本申请的计算机可读存储介质一实施例的示意框图；

图11是本申请移动终端的硬件架构的示意框图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。本申请提供一种数据持久化方法，请参阅图1，图1是本申请数据持久化方法第一实施例的流程示意图。该方法包括以下具体步骤：

S11：获取第一数据持久化请求以及与第一数据持久化请求相关联的第二数据持久化请求；

一般来说，将数据从内存中保存到数据库中的过程中，往往会设置保存按钮，例如当用户按下或触碰保存按钮，可以使得数据库获取数据持久化的请求，以将数据进行保存。其中，数据库包括SQLite数据库、Oracle数据库、DB2数据库以及Informix数据库中的至少一种，本申请以SQLite数据库为例。

其中，数据持久化请求，就是用于请求对目标文件进行持久化操作，也即将内存的数据冲刷保存到磁盘上。其中，持久性指事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

当然针对本申请的数据持久化过程，还可以通过其他请求触发条件来根据数据库的状态实现获取数据持久化请求，例如异步线程进行实时监控、按照数据量触发等等。

针对于同一目标文件，往往对同一目标文件的保存存在相关联的多个数据持久化的请求，其中，相关联的多个数据持久化请求用于请求对同一目标文件进行持久化操作。因此若想要对同一目标文件进行持久化，则可以获取第一数据持久化请求以及与第一数据持久化请求相关联的第二数据持久化请求。

S12：将获取的第一数据持久化请求以及第二数据持久请求加入到请求队列中；

在保存内存数据到数据库的过程中，为了追求极致的性能，数据库设置有异步线程以及请求队列，通过异步线程可以将获取的数据持久化请求放入请求队列中，其中，该请求队列中可以存放多个数据持久化请求，而这些数据持久化请求相互之间可以关联存在。

因此，可以将获取的第一数据持久化请求以及第二数据持久请求加入到请求队列中：一般来说，第一数据持久化请求以及第二数据持久请求可以进行排序，比如先将第一数据持久化请求放入请求队列中，然后再把第二数据持久请求放入请求队列中。当然，也可以先将第二数据持久化请求放入请求队列中，然后再把第一数据持久请求放入请求队列中，具体并不做限定。

通过合理地对数据持久化请求进行排序，从而确定数据持久化请求的正常读取，进而可以实现数据库对数据持久化对应的目标文件进行有效保存操作，使得数据库的性能提高。

S13：在确定第一数据持久化请求和第二数据持久化请求相关联时，对第一数据持久化请求和第二数据持久化请求进行合并，得到第三数据持久化请求。

当确定请求队列中的确有与第一数据持久化请求相关联的第二数据持久化请求，也就是说要在检查点持久化操作时执行第二数据持久化请求对应的目标文件进行保存，如果依然是先处理第一数据持久化请求，然后才是处理第二数据持久化请求，这样会存在数据持久化请求紊乱的情况，此情况会在后面的具体实施例中进行详细描述，因为违反了持久化顺序，第二数据持久化请求实际上是已经覆盖了第一数据持久化请求，所以会导致异常发生后上一个检查点到这一次检查点的数据库内容丢失。

因此，可以将第一数据持久化请求和第二数据持久化请求进行合并，以得到第三数据持久化请求，从而实现对第一数据持久化请求以及第二数据持久化请求的及时处理。

S14：对第三数据持久化请求进行处理。

由于I/O处理过程较为耗时，数据库通常可以牺牲一定的持久性要求提供更好的事务处理性能。例如：SQLite数据库在WAL日志模式下可以通过将同步模式(synchronousmode)从全部(full)为普通(normal)关闭WAL日志文件的持久化操作，只保留数据库文件检查点操作时的持久化动作。但是这样在一定程度上牺牲了持久性，存在致异常情况发生时数据丢失的情况。

因此，在步骤S13中，将第一数据持久化请求和第二数据持久化请求进行合并，从而得到第三数据持久化请求，从而将I/O处理过程所需要耗费的时间缩短，使得同一目标文件的持久化请求得以及时有效地处理以保存至数据库中，从而降低了数据丢失风险。

本申请实施例第一方面针对将内存中的数据保存至数据库的过程中可能丢失数据的情况，将获取同一目标文件相关联的多个数据持久化请求加入到请求队列中；并对请求队列中的多个数据持久化请求进行合并处理，以将与数据持久化请求对应的同一目标文件保存至数据库中。通过上述方式，本申请能够有效地将多个数据持久化请求对应的同一目标文件保存至数据库中，从而降低了数据和/或数据对应的索引关系丢失风险。

具体地，在请求队列中的数据量达到预设持久化事件需求时，对请求队列中的第三数据持久化请求进行处理，以将与所述第三数据持久化请求对应的目标文件保存至数据库中。

值得注意的是，这里的预设持久化事件需求指的是否有事物持久化事件，如果有事物持久化事件存在，则可以判定满足预设持久化时间需求。比如自行配置是1000个4K数据(表示一个预设持久化事件需求)才保存一次，也即是根据负载量4M来保存一次，其中一个文件页对应的数据量所占内存是4K；再比如1个文件页表示一个预设持久化事件需求，当然也可以自行设置多个文件页表示一个预设持久化事件需求。满足预设持久化时间需求时则保存一次，也即事务持久化一次，相当于事件是实时保存。虽然不能说数据真正的实时保存，但对于预设持久化事件需求来说，持久化事件是实时保存的。

更进一步地，当数据持久化请求放入请求队列中，异步线程还可以按顺序将数据持久化请求进行依次执行，从而对据库对数据持久化对应的目标文件进行有效保存。

为了改善数据库的吞吐性能，可以通过异步线程实时对请求队列中的数据持久化请求进行处理，以将与数据持久化请求对应的目标文件保存至数据库中，其中，异步线程中，如果A线程要请求某个资源，但是此资源正在被B线程使用中，因为没有同步机制存在，A线程仍然请求的到，A线程无需等待。

当然，除了通过异步线程的方式可以对满足预设持久化事件需求时对请求队列中的数据持久化请求进行处理，此外，当数据库设置是实时同步线程时，比如A线程要请求某个资源，但是此资源正在被B线程使用中，因为同步机制存在，A线程请求不到，A线程只需等待比较短的时间即可进行处理。当然，本领域技术人员可以通过本领域公知的其他方式来针对持久化事件实时对请求队列中的数据持久化请求进行处理。

因此，本申请针对将内存中的数据保存至数据库的过程中可能丢失数据的情况，将获取的数据持久化请求加入到请求队列中；在请求队列中的数据量达到预设持久化事件需求时，对请求队列中的数据持久化请求进行处理，以将与数据持久化请求对应的目标文件保存至数据库中，缩小了数据持久化请求提交后到数据真正持久化中间发生异常崩溃造成数据丢失的风险时间窗口。通过上述方式，本申请能够有效地将数据持久化请求对应的目标文件保存至数据库中，从而降低了目标文件因系统崩溃等异常情况而发生的数据丢失风险。

更进一步地，图1中步骤S13中的在请求队列中的数据量达到预设持久化事件需求时，对请求队列中的数据持久化请求进行处理，可以包括：在请求队列中的数据量达到预设持久化事件需求时，对请求队列中位于请求队列首端的第一数据持久化请求进行处理。具体地，请参阅图2，图2是图1中步骤S13一具体实施例的流程示意图，具体包括以下步骤：

S21：确定第一数据持久化请求位于请求队列的首端；

一般来说，持久化请求的异步合并方法首先要保证异常崩溃发生时异步的写能同步到存储设备。对于系统崩溃和有备用电源的掉电场景，在异常发生时都有一段时间可以进行异常处理。通过限制异步请求完成持久化所需时间可以保证异常发生时的数据库持久性，在超过限制时阻塞新的数据库事务提交异步请求即可。

在请求队列中的数据量达到预设持久化事件需求时，对请求队列中的数据持久化请求进行处理的过程中，需要确定请求队列里的数据持久化请求的情况，比如确定请求队列中有位于请求队列首端的第一数据持久化请求，以此作为一个处理数据持久化请求的基准点，通过位于请求队列首端的第一数据持久化请求作为基准点，可以有效地维持数据持久化请求次序的正确读取，从而降低读取数据持久化请求出错的风险。

S22：判断请求队列中是否有与第一数据持久化请求相关联的第二数据持久化请求；

由于预设持久化事件是实时的，满足预设持久化事件需求时对请求队列中的数据持久化请求进行处理，因此，请求队列中的数据持久化请求非常多，比如在异步线程中，有多个持久化请求，比如10个、100个或者1000个，因此，第二数据持久化请求也可能是多个数据持久化请求。目标文件数据从内存冲刷到磁盘上需要时间，而数据库处理能力有限，存在还来不及处理前一个持久化请求的情况，通过放置在新增的队列中，可以提升数据库的处理能力。

通常，具体保存内存数据到数据库的过程中，通用的数据库事务实现方式为预写日志(Write Ahead Logging，WAL)，即在修改数据库文件内容前要确保这些修改已经记录到日志中。事务记录持久化到日志文件后即认为事务提交成功，在日志文件积累了一定数量修改后需将日志内容更新回数据库文件，这个过程被称为检查点操作(checkpoint)。如系统出现掉电等崩溃行为可以通过日志恢复数据库。如系统出现掉电等崩溃行为可以通过日志恢复数据库。

对于不同的数据持久化请求，进行的保存操作不同，比如对于没有关联的数据持久化请求，数据持久化请求与数据持久化满足预设持久化事件的实时需求，而检查点持久化的时间间隔并不改变，而对于有关联的数据持久化请求，如果检查点持久化清除或合并了请求队列中的所有日志文件的数据持久化请求，则检查点持久化操作时执行事务持久化，也即数据持久化请求对应的目标文件的持久化保存。所以需要判断请求队列中是否有与第一数据持久化请求相关联的第二数据持久化请求，其中，相关联的多个数据持久化请求用于请求对同一目标文件进行持久化操作，这在重I/O负载下，对降低数据库的尾部时延有较大帮助。

S23：对第一数据持久化请求和第二数据持久化请求进行合并，得到第三数据持久化请求；

当判断到请求队列中的确有与第一数据持久化请求相关联的第二数据持久化请求，也就是说要在检查点持久化操作时执行第二数据持久化请求对应的目标文件进行保存，如果依然是先处理第一数据持久化请求，然后才是处理第二数据持久化请求，这样会存在数据持久化请求紊乱的情况，此情况会在后面的具体实施例中进行详细描述，因为违反了持久化顺序，第二数据持久化请求实际上是已经覆盖了第一数据持久化请求，所以会导致异常发生后上一个检查点到这一次检查点的数据库内容丢失。

因此，一方面可以通过清除第一数据持久化请求来避免异常保存的情况发生，另一方面还可以将第一数据持久化请求和第二数据持久化请求进行合并，以得到第三数据持久化请求，从而实现对第一数据持久化请求以及第二数据持久化请求的及时处理。

S24：对第三数据持久化请求进行处理。

具体地，对第三数据持久化请求进行处理，请参阅图3，图3是图1中步骤S14一具体实施例的流程示意图，具体包括以下步骤：

S31：基于异步线程判断请求队列是否存在第三数据持久化请求；

有上述图1的步骤S12可知，数据库设置有异步线程以及请求队列，当将第一数据持久化请求和第二数据持久化请求进行合并，得到第三数据持久化请求，可以基于异步线程判断请求队列是否存在第三数据持久化请求以进行进一步的验证，以提升方案的可实现性。

若确定存在第三数据持久化请求，则进入步骤S32：通过持久化请求接口对数据持久化请求对应的目标文件的进行保存；若确定不存在第三数据持久化请求，则进入步骤S33：判定请求队列中没有与第一数据持久化请求相关联的第二数据持久化请求。

基于异步线程判断请求队列是否存在第三数据持久化请求，请参阅图4，图4是图3中步骤S31一具体实施例的流程示意图，具体包括以下步骤：

S41：判断请求队列是否为空；

当请求队列里的数据持久化请求是相互关联时，对第一数据持久化请求相关联的第二数据持久化请求进行合并，也就意味着，得到的第三数据持久化请求为目前请求队列中单独的一个数据持久化请求，因此，通过对请球队里进行判断，可以得知是否存在第三数据持久化请求。

若请求队列为空，则进入步骤S42：则确定不存在第三数据持久化请求；若请求队列不为空，则进入步骤S43：则确定存在第三数据持久化请求。

在本步骤中，还可以通过限定时间段来判定和检测请求队列里的数据持久化请求个数，以便进行针对性的处理，提高数据库处理效率，当然，本领域技术人员还可以通过本领域公知的其他方式来对请求队列是否存在第三数据持久化请求进行检测判断。

若存在第三数据持久化请求，则通过持久化请求接口对第三数据持久化请求对应的目标文件进行保存，请参阅图5，图5是图3中步骤S32一具体实施例的流程示意图，具体包括以下步骤：

S51：基于持久化请求接口调用持久化请求函数；

通常，为保证日志文件及数据库文件的持久性，数据库需要调用底层提供的同步手段，如：文件系统的持久化请求接口，也即fsync接口。持久化请求接口可以调用持久化请求函数，持久化请求函数可以用于将与数据持久化请求对应的目标文件进行持久化。

S52：通过持久化请求函数检测目标文件保存到数据库中的进程是否完成；

持久化请求函数预设有具体多种持久化处理进程的函数值，比如设置1表示与数据持久化请求对应的目标文件持久化完成，而设置0表示与数据持久化请求对应的目标文件持久化失败，还可以设置目标文件丢失所对应的预设函数值等等，具体此处不做限定，可以根据需求进行选择或设置。数据库中设置有日志文本，若持久化也即保存失败，则可以将具体的失败原因记录下来，并写道日志文本中，以便查找具体原因。

具体地，通过持久化请求函数检测目标文件保存到数据库中的进程是否完成，可以确定出若完成，则进入步骤S53：向数据库反馈目标文件保存完成对应的第一预设函数值；若未完成，则进入步骤S54：向数据库反馈目标文件保存未完成对应的第二预设函数值，并将第二预设函数值写进日志文本以实现记录。

由于本申请涉及的技术的应用场景广泛，在本申请中，具体地可以以一个典型的场景是广泛使用SQLite数据库的智能移动终端上的应用为例，请参阅图6以及图7，图6是普通数据库事务持久化方法以及本申请数据持久化方法对比示意图；图7是本申请数据持久化方法的异步合并过程中的一致性保证示意图。下文将结合具体的应用场景对本申请的数据持久化方法进行详细描述。

目前，持久化请求的异步合并方法首先要保证异常崩溃发生时异步的写能同步到存储设备。其中系统异常崩溃，比如：断电、死机等，异常情况会导致数据丢失、数据库不一致。对于系统崩溃和有备用电源的掉电场景，在异常发生时都有一段时间可以进行异常处理。通过限制异步请求完成持久化所需时间可以保证异常发生时的数据库持久性，在超过限制时阻塞新的数据库事务提交异步请求即可。下面主要介绍异步、合并的实现和异步合并过程的一致性处理。

一、异步合并方法的实现

持久化请求被放入请求队列中，异步线程按顺序依次执行持久化请求。对比SQLite数据库的normal同步模式，异步合并方法通过异步线程实现对日志文件和数据库文件的持久化。在异步线程执行前的新持久化请求(fsync)会和之前的同一文件持久化请求合并。

通常来说，一个SQLite数据库会有一个日志文件和数据库文件，在一段时间内对日志文件或数据库文件的fsync请求可能有多个，本申请的方案可以通过合并将这些针对同一文件的多个数据持久化请求进行处理。这里的文件指的就是有多个相同fsync请求的日志文件或数据库文件。

如图6所示，normal同步模式中，假如有1至5个事务提交，需要等待一固定预设时长才能在检查点对该5个事务提交进行检查。而本申请方案中，在事务提交时，就执行事务持久化，相当于对目标文件实现了实时保存，异步合并的优势是缩小了事务提交后到事务真正持久化中间发生异常崩溃造成数据丢失的风险时间窗口，当然，崩溃任何时间都可以发生，图6意在说明本方案的优势：缩小了风险时间窗口，避免了数据内容的丢失，并且检查点过程中对日志文件和数据库文件的持久化也得以异步化。

二、异步合并的一致性处理

本方案在对持久化请求的异步合并过程中，需要考虑数据库的一致性，避免数据库出现不一致的状态。主要是在检查点前后需要保证一致性，这可以通过保证日志文件和数据库文件的落盘顺序得以保证。具体规则为：当检查点过程中像队列中加入数据库文件持久化请求时要清除队列中的所有日志文件的持久化请求。

具体地，原因如下图7所示，持久化请求队列中有请求1、请求2，请求3，其中请求1是检查点过程中对WAL日志文件的fsync请求，请求2是检查点过程中对数据库文件的fsync请求，请求3是检查点过程后对WAL日志文件的又一次fsync请求。其中，请求1与请求2之间存在索引关系。因为上述规则考虑的场景为内存中检查点已完成、日志文件已被清除，而存储上数据库状态还未持久化请求1。此时执行日志文件的持久化实际上完成的是请求3，这违反了请求2和请求3的持久化顺序会导致异常发生后上一个检查点到这一次检查点的数据库内容丢失。也就是说，若在请求1和请求2持久化过程中，对请求3进行事务提交，可能导致两个丢失，一是索引关系丢失，二是请求1、请求2分别对应的数据内容以及请求3对应的数据内容都丢失。因此，通过事务持久化确定日志文件和数据库文件的落盘顺序，可以确定内存中请求队列的顺序，从而避免数据库内容丢失。

其中，持久化请求的合并，请求队列里是有两部分，持久化请求和持久化请求索引的数据内容，比如：写一句话，发送第一持久化请求，放在了队列里，再写一段话，发送第二持久化请求，此第一持久化请求以及第二持久化请求进行异步合并；放在了队列(新增)，这时还没有从内存中冲刷到磁盘上，要第一持久化请求以及第二持久化请求进行异步合并后，进行统一冲刷保存到磁盘上。由于时间段较短，因为在异步线程中，有多个持久化请求，比如100个，保存数据从内存冲刷到磁盘上需要时间，数据库处理能力有限，存在还来不及处理前一个持久化请求的情况，通过放置在新增的队列中，可以提升数据库的处理能力。在图7中，检查点如果清除了队列中的所有日志文件的持久化请求，则检查点持久化的操作中执行事务持久化。

因此，本技术方案为使用WAL模式日志的数据库提供了一套完整的持久化请求同步方法，在保证持久性的同时大幅提升了数据库处理能力，极大地改善了数据库的插入、更新、删除等写操作的吞吐性能，对数据库事务在重I/O负载下的尾部时延降低有较大帮助。

本技术方案提出了针对数据库WAL日志文件和数据库文件的持久化请求异步合并方法，在提升事务处理性能的同时通过对异常崩溃情况进行保护处理以保证持久性。在持久化请求异步合并的过程中，需要保证日志文件和数据库文件持久化请求的落盘顺序以保证数据库的一致性。

值得注意的是，上述方案中，异步合并的实现方法中的请求队列可以替换为任何可以缓冲并保留请求顺序的数据结构，异常保护方法中限制缓存的异步持久化请求完成所需时间可扩展为在检测到可预期的高风险后关闭后续持久化请求的异步合并。

请参阅图8，图8是本申请的移动终端一实施例的示意框图。本申请实施例提供了一种移动终端6，包括：

获取模块61，用于获取第一数据持久化请求以及与第一数据持久化请求相关联的第二数据持久化请求，其中，相关联的多个数据持久化请求用于请求对同一目标文件进行持久化操作；

加入模块62，用于连接获取模块61，用于将获取的第一数据持久化请求以及第二数据持久化请求加入到请求队列中；

处理模块63，连接加入模块62，用于在确定第一数据持久化请求和第二数据持久化请求相关联时，对第一数据持久化请求和第二数据持久化请求进行合并，得到第三数据持久化请求；并且处理模块63还用于对第三数据持久化请求进行处理。

因此，本申请针对将内存中的数据保存至数据库的过程中可能丢失数据的情况，加入模块62将获取模块61获取的同一目标文件相关联的多个数据持久化请求加入到请求队列中；处理模块63对请求队列中的多个数据持久化请求进行合并处理，以将与数据持久化请求对应的同一目标文件保存至数据库中，缩小了数据持久化请求提交后到数据真正持久化中间发生异常崩溃造成数据丢失的风险时间窗口。通过上述方式，本申请能够有效地将数据持久化请求对应的目标文件保存至数据库中，从而降低了对同一目标文件因数据库处理不及时等情况而发生的数据和/或数据对应的索引关系丢失风险。

进一步地，请参见图9，图9是本申请移动终端另一实施例的示意图。本申请实施例提供另一种移动终端7，包括：处理器71和存储器72，存储器72中存储有计算机程序721，处理器71用于执行计算机程序721以本申请实施例第一方面以及本申请实施例第二方面的定制方法，在此不再赘述。

请参阅图10，图10是本申请的计算机可读存储介质一实施例的示意框图。如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在计算机可读存储介质80中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储装置中，包括若干指令(计算机程序81)用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式方法的全部或部分步骤。而前述的存储装置包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种介质以及具有上述存储介质的电脑、手机、笔记本电脑、平板电脑、相机等电子设备。

关于计算机可读存储介质中的计算机程序的执行过程的阐述可以参照上述本申请移动终端80的方法实施例中阐述，在此不再赘述。

请参阅图11，图11是本申请移动终端的硬件架构的示意框图，该移动终端900可以为手机、平板电脑以及笔记本电脑等，本实施例图示以手机为例。该可移动终端900的结构可以包括射频(radio frequency，RF)电路910、存储器920、输入单元930、显示单元940、传感器950、音频电路960、WiFi(wireless fidelity)模块970、处理器980以及电源990等。其中，RF电路910、存储器920、输入单元930、显示单元940、传感器950、音频电路960以及WiFi模块970分别与处理器980连接；电源990用于为整个移动终端900提供电能。

具体而言，RF电路910用于接发信号；存储器920用于存储数据指令信息；输入单元930用于输入信息，具体可以包括触控面板931以及操作按键等其他输入设备932；显示单元940则可以包括显示面板等；传感器950包括红外传感器、激光传感器等，用于检测用户接近信号、距离信号等；扬声器961以及传声器(或者麦克风)962通过音频电路960与处理器980连接，用于接发声音信号；WiFi模块970则用于接收和发射WiFi信号，处理器980用于处理移动终端的数据信息。

以上所述仅为本申请的部分实施例，并非因此限制本申请的保护范围，凡是利用本申请说明书及附图内容所作的等效装置或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。