CN111898158B - 一种ofd文档的加密方法 - Google Patents

Abstract

本申请公开了一种OFD文档的加密方法，包括：从5个进程中选出1个进程作为主进程执行加密操作，其余进程待命；5个进程同时加密；若第一进程率先完成加密，就向其余4个进程分别发送选主进程的通知，其余4个进程收到第一进程的通知之后，暂停加密测速，发送确认信号给第一进程；第一进程收集确认信号并累计个数N；第一进程将N分别发给其余进程；第一进程在执行加密任务的同时，向其余进程分别定时发送一个“正在工作”的状态标识，其余进程收到状态标识之后认定第一进程处于“活跃“状态，保持待命状态。本申请的OFD文档的加密方法，采用了多进程的加密模式，提高了加密的容错率，避免单进程模式出现的问题，能够保证不间断的提供加密服务。

Description

一种OFD文档的加密方法

技术领域

本申请涉及电子文档技术领域，具体涉及一种OFD文档的加密方法。

背景技术

在应用OFD文档技术的领域中，常用的OFD加密方式一般是启动一个进程对OFD文档进行加密，具体过程描述如下：

1.前端发送加密指令。

2.后台启动一个提供加密服务的进程。

3.后台进程等待接收加密OFD文档的指令。

4.后台进程接收到指令后，开始加密OFD文档。

5.后台进程加密完成后，等待下一个加密指令。

6.将加密的OFD发送给前端。

此加密方式是一个单循环的过程，比较简单，见图1。

该技术采用单进程模式，虽然比较简单，但容错率低，一旦进程“假死”，后台将无法提供加密服务，导致前台没有响应，只能通过人工方式重启进程，不及时，不能做到用户无感知，因此用户体验极差。同时，维护成本也会提升，需要抽出运维人员来维护。

发明内容

本申请的目的是提供一种OFD文档的加密方法。为了对披露的实施例的一些方面有一个基本的理解，下面给出了简单的概括。该概括部分不是泛泛评述，也不是要确定关键/重要组成元素或描绘这些实施例的保护范围。其唯一目的是用简单的形式呈现一些概念，以此作为后面的详细说明的序言。

根据本申请实施例的一个方面，提供一种OFD文档的加密方法，包括：

采用5个进程，从所述5个进程中选出1个进程作为主进程执行加密操作，另外4个进程待命。

进一步地，所述从所述5个进程中选出1个进程作为主进程执行加密操作，包括：

所述5个进程同时加密；所述5个进程包括第一进程、第二进程、第三进程、第四进程和第五进程；

若第一进程率先完成加密，就向其余4个进程分别发送选主进程的通知，第二进程、第三进程、第四进程、第五进程收到第一进程的通知之后，暂停加密测速，发送确认信号给第一进程；

第一进程将收集第二进程、第三进程、第四进程、第五进程的确认信号，并累计确认信号的个数，记为N；

第一进程将N分别发给第二进程、第三进程、第四进程、第五进程，第二进程收到N后，若N＞＝3，则确认节点候选成功，并进入待命状态；第三进程收到N后，若N＞＝3，则确认第一进程候选成功，并进入待命状态；第四进程收到N后，若N＞＝3，则确认第一进程候选成功，并进入待命状态；第五进程收到N后，若N＞＝3，则确认第一进程候选成功，并进入待命状态；

至此，第一进程候选成功，进程开始执行加密任务；第一进程在执行加密任务的同时，向其余4个进程分别定时发送一个“正在工作”的状态标识，4个进程收到状态标识之后认定第一进程处于“活跃“状态，依然保持待命状态。

进一步地，所述方法还包括：

如果候选进程运行中进入了“假死”状态，也就是候选进程变成了“僵尸”进程，将无法再执行加密工作，此时，其余4个进程无法再收到第一进程“正在工作”的状态标识，那么4个进程开始进程加密测速，重新选出一个主进程。

进一步地，所述重新选出一个主进程，包括：

若第三进程首先完成加密，那么第三进程向第二进程、第四进程、第五进程分别发送选主进程的通知，第二进程、第四进程、第五进程收到通知后，暂停加密测速，并发送确认信号给第三进程。

