文件读写方法、装置和系统与流程

本申请涉及WebIDE(WebIDE是一类让用户可以在页面上编辑代码的网页)开发技术领域，尤其涉及一种文件读写方法、装置和系统。

背景技术：

GIT(分布式版本控制系统)和SVN(Subversion，开放源代码的版本控制系统)是开发过程中常用的文件版本控制工具，常用于团队开发任务中，但是这两种工具对系统、环境以及命令熟练度的要求比较高，造成开发人员在使用时开发效率低。

目前，已经有部分WebIDE开发环境(例如国内的Coding.net)让开发人员可以在浏览器中编写并提交代码文件，以解决操作成本高带来的效率低的问题。例如，一些多人协同开发的系统采用的是客户端缓存的方法，即多个开发人员分别在自己的客户端缓存中记录对同一个文件的操作，然后将自己的缓存操作提交到服务器，服务器获取各个客户端的缓存操作后将其合并为一个完整的操作，再对文件进行更新。然而，该方案存在以下问题：

(1)开发人员对文件的读写权限并没有妥善被控制，由于可以在多个浏览器中打开同一个文件进行编写，或者多个开发人员打开同一个文件进行编写，因此在同一时间对于同一个文件而言可能会存在被不同的开发人员打开并写入不同的内容的情况，导致在多个不同的开发人员编写后提交文件时文件的内容存在冲突，或者是文件的内容出现相互覆盖的情况，严重限制了多个开发人员在多人协作开发中的发挥；

(2)客户端需要有缓存，且需要有足够的权限操作缓存系统，例如ios系统对用户权限做严格控制，或者用户手动关闭了权限，开发人员便会无法进行操作；

(3)文件修改的内容都保存在客户端，如果开发人员修改了数据但还没来得及提交到服务器，此时用户切换客户端就会造成数据丢失；

(4)所有的操作数据都存储在客户端缓存，开发人员如果有权限即可随意修改缓存数据，安全性差。

申请内容

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请的第一个目的在于提出一种文件读写方法，该文件读写方法。

本申请的第二个目的在于提出一种文件读写装置。

本申请的第三个目的在于提出一种文件读写系统。

为达上述目的，本申请第一方面实施例提出了一种文件读写方法，包括以下步骤：接收访问请求，并根据所述访问请求获取文件标识信息和第一用户标识信息；在缓存服务器中查询所述文件标识信息对应的锁定文件，如果未查询到所述文件标识信息对应的锁定文件，则从文件服务器获取所述文件标识信息对应的第一原始文件；根据所述第一用户标识信息和所述第一原始文件生成锁定文件，并将所述锁定文件提交至所述缓存服务器；以及接收针对所述第一原始文件的编辑操作，并将编辑后的第一原始文件提交至所述缓存服务器，以使所述缓存服务器根据所述编辑后的第一原始文件对所述锁定文件进行更新。

本申请实施例的文件读写方法，通过缓存服务器实现了适用于WebIDE系统的文件锁定机制，利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲，使用缓存机制实现文件的锁定，从而使得用户在对文件操作的过程中拥有文件的独享操作权，避免了多个用户对同一个文件操作时提交的内容互相冲突，使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外，使用缓存机制实现文件的锁定，比每次都修改文件服务器的数据库相比成本更低，且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等，给用户更好的体验。

为达上述目的，本申请第二方面实施例提出了一种文件读写装置，包括：第一接收模块，用于接收访问请求；第一获取模块，用户根据所述访问请求获取文件标识信息和第一用户标识信息；查询模块，用于在缓存服务器中查询所述文件标识信息对应的锁定文件；第二获取模块，用于当所述查询模块未查询到所述文件标识信息对应的锁定文件时，从文件服务器获取所述文件标识信息对应的第一原始文件；生成模块，用于根据所述第一用户标识信息和所述第一原始文件生成锁定文件；提交模块，用于将所述锁定文件提交至所述缓存服务器；以及第二接收模块，用于接收针对所述第一原始文件的编辑操作，其中，所述提交模块将编辑后的第一原始文件提交至所述缓存服务器，以使所述缓存服务器根据所述编辑后的第一原始文件对所述锁定文件进行更新。