第三进程收到其余所有进程的确认信号之后，累计确认信号个数，并将个数分别发送给其余所有进程，其余进程收到个数后，分别判断个数是否大于2，若大于2，则确认第三进程候选成功，第三进程则开始执行加密任务，其他进程进入待命状态，同样，第三进程在执行加密任务的同时，向其余3个进程分别定时发送一个“正在工作”的状态标识，3个进程收到状态标识之后认定第三进程处于“活跃”状态，依然保持待命状态。

进一步地，所述方法还包括：

若第二进程、第四进程率先完成加密测速，那么第二进程和第四进程之间不允许互相发送选主进程的通知；

第二进程向第一进程、第三进程、第五进程发送选主进程的通知，第一进程、第三进程、第五进程收到通知后向第二进程发送确认信号，第二进程收到后累计确认信号数量。

第四进程向第一进程、第三进程、第五进程发送主进程通知，第一进程、第三进程、第五进程收到通知后向第四进程发送确认信号，第四进程收到后累计确认信号数量。

进一步地，所述方法还包括：如果只有4个进程进行选主进程且出现2个以上进程同时完成加密测速的情况，则无法竞选成功，需要重新开始加密测速，开始新一轮选主进程。

进一步地，所述新一轮选主进程，包括：将4个进程分别记为第一进程、第二进程、第三进程、第四进程；

若第一进程、第二进程率先完成加密测速，由于第一进程和第二进程都是候选者，那么第一进程和第二进程之间不允许互相发送选主进程的通知；

第一进程向第三进程、第四进程发送选主进程的通知，第三进程、第四进程收到通知后会向第一进程发送确认信号，第一进程收到后，累计确认信号数量，总数为2，将确认信号数量分别发给其余2个进程，第三进程和第四进程收到确认信号数量之后，发现确认数量未超过总进程个数的一半，那么第一进程候选未成功。

同理，第二进程候选也未成功。

由于第一进程和第二进程都未候选成功，则所有进程重新开始加密测速，开始新一轮的选主进程。

根据本申请实施例的另一个方面，提供一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现上述的OFD文档的加密方法。

根据本申请实施例的另一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以实现上述的OFD文档的加密方法。

本申请实施例的其中一个方面提供的技术方案可以包括以下有益效果：

本申请实施例提供的OFD文档的加密方法，采用了多进程的加密模式，提高了加密的容错率，避免单进程模式出现的问题，能够保证不间断的提供加密服务。

本申请的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者，部分特征和优点可以从说明书中推知或毫无疑义地确定，或者通过实施本申请实施例了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

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

图1示出了现有技术的OFD加密方式的流程图；

图2示出了本申请一个实施例中的选出一个进程对一组数据执行加密的过程示意图；

图3示出了本申请一个实施例中的主进程向待命进程发送状态标识的示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，下面结合附图和具体实施例对本申请做进一步说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

如图1所示，本申请的一个实施例提供了一种OFD文档的加密方法，包括：

采用5个进程，从所述5个进程中选出1个进程作为主进程执行加密操作，另外4个进程待命。

为了避免单进程可能带来了的“假死”问题，本申请采用5个进程对OFD文档进行加密，并通过共识的方式选出1个进程作为主进程执行加密工作，另外4个进程待命。

为了更好的描述，将5个进程分别记为进程1、进程2、进程3、进程4、进程5。下面描述一下如何选出一个进程对一组数据执行加密的过程，见图2、图3：

1)后台启动5个进程，这5个进程同时加密该数据，加密算法采用对称加密，算法一般采用AES、SM4等算法，注意这5个进程都不是恶意进程，是完全可信任的。

2)若进程1率先完成加密，就会向其余4个进程分别发送选主进程的通知(参考图2所示)，进程2、进程3、进程4、进程5收到进程1的通知之后，暂停加密测速，发送确认信号给进程1；

3)进程1将收集进程2、进程3、进程4、进程5的确认信号，并累计确认信号的个数，记为N；