本申请实施例的文件读写装置，通过缓存服务器实现了适用于WebIDE系统的文件锁定机制，利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲，使用缓存机制实现文件的锁定，从而使得用户在对文件操作的过程中拥有文件的独享操作权，避免了多个用户对同一个文件操作时提交的内容互相冲突，使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外，使用缓存机制实现文件的锁定，比每次都修改文件服务器的数据库相比成本更低，且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等，给用户更好的体验。

为达上述目的，本申请第三方面实施例提出了一种文件读写系统，包括：WebIDE服务器、缓存服务器和文件服务器，其中，所述WebIDE服务器用于接收访问请求，并根据所述访问请求获取文件标识信息和第一用户标识信息，以及在缓存服务器中查询所述文件标识信息对应的锁定文件，如果未查询到所述文件标识信息对应的锁定文件，则从文件服务器获取所述文件标识信息对应的第一原始文件，并根据所述第一用户标识信息和所述第一原始文件生成锁定文件，并将所述锁定文件提交至所述缓存服务器，以及接收针对所述第一原始文件的编辑操作，并将编辑后的第一原始文件提交至所述缓存服务器；以及所述缓存服务器用于存储所述锁定文件，并根据所述编辑后的第一原始文件对所述锁定文件进行更新。

本申请实施例的文件读写系统，通过缓存服务器实现了适用于WebIDE系统的文件锁定机制，利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲，使用缓存机制实现文件的锁定，从而使得用户在对文件操作的过程中拥有文件的独享操作权，避免了多个用户对同一个文件操作时提交的内容互相冲突，使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外，使用缓存机制实现文件的锁定，比每次都修改文件服务器的数据库相比成本更低，且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等，给用户更好的体验。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是本申请一个实施例的文件读写方法的流程图；

图2是本申请一个具体实施例的文件读写方法的流程图；

图3是本申请另一个具体实施例的文件读写方法的流程图；

图4是本申请另一个具体实施例的文件读写方法的流程图；

图5是本申请另一个具体实施例的文件读写方法的流程图；

图6是本申请一个实施例的文件读写装置的结构示意图；

图7是本申请一个具体实施例的文件读写装置的结构示意图；以及

图8是本申请一个实施例的文件读写装置的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

图1是本申请一个实施例的文件读写方法的流程图。

如图1所示，文件读写方法包括：

S101，接收访问请求，并根据访问请求获取文件标识信息和第一用户标识信息。

在本申请的实施例中，包括WebIDE服务器、缓存服务器以及文件服务器。其中，WebIDE服务器可以提供编辑文件的用户界面、执行缓存服务器中的操作、或者是和缓存服务器以及文件服务器进行交互。文件服务器用于存储文件的代码文件，例如，GIT服务器用于存储GIT文件的代码文件，SVN服务器用于存储SVN文件的代码文件。而缓存服务器则是使用缓存机制来实现存储锁定的文件，例如，可以是noSql缓存服务器，也可以是Redis、Tair或者其它缓存服务器。

应当理解的是，WebIDE服务器、缓存服务器以及文件服务器可以是单个的服务器，也可以是由多个服务器组成的服务器集群。

具体地，WebIDE服务器接收用户A发送的访问某个文件的访问请求，并获取该文件的文件标识信息以及用户A的用户标识信息。其中，文件标识信息用于在服务器端查询该文件的唯一标识，例如，文件标识信息可以是文件路径、文件的MD5(Message Digest Algorithm 5，消息摘要算法第五版)等。用户标识信息是用于验证用户身份的唯一标识，例如，用户标识信息可以是用户ID(身份标识号码)等。

S102，在缓存服务器中查询文件标识信息对应的锁定文件，如果未查询到文件标识信息对应的锁定文件，则从文件服务器获取文件标识信息对应的第一原始文件。

具体地，WebIDE服务器根据文件标识信息在缓存服务器中查询是否存在与文件标识信息对应的文件，其中，该文件在缓存服务器中是处于锁定状态的，即锁定文件。也就是 说，在用户A请求访问文件时，并不直接从文件服务器获取文件，而是先在缓存服务器中查询是否存在已被锁定的文件，如果缓存服务器中不存在已被锁定的文件，则再从文件服务器获取该文件。