4)进程1将N分别发给进程2、进程3、进程4、进程5，进程2收到N后，若N＞＝3，则确认节点候选成功，并进入待命状态；进程3收到N后，若N＞＝3，则确认进程1候选成功，并进入待命状态，进程4收到N后，若N＞＝3，则确认进程1候选成功，并进入待命状态，进程5收到N后，若N＞＝3，则确认进程1候选成功，并进入待命状态；

5)至此，进程1候选成功，进程开始执行加密任务。如图3所示，进程1在执行加密任务的同时，向其余4个进程分别定时发送一个“正在工作”的状态标识，4个进程收到状态标识之后认定进程1处于“活跃“状态，依然保持待命状态。

上面描述的是正常运行的过程，如果候选进程运行中进入了“假死”状态，也就是候选进程变成了“僵尸”进程，将无法再执行加密工作，此时，其余4个进程无法再收到进程1“正在工作”的状态标识，那么4个进程开始进程加密测速，重新选出一个主进程，步骤如下：

1)若进程3首先完成加密，那么进程3向进程2、进程4、进程5分别发送选主进程的通知，进程2、进程4、进程5收到通知后，暂停加密测速，并发送确认信号给进程3。

2)进程3收到其余所有进程的确认信号之后，累计确认信号个数，并将个数分别发送给其余所有进程，其余进程收到个数后，分别判断个数是否大于2，若大于2，则确认进程3候选成功，进程3则开始执行加密任务，其他进程进入待命状态，同样，进程3在执行加密任务的同时，向其余3个进程分别定时发送一个“正在工作”的状态标识，3个进程收到状态标识之后认定进程3处于“活跃”状态，依然保持待命状态。

另外，处于“假死”状态的进程1重启之后，会直接进入待命状态，等待下一轮的候选。

5个进程中如果出现2个以上进程同时完成加密测速的情况，主进程竞选具体过程如下：

1)若进程2、进程4率先完成加密测速，由于进程2和进程4都是候选者，那么进程2和进程4之间不允许互相发送选主进程的通知；

2)进程2向进程1、进程3、进程5发送选主进程的通知，进程1、进程3、进程5收到通知后会向进程2发送确认信号，进程2收到后累计确认信号数量。

3)与此同时，进程4向进程1、进程3、进程5发送主进程通知，进程1、进程3、进程5收到通知后会向进程4发送确认信号，进程4收到后累计确认信号数量。

4)由于进程2和进程4票数相等，无法候选成功，则需要重新开始加密测速，开始新一轮的选主进程的过程。

如果只有4个进程进行选主且出现2个以上进程同时完成加密测速的情况，则无法竞选成功，需要重新开始加密测速，开始新一轮选主进程的过程。4个进程分别记为进程1、进程2、进程3、进程4、具体过程描述如下：

1)若进程1、进程2率先完成加密测速，由于进程1和进程2都是候选者，那么进程1和进程2之间不允许互相发送选主进程的通知；

2)进程1向进程3、进程4发送选主进程的通知，进程3、进程4收到通知后会向进程1发送确认信号，进程1收到后，累计确认信号数量，总数为2，将确认信号数量分别发给其余2个进程，进程3和进程4收到确认信号数量之后，发现确认数量未超过总进程个数(数值为4)的一半，那么进程1候选未成功。

3)同理，进程2候选也未成功。

4)由于进程1和进程2都未候选成功，则所有进程重新开始加密测速，开始新一轮的选主进程的过程。

综上所述，采用了一种选择一个进程执行加密任务的共识算法，主要优势在于提高了加密的容错率，避免单进程模式出现的问题，能够保证不间断的提供加密服务。

本申请实施例采用了多进程的加密模式，利用共识算法选择加密进程的主进程，在主进程出现“假死”状态后，再利用共识算法从其他待命进程中重新选出主进程，避免了一个进程出现“假死”而导致的加密任务失败现象，提高了加密服务的容错率，为用户实现了稳定不间断的提供加密服务，提升了用户体验，且因无需人工重启，节约了运维成本。

需要说明的是：

术语“模块”并非意图受限于特定物理形式。取决于具体应用，模块可以实现为硬件、固件、软件和/或其组合。此外，不同的模块可以共享公共组件或甚至由相同组件实现。不同模块之间可以存在或不存在清楚的界限。

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述实施例仅表达了本申请的实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (6)