如果WebIDE服务器在缓存服务器中未查询到对应的锁定文件，则说明文件服务器上存储的原始文件目前处于未锁定的状态，用户A有权限从文件服务器上获取原始文件并对该原始文件加锁，因此，WebIDE服务器在文件服务器中根据文件标识信息查找到对应的原始文件，并获取该原始文件。

S103，根据第一用户标识信息和第一原始文件生成锁定文件，并将锁定文件提交至缓存服务器。

具体地，WebIDE服务器将原始文件的文件内容展现给用户A，同时根据用户A的用户标识信息锁定该原始文件，以生成包含原始文件和用户标识信息的锁定文件。然后，WebIDE服务器以文件标识信息作为锁定文件的标识，将锁定文件提交至缓存服务器进行存储。

应当理解的是，在将锁定文件存储在缓存服务器之后，如果WebIDE服务器接收到用户B发送的访问该文件的请求后，WebIDE服务器同样会以相同的方式先查询缓存服务器中是否存在该文件对应的锁定文件，如果WebIDE服务器查询到对应的锁定文件，由于缓存服务器中存在锁定文件，因此用户B在文件已被锁定的状态下不允许获取文件或者是对文件进行编辑。由此，可以避免用户A和用户B同时对文件进行编辑导致编辑的内容相互冲突的问题。

S104，接收针对第一原始文件的编辑操作，并将编辑后的第一原始文件提交至缓存服务器，以使缓存服务器根据编辑后的第一原始文件对锁定文件进行更新。

具体地，用户A可以对原始文件的文件内容进行编辑，当用户A选择保存编辑后的内容时，WebIDE服务器将编辑后的原始文件加上用户标识信息提交至缓存服务器。也就是说，WebIDE服务器将用户A编辑后的内容保存至缓存服务器的锁定文件中。

应当理解的是，WebIDE服务器从文件服务器读写文件以及将文件内容展现给用户的方式均可采用现有技术实现，例如，WebIDE服务器使用GitLab API或者Svn API实现文件的读写，使用ACE等开源JS框架实现文件内容的展现。而缓存服务器中使用的缓存，可以用SSD(Solid State Drives，固态硬盘)做缓存持久化空间，以得到更大的存储空间，或者使用Tair集群等缓存方案皆可。由于上述方案都是成熟的技术，因此，此处不再复赘。

本申请实施例的文件读写方法，通过缓存服务器实现了适用于WebIDE系统的文件锁定机制，利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲，使用缓存机制实现文件的锁定，从而使得用户在对文件操作的过程中拥有文件的独享操作权，避 免了多个用户对同一个文件操作时提交的内容互相冲突，使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外，使用缓存机制实现文件的锁定，比每次都修改文件服务器的数据库相比成本更低，且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等，给用户更好的体验。

图2是本申请一个具体实施例的文件读写方法的流程图。

如图2所示，文件读写方法包括：

S201，接收访问请求，并根据访问请求获取文件标识信息和第一用户标识信息。

S202，在缓存服务器中查询文件标识信息对应的锁定文件，如果未查询到文件标识信息对应的锁定文件，则从文件服务器获取文件标识信息对应的第一原始文件。

S203，如果查询到文件标识信息对应的锁定文件，则判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配，若第一用户标识信息与第二用户标识信息匹配，则从缓存服务器中获取锁定文件。

具体地，如果WebIDE服务器在缓存服务器中查询到对应的锁定文件，则说明文件服务器上存储的原始文件目前处于锁定的状态，则WebIDE服务器获取锁定文件的用户标识信息，并判断用户A的用户标识信息和锁定文件的用户标识信息是否匹配，如果用户A的用户标识信息和锁定文件的用户标识信息匹配，则WebIDE服务器判断用户A有权限获取锁定文件并进行编辑。

应当理解的是，在用户A读取到锁定文件后，该锁定文件在缓存服务器中仍然继续保持锁定状态。

在本申请的一个实施例中，若第一用户标识信息与第二用户标识信息不匹配，则生成拒绝获取锁定文件的提示信息。具体地，如果是用户B访问缓存服务器中的锁定文件，则用户B的用户标识信息和锁定文件的用户标识信息不匹配，即该锁定文件是用户A锁定的，则WebIDE服务器判断用户B没有权限获取锁定文件进行编辑，生成提示提示信息提示用户B。

在本申请的一个实施例中，如果WebIDE服务器判断用户B没有权限获取锁定文件进行编辑，则WebIDE服务器可以为用户B提供一个锁定文件的副本，用户B可以对副本进行编辑，以使在用户A对锁定文件解锁后，WebIDE服务器根据用户B编辑的副本在处理副本和用户A编辑的锁定文件的冲突之后再进行提交。由此，在用户B没有对锁定文件编辑的权限时，可以为用户B提供一种更加友好的操作方式。

S204，接收针对锁定文件的编辑操作，并将编辑后的锁定文件提交至缓存服务器，以使缓存服务器根据编辑后的锁定文件对锁定文件进行更新。

具体地，WebIDE服务器将锁定文件的文件内容展现给用户A，用户A可以对文件内 容进行编辑，当用户A选择保存编辑后的内容时，WebIDE服务器将编辑后的锁定文件加上用户标识信息提交至缓存服务器。也就是说，WebIDE服务器将用户A编辑后的内容保存至缓存服务器的锁定文件中。

应当理解的是，由于缓存服务器中缓存文件的持久化特性，用户A在缓存服务器中存储的锁定文件会被持久保持，当用户A从一个客户端切换至另一个客户端时，可以根据用户A的用户表示信息和文件标识信息再次读取缓存服务器中的锁定文件进行编辑。

图3是本申请另一个具体实施例的文件读写方法的流程图。

如图3所示，文件读写方法包括：

S301，接收访问请求，并根据访问请求获取文件标识信息和第一用户标识信息。

S302，在缓存服务器中查询文件标识信息对应的锁定文件，如果未查询到文件标识信息对应的锁定文件，则从文件服务器获取文件标识信息对应的第一原始文件。

S303，根据第一用户标识信息和第一原始文件生成锁定文件，并将锁定文件提交至缓存服务器。

S304，接收针对第一原始文件的编辑操作，并将编辑后的第一原始文件提交至缓存服务器，以使缓存服务器根据编辑后的第一原始文件对锁定文件进行更新。

S305，从文件服务器获取第二原始文件，并判断缓存服务器中锁定文件的第一提交信息与第二原始文件的第二提交信息是否匹配，如果第一提交信息与第二提交信息匹配，则将锁定文件提交至文件服务器，以使文件服务器将第二原始文件替换为锁定文件。

具体地，WebIDE服务器根据用户A编辑的内容对缓存服务器中的锁定文件更新后，从文件服务器再次获取文件服务器中保存的原始文件，并从获取该原始文件的提交信息，如果缓存服务器中锁定文件的提交信息和文件服务器中原始文件的提交信息匹配，则WebIDE服务器将更新后的锁定文件异步提交至文件服务器，将文件服务器中的原始文件替换为更新后的锁定文件。

S306，如果第一提交信息与第二提交信息不匹配，则根据第二原始文件对锁定文件进行更新，并根据第二提交信息更新第一提交信息，以及将更新后的锁定文件提交至文件服务器。

具体地，如果缓存服务器中锁定文件的提交信息和文件服务器中原始文件的提交信息不匹配，说明文件服务器中原始文件已经被更新，例如，用户通过文件服务器的客户端对原始文件进行了更新，则WebIDE服务器将锁定文件的内容保存为副本，并获取原始文件的内容，根据原始文件的内容对锁定文件的内容进行更新。在用户A在解决锁定文件的内容和原始文件的内容之间的冲突之后，WebIDE服务器将缓存服务器中的锁定文件的提交信息更新为文件服务器中原始文件的提交信息。然后，WebIDE服务器将更新后的锁定文 件异步提交至文件服务器，将文件服务器中的原始文件替换为更新后的锁定文件。

图4是本申请另一个具体实施例的文件读写方法的流程图。

如图4所示，文件读写方法包括：