1.一种OFD文档的加密方法，其特征在于，包括：

采用5个进程，从所述5个进程中选出1个进程作为主进程执行加密操作，另外4个进程待命；

所述从所述5个进程中选出1个进程作为主进程执行加密操作，包括：

所述5个进程同时加密；所述5个进程包括第一进程、第二进程、第三进程、第四进程和第五进程；

若第一进程率先完成加密，就向其余4个进程分别发送选主进程的通知，第二进程、第三进程、第四进程、第五进程收到第一进程的通知之后，暂停加密测速，发送确认信号给第一进程；

第一进程将收集第二进程、第三进程、第四进程、第五进程的确认信号，并累计确认信号的个数，记为N；

第一进程将N分别发给第二进程、第三进程、第四进程、第五进程，第二进程收到N后，若N＞＝3，则确认节点候选成功，并进入待命状态；第三进程收到N后，若N＞＝3，则确认第一进程候选成功，并进入待命状态；第四进程收到N后，若N＞＝3，则确认第一进程候选成功，并进入待命状态；第五进程收到N后，若N＞＝3，则确认第一进程候选成功，并进入待命状态；

至此，第一进程候选成功，进程开始执行加密任务；第一进程在执行加密任务的同时，向其余4个进程分别定时发送一个“正在工作”的状态标识，4个进程收到状态标识之后认定第一进程处于“活跃“状态，依然保持待命状态；

所述方法还包括：

如果候选进程运行中进入了“假死”状态，也就是候选进程变成了“僵尸”进程，将无法再执行加密工作，此时，其余4个进程无法再收到第一进程“正在工作”的状态标识，那么4个进程开始进程加密测速，重新选出一个主进程；

所述重新选出一个主进程，包括：

若第三进程首先完成加密，那么第三进程向第二进程、第四进程、第五进程分别发送选主进程的通知，第二进程、第四进程、第五进程收到通知后，暂停加密测速，并发送确认信号给第三进程；

第三进程收到其余所有进程的确认信号之后，累计确认信号个数，并将个数分别发送给其余所有进程，其余进程收到个数后，分别判断个数是否大于2，若大于2，则确认第三进程候选成功，第三进程则开始执行加密任务，其他进程进入待命状态，同样，第三进程在执行加密任务的同时，向其余3个进程分别定时发送一个“正在工作”的状态标识，3个进程收到状态标识之后认定第三进程处于“活跃”状态，依然保持待命状态。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若第二进程、第四进程率先完成加密测速，那么第二进程和第四进程之间不允许互相发送选主进程的通知；

第二进程向第一进程、第三进程、第五进程发送选主进程的通知，第一进程、第三进程、第五进程收到通知后向第二进程发送确认信号，第二进程收到后累计确认信号数量；

第四进程向第一进程、第三进程、第五进程发送主进程通知，第一进程、第三进程、第五进程收到通知后向第四进程发送确认信号，第四进程收到后累计确认信号数量。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：如果只有4个进程进行选主进程且出现2个以上进程同时完成加密测速的情况，则无法竞选成功，需要重新开始加密测速，开始新一轮选主进程。

4.根据权利要求3所述的方法，其特征在于，所述新一轮选主进程，包括：将4个进程分别记为第一进程、第二进程、第三进程、第四进程；

若第一进程、第二进程率先完成加密测速，由于第一进程和第二进程都是候选者，那么第一进程和第二进程之间不允许互相发送选主进程的通知；

第一进程向第三进程、第四进程发送选主进程的通知，第三进程、第四进程收到通知后会向第一进程发送确认信号，第一进程收到后，累计确认信号数量，总数为2，将确认信号数量分别发给其余2个进程，第三进程和第四进程收到确认信号数量之后，发现确认数量未超过总进程个数的一半，那么第一进程候选未成功；

同理，第二进程候选也未成功；

由于第一进程和第二进程都未候选成功，则所有进程重新开始加密测速，开始新一轮的选主进程。

5.一种电子设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如权利要求1-4中任一所述的方法。

6.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行，以实现如权利要求1-4中任一所述的方法。