S401，接收访问请求，并根据访问请求获取文件标识信息和第一用户标识信息。

S402，在缓存服务器中查询文件标识信息对应的锁定文件，如果未查询到文件标识信息对应的锁定文件，则从文件服务器获取文件标识信息对应的第一原始文件。

S403，如果查询到文件标识信息对应的锁定文件，则判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配，若第一用户标识信息与第二用户标识信息匹配，则从缓存服务器中获取锁定文件。

S404，接收针对锁定文件的编辑操作，并将编辑后的锁定文件提交至缓存服务器，以使缓存服务器根据编辑后的锁定文件对锁定文件进行更新。

S405，接收针对缓存服务器中锁定文件的解锁请求，并在判断第一用户标识信息与锁定文件对应的第二用户标识信息匹配时，从缓存服务器中删除锁定文件。

具体地，在用户A对锁定文件编辑完成之后，用户A可以发送对锁定文件进行解锁的请求，WebIDE服务器在接收到用户A发送的解锁请求后，提示用户即将对锁定文件解锁，并提示用户是否在解锁前将锁定文件提交至文件服务器中。在用户A确认对锁定文件解锁之后，根据文件标识信息在缓存服务器中查找到对应的锁定文件，并判断锁定文件对应的用户标识信息是否和用户A的用户标识信息匹配。如果锁定文件对应的用户标识信息和用户A的用户标识信息匹配，则WebIDE服务器从缓存服务器中删除该锁定文件。

应当理解的是，在锁定文件从缓存服务器删除之后，如果用户B请求访问文件，则WebIDE服务器则进一步根据步骤S401-S404的方法为用户B提供单独操作文件的独享操作权。

图5是本申请另一个具体实施例的文件读写方法的流程图。

如图5所示，文件读写方法包括：

S501，接收访问请求，并根据访问请求获取文件标识信息和第一用户标识信息。

S502，在缓存服务器中查询文件标识信息对应的锁定文件，如果未查询到文件标识信息对应的锁定文件，则从文件服务器获取文件标识信息对应的第一原始文件。

S503，如果查询到文件标识信息对应的锁定文件，则判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配，若第一用户标识信息与第二用户标识信息匹配，则从缓存服务器中获取锁定文件。

S504，若第一用户标识信息与第二用户标识信息不匹配，则生成拒绝获取锁定文件的提示信息。

S505，接收针对第二用户标识信息的替换请求，并根据替换请求将第二用户标识信息替换为第一用户标识信息，以及生成第二用户标识信息被替换的提示信息。

具体地，如果用户B没有权限获取锁定文件进行编辑，而用户B又急需对锁定文件进行编辑，此时该文件被用户A锁定，则用户B可以选择抢锁，直接将具有锁定文件的读写权限的用户A变为用户B具有权限。也就是说，用户B发送对缓存服务器中锁定文件所对应的用户标识信息的替换请求，WebIDE服务器在接收到用户B发送的替换请求后，将锁定文件的用户标识信息替换为用户B的用户标识信息，并生成锁定文件的用户标识信息被替换的提示信息以提示用户A。

S506，接收针对锁定文件的编辑操作，并将编辑后的锁定文件提交至缓存服务器，以使缓存服务器根据编辑后的锁定文件对锁定文件进行更新。

具体地，WebIDE服务器将锁定文件的文件内容展现给用户B，用户B可以对文件内容进行编辑，当用户B选择保存编辑后的内容时，WebIDE服务器将编辑后的锁定文件加上用户B的用户标识信息提交至缓存服务器。也就是说，WebIDE服务器将用户B编辑后的内容保存至缓存服务器的锁定文件中。

本申请实施例的文件读写方法，为用户提供文件锁定、文件解锁和抢锁等功能，解决了多人协同开发时提交的内容互相冲突、互相覆盖的问题，同时使用缓存服务器保存锁定文件可以解决多个WebIDE服务器中信息不同步的问题，使得多人协同开发时能够充分发挥快速、不受环境限制的优势。

为了实现上述实施例，本申请还提出一种文件读写装置。

图6是本申请一个实施例的文件读写装置的结构示意图，如图6所示，文件读写装置包括：第一接收模块101、第一获取模块102、查询模块103、第二获取模块104、生成模块105、提交模块106和第二接收模块107。

具体地，第一接收模块101用于接收访问请求。第一获取模块102用户根据访问请求获取文件标识信息和第一用户标识信息。具体而言，第一接收模块101接收用户A发送的访问某个文件的访问请求，第一获取模块102获取该文件的文件标识信息以及用户A的用户标识信息。其中，文件标识信息用于在服务器端查询该文件的唯一标识，例如，文件标识信息可以是文件路径、文件的MD5等。用户标识信息是用于验证用户身份的唯一标识，例如，用户标识信息可以是用户ID等。

查询模块103用于在缓存服务器中查询文件标识信息对应的锁定文件。第二获取模块104用于当查询模块103未查询到文件标识信息对应的锁定文件时，从文件服务器获取文件标识信息对应的第一原始文件。具体而言，查询模块103根据文件标识信息在缓存服务器中查询是否存在与文件标识信息对应的文件，其中，该文件在缓存服务器中是处于锁定 状态的，即锁定文件。也就是说，在用户A请求访问文件时，并不直接从文件服务器获取文件，而是先在缓存服务器中查询是否存在已被锁定的文件，如果缓存服务器中不存在已被锁定的文件，则再从文件服务器获取该文件。如果查询模块103在缓存服务器中未查询到对应的锁定文件，则说明文件服务器上存储的原始文件目前处于未锁定的状态，用户A有权限从文件服务器上获取原始文件并对该原始文件加锁，因此，第二获取模块104在文件服务器中根据文件标识信息查找到对应的原始文件，并获取该原始文件。

生成模块105用于根据第一用户标识信息和第一原始文件生成锁定文件。提交模块106用于将锁定文件提交至缓存服务器。具体而言，生成模块105将原始文件的文件内容展现给用户A，同时生成模块105根据用户A的用户标识信息锁定该原始文件，以生成包含原始文件和用户标识信息的锁定文件。然后，提交模块106以文件标识信息作为锁定文件的标识，将锁定文件提交至缓存服务器进行存储。

第二接收模块107用于接收针对第一原始文件的编辑操作，其中，提交模块106将编辑后的第一原始文件提交至缓存服务器，以使缓存服务器根据编辑后的第一原始文件对锁定文件进行更新。具体地，用户A可以对原始文件的文件内容进行编辑，当用户A选择保存编辑后的内容时，第二接收模块107接收用户的编辑操作，提交模块106将编辑后的原始文件加上用户标识信息提交至缓存服务器。也就是说，将用户A编辑后的内容保存至缓存服务器的锁定文件中。

本申请实施例的文件读写装置，通过缓存服务器实现了适用于WebIDE系统的文件锁定机制，利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲，使用缓存机制实现文件的锁定，从而使得用户在对文件操作的过程中拥有文件的独享操作权，避免了多个用户对同一个文件操作时提交的内容互相冲突，使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外，使用缓存机制实现文件的锁定，比每次都修改文件服务器的数据库相比成本更低，且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等，给用户更好的体验。

图7是本申请一个具体实施例的文件读写装置的结构示意图，如图7所示，文件读写装置包括：第一接收模块101、第一获取模块102、查询模块103、第二获取模块104、生成模块105、提交模块106、第二接收模块107、第一判断模块108、第一提示模块109、第二判断模块110、更新模块111、第三接收模块112、解锁模块113、第四接收模块114、替换模块115和第二提示模块116。

具体地，第一判断模块108用于当查询模块103查询到文件标识信息对应的锁定文件时，判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配。第二获取模块104还用于当第一判断模块108判断第一用户标识信息与第二用户标识信息匹配时，从缓 存服务器中获取锁定文件。具体地，如果查询模块103在缓存服务器中查询到对应的锁定文件，则说明文件服务器上存储的原始文件目前处于锁定的状态，则获取锁定文件的用户标识信息，第一判断模块108判断用户A的用户标识信息和锁定文件的用户标识信息是否匹配，如果第一判断模块108判断用户A的用户标识信息和锁定文件的用户标识信息匹配，则用户A有权限获取锁定文件并进行编辑，因此，第二获取模块104从缓存服务器中获取锁定文件。

第一提示模块109用于当第一判断模块108判断第一用户标识信息与第二用户标识信息不匹配时，生成拒绝获取锁定文件的提示信息。具体地，如果是用户B访问缓存服务器中的锁定文件，则第一判断模块108判断用户B的用户标识信息和锁定文件的用户标识信息不匹配，即该锁定文件是用户A锁定的，则第一判断模块108判断用户B没有权限获取锁定文件进行编辑，第一提示模块109生成提示提示信息提示用户B。

在本申请的一个实施例中，文件读写装置还包括第二判断模块110和更新模块111。其中，第二获取模块104还用于从文件服务器获取第二原始文件。第二判断模块110用于判断缓存服务器中锁定文件的第一提交信息与第二原始文件的第二提交信息是否匹配。提交模块106还用于当第二判断模块110判断第一提交信息与第二提交信息匹配时，将锁定文件提交至文件服务器，以使文件服务器将第二原始文件替换为锁定文件。具体地，提交模块106根据用户A编辑的内容对缓存服务器中的锁定文件更新后，第二获取模块104从文件服务器再次获取文件服务器中保存的原始文件，并从获取该原始文件的提交信息，如果第二判断模块110判断缓存服务器中锁定文件的提交信息和文件服务器中原始文件的提交信息匹配，则提交模块106将更新后的锁定文件异步提交至文件服务器，将文件服务器中的原始文件替换为更新后的锁定文件。

更新模块111用于当第二判断模块110判断第一提交信息与第二提交信息不匹配时，根据第二原始文件对锁定文件进行更新，并根据第二提交信息更新第一提交信息，其中，提交模块106还用于将更新后的锁定文件提交至文件服务器。具体地，如果第二判断模块110判断缓存服务器中锁定文件的提交信息和文件服务器中原始文件的提交信息不匹配，说明文件服务器中原始文件已经被更新，例如，用户通过文件服务器的客户端对原始文件进行了更新，则更新模块111将锁定文件的内容保存为副本，并获取原始文件的内容，根据原始文件的内容对锁定文件的内容进行更新。在用户A在解决锁定文件的内容和原始文件的内容之间的冲突之后，提交模块106将缓存服务器中的锁定文件的提交信息更新为文件服务器中原始文件的提交信息。然后，提交模块106将更新后的锁定文件异步提交至文件服务器，将文件服务器中的原始文件替换为更新后的锁定文件。

在本申请的一个实施例中，文件读写装置还包括第三接收模块112和解锁模块113。其 中，第三接收模块112用于接收针对缓存服务器中锁定文件的解锁请求。解锁模块113用于在第一判断模块108判断第一用户标识信息与锁定文件对应的第二用户标识信息匹配时，从缓存服务器中删除锁定文件。具体而言，具体地，在用户A对锁定文件编辑完成之后，用户A可以发送对锁定文件进行解锁的请求，第三接收模块112在接收到用户A发送的解锁请求后，提示用户即将对锁定文件解锁，并提示用户是否在解锁前将锁定文件提交至文件服务器中。在用户A确认对锁定文件解锁之后，第一判断模块108根据文件标识信息在缓存服务器中查找到对应的锁定文件，并判断锁定文件对应的用户标识信息是否和用户A的用户标识信息匹配。如果第一判断模块108判断锁定文件对应的用户标识信息和用户A的用户标识信息匹配，则解锁模块113从缓存服务器中删除该锁定文件。

在本申请的一个实施例中，文件读写装置还包括第四接收模块114、替换模块115和第二提示模块116。其中，第四接收模块114用于接收针对第二用户标识信息的替换请求。替换模块115用于根据替换请求将第二用户标识信息替换为第一用户标识信息。第二提示模块116用于生成第二用户标识信息被替换的提示信息。具体地，如果用户B没有权限获取锁定文件进行编辑，而用户B又急需对锁定文件进行编辑，此时该文件被用户A锁定，则用户B可以选择抢锁，直接将具有锁定文件的读写权限的用户A变为用户B具有权限。也就是说，用户B发送对缓存服务器中锁定文件所对应的用户标识信息的替换请求，第四接收模块114在接收到用户B发送的替换请求后，替换模块115将锁定文件的用户标识信息替换为用户B的用户标识信息，第二提示模块116生成锁定文件的用户标识信息被替换的提示信息以提示用户A。

本申请实施例的文件读写装置，为用户提供文件锁定、文件解锁和抢锁等功能，解决了多人协同开发时提交的内容互相冲突、互相覆盖的问题，同时使用缓存服务器保存锁定文件可以解决多个WebIDE服务器中信息不同步的问题，使得多人协同开发时能够充分发挥快速、不受环境限制的优势。

为了实现上述实施例，本申请还提出一种文件读写系统。

图8是本申请一个实施例的文件读写装置的结构示意图，如图8所示，文件读写系统包括：WebIDE服务器1、缓存服务器2和文件服务器3。

具体地，WebIDE服务器1用于接收访问请求，并根据访问请求获取文件标识信息和第一用户标识信息，以及在缓存服务器2中查询文件标识信息对应的锁定文件，如果未查询到文件标识信息对应的锁定文件，则从文件服务器3获取文件标识信息对应的第一原始文件，并根据第一用户标识信息和第一原始文件生成锁定文件，并将锁定文件提交至缓存服务器2，以及接收针对第一原始文件的编辑操作，并将编辑后的第一原始文件提交至缓存服务器2；以及

缓存服务器2用于存储锁定文件，并根据编辑后的第一原始文件对锁定文件进行更新。

在本申请的一个实施例中，WebIDE服务器1还用于当查询到文件标识信息对应的锁定文件时，判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配，若第一用户标识信息与第二用户标识信息匹配，则从缓存服务器2中获取锁定文件。

在本申请的一个实施例中，WebIDE服务器1还用于当第一用户标识信息与第二用户标识信息不匹配时，生成拒绝获取锁定文件的提示信息。

在本申请的一个实施例中，文件服务器3存储有第二原始文件，其中第二原始文件为第一原始文件更新后的版本，WebIDE服务器1还用于从文件服务器3获取第二原始文件，并判断缓存服务器2中锁定文件的第一提交信息与第二原始文件的第二提交信息是否匹配，当第一提交信息与第二提交信息匹配时，将锁定文件提交至文件服务器3。文件服务器3还用于第二原始文件替换为锁定文件。

在本申请的一个实施例中，WebIDE服务器1还用于当第一提交信息与第二提交信息不匹配时，根据第二原始文件对锁定文件进行更新，并根据第二提交信息更新第一提交信息，以及将更新后的锁定文件提交至文件服务器3。文件服务器3还用于将第二原始文件替换为更新后的锁定文件。

在本申请的一个实施例中，WebIDE服务器1还用于接收针对缓存服务器2中锁定文件的解锁请求，并在判断第一用户标识信息与锁定文件对应的第二用户标识信息匹配时，从缓存服务器2中删除锁定文件。

在本申请的一个实施例中，WebIDE服务器1还用于接收针对第二用户标识信息的替换请求，并根据替换请求将第二用户标识信息替换为第一用户标识信息，以及生成第二用户标识信息被替换的提示信息。

另外，根据本申请实施例的文件读写系统实现方式以及作用可以参考上述实施例中文件读写方法和文件读写装置的实现方式，为了减少冗余，此处不做赘述。

本申请实施例的文件读写系统，通过缓存服务器实现了适用于WebIDE系统的文件锁定机制，利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲，使用缓存机制实现文件的锁定，从而使得用户在对文件操作的过程中拥有文件的独享操作权，避免了多个用户对同一个文件操作时提交的内容互相冲突，使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外，使用缓存机制实现文件的锁定，比每次都修改文件服务器的数据库相比成本更低，且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等，给用户更好的体验。

进而，为用户提供文件锁定、文件解锁和抢锁等功能，解决了多人协同开发时提交的内容互相冲突、互相覆盖的问题，同时使用缓存服务器保存锁定文件可以解决多个 WebIDE服务器中信息不同步的问题，使得多人协同开发时能够充分发挥快速、不受环境限制的优势。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。