CN104202385A - 一种分布式文件系统的数据备份及更新方法 - Google Patents
一种分布式文件系统的数据备份及更新方法 Download PDFInfo
- Publication number
- CN104202385A CN104202385A CN201410426213.0A CN201410426213A CN104202385A CN 104202385 A CN104202385 A CN 104202385A CN 201410426213 A CN201410426213 A CN 201410426213A CN 104202385 A CN104202385 A CN 104202385A
- Authority
- CN
- China
- Prior art keywords
- server
- file
- file server
- resolution
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Abstract
本发明公开了一种分布式文件系统的数据备份及更新方法,旨在提供一种改进的分布式文件系统的数据备份及更新方法,以减轻客户端的网络传输压力及降低互为备份的文件服务器的数据一致性维护难度。本发明技术要点:包括客户端向解析服务器发起文件服务器上传文件请求;解析服务器为客户端指定一台文件服务器,将文件服务器上的一个有效存储路径返回给客户端;客户端按照所述存储路径将文件上传到所述文件服务器上;文件服务器接收并存储所述客户端上传的文件,并向解析服务器返回操作成功的消息;再将客户端上传的文件传输给其他文件服务器;解析服务器收到操作成功的消息后,将客户端上传文件的存储路径及文件名组合编码返回给客户端告知用户等。
Description
技术领域
本发明涉及分布式文件系统,尤其是一种分布式文件系统的数据备份及更新方法。
背景技术
随着云存储技术的发展,大量的用户访问对云端服务器的数据吞吐量和系统并发量都是一个巨大的考验。为了保证文件存储的安全性,防止云端服务器坏掉导致用户存储的文件丢失,现有技术采用了各种文件副本备份的方法。
在现有的带多文件副本存储服务器(以下简称为文件服务器)的系统中,所有的服务器上的文件副本均从客户端获取。也就是说,在上传文件到数据服务器时通过客户端与多个文件服务器直接进行通信,将文件分别上传到各个文件服务器上以实现文件备份。这样的方法存在这样的问题,所有文件服务器均从客户端同时接受数据不但对客户端的网络造成巨大的压力,文件出错的可能性也高。若有上传过程中其中一处出现网络传输错误就会请求客户端的重传,这势必造成客户端的网络拥塞,且各文件服务器中的数据一致性也很难维护。
发明内容
本发明所要解决的技术问题是:针对上述存在的问题,提供一种改进的分布式文件系统的数据备份及更新方法,以减轻客户端的网络传输压力及降低互为备份的文件服务器的数据一致性维护难度。
本发明采用的技术方案如下:
首选,本发明提供了一种分布式文件系统的数据副本互备方法,包括:
步骤1:客户端向解析服务器发起文件服务器上传文件请求;
步骤2:解析服务器为客户端指定一台文件服务器,并在所述文件服务器上生成一个包括上传时间及文件类型的文件名,然后将所述文件服务器上的一个有效存储路径返回给客户端;
步骤3:客户端按照所述存储路径将文件上传到所述文件服务器上;
步骤4:所述文件服务器接收并存储所述客户端上传的文件,并向解析服务器返回操作成功的消息;再将所述客户端上传的文件传输给其他文件服务器;
步骤5:解析服务器收到操作成功的消息后,将客户端上传文件的存储路径及文件名组合编码返回给客户端告知用户。
进一步,所述文件服务器分为多组,每个文件服务器组具有若干文件服务器,且每台文件服务器具有与其同组的其他文件服务器的地址;
解析服务器还具有每个文件服务器的实时负载信息及分组信息;
在所述步骤2中,解析服务器根据文件服务器的实时负载信息为客户端分配文件服务器;
在所述步骤4中,所述文件服务器将所述客户端上传的文件传输给与其同组的其他文件服务器;
在所述步骤5中,解析服务器收到操作成功的消息后,将客户端上传文件的分组、存储路径及文件名组合编码返回给客户端告知用户。
进一步,每个文件服务器每间隔一段时间便将包含自身分组信息及当前负载信息的心跳包发送给解析服务器;解析服务器在收到每个文件服务器发来的心跳包后,更新解析服务器存储的各个文件服务器的实时负载信息。
进一步,当解析服务器在一定时间间隔中未收到某文件服务器的心跳包时,解析服务器则判断与该文件服务器失去信号连接,解析服务器将该失联文件服务器标示为失效并通知该文件服务器同组的其他文件服务器,之后解析服务器及该组的其他文件服务器均不再与该文件服务器进行数据交互;
再判断该组中的文件服务器数量是否小于阈值Nmin:若小于阈值Nmin,解析服务器则从后备文件服务器队列中选取一台未使用的有效服务器作为替补,并将替补文件服务器的地址传给该失联文件服务器同组的其他文件服务器,将该失联文件服务器同组的其他文件服务器的地址传给替补文件服务器;所述替补文件服务器通过地址访问同组的其他文件服务器,请求文件备份;其他文件服务器收到文件备份请求后,将自身存储的文件传输给替补文件服务器;
之后,所述替补文件服务器每间隔一段时间便将包含自身当前负载信息及分组信息的心跳包发送给解析服务器;
所述解析服务器具有后备文件服务器队列中的文件服务器地址。
进一步,当解析服务器收到新的文件服务器传来的心跳包时,先根据心跳包找到新增文件服务器所在的组,再判断该组中的文件服务器数量是否小于阈值Nmin:若小于阈值Nmin,解析服务器将该新增文件服务器标示为有效并通知该文件服务器同组的其他文件服务器,解析服务器通知所述新增文件服务器更新其文件,之后新增文件服务器读取同组其他文件服务器的操作日志,将自身的操作日志与其他文件服务器的操作日志进行对比并根据对比结果更新自身存储的文件及操作日志,从而与同组其他文件服务器的文件及操作日志内容相同;
若大于阈值Nmin,解析服务器通知新增文件服务器删除其上的所有文件,并将其加入后备文件服务器队列;
所述操作日志保存有所属文件服务器上存储的文件的名称、类型及上传时间。
本发明还提供了一种分布式文件系统的数据更新方法,包括:
步骤1:用户将需要更新的文件的分组、存储路径及文件名组合编码输出给客户端;
步骤2:客户端将所述编码传输给解析服务器;
步骤3:解析服务器解析所述编码得到需要更新的文件的分组、存储路径及文件名,并将所述文件的存储路径返回给客户端;
步骤4:客户端根据存储路径访问文件存储服务器,向文件存储服务器发出文件更新请求;
步骤5:文件存储服务器验证请求,如无误则返回同意更新的消息;
步骤6:客户端收到同意更新的消息后,将新的文件副本上按照文件存储路径传给文件服务器;
步骤7:文件服务器接收、存储新的文件副本,并更新文件名中的上传时间,删除被所述新的文件副本更新掉的文件,再将所述新的文件副本传输给同组的其他文件服务器并通知其他文件服务器删除被所述新的文件副本更新掉的文件;最后文件服务器向解析服务器返回操作成功的消息;
步骤8:解析服务向客户端返回操作更新的消息;
所述文件服务器分为多组,每个文件服务器组具有若干文件服务器,且每台文件服务器具有与其同组的其他文件服务器的地址。
由于采用了上述技术方案,本发明的有益效果是:
1.本发明实现了各文件存储器之间文件的互为备份,减轻了客户端的网络压力。
2.有效降低了各文件存储器之间数据一致的维持难度。
3.当某服务器组中的服务器宕机后,能自动从后备服务器队列中挑选一台有效服务器替换掉宕机的服务器,并自动完成该组的数据备份。当宕机的服务器恢复正常时,本发明能够根据当前服务器的运行状态自动选择是否继续使用该服务器,若确定使用,自动完成该服务器的文件同步更新。进一步从硬件层面确保了数据的安全性。
综上,本发明提出的分布式文件系统数据备份及更新方法能够很好的满足其高并发、高安全的要求。
附图说明
本发明将通过例子并参照附图的方式说明,其中:
图1为分布式文件系统的结构图。
图2为本发明中上传文件具体实施例的流程图。
图3为本发明中更新文件具体实施例的流程图。
图4为本发明中替换失联文件服务器具体实施例的流程图。
图5为本发明中重连的失联文件服务器具体实施例的流程图。
具体实施方式
本说明书中公开的所有特征,或公开的所有方法或过程中的步骤,除了互相排斥的特征和/或步骤以外,均可以以任何方式组合。
本说明书中公开的任一特征,除非特别叙述,均可被其他等效或具有类似目的的替代特征加以替换。即,除非特别叙述,每个特征只是一系列等效或类似特征中的一个例子而已。
图1展示的是分布式文件系统的结构框图。包括大量的客户端、解析服务器及多个文件服务器。
本发明中,文件服务器分为多个组,每组具有一定数量的文件服务器,每台文件服务器具有与其同组的其他文件服务器的地址。
根据分布式文件系统规模确定需要配置的文件服务器组数目,各文件服务器组间相对独立,更多的文件服务器组可以更好的提升系统的并发能力。
在同一组中的文件服务器互为备份,当某台文件服务器的内容丢失后可以在其对应的组内找到该文件的备份。每组文件服务器的数量主要由系统的安全需求决定。同一组服务器的数目越多文件冗余度越高,系统储存的文件越安全,同时在一定程度上也可以提升文件的传输效率。
下面结合图2,说明基于图1的分布式文件系统的文件上传方法,包括:
步骤1:客户端向解析服务器发起文件服务器上传文件请求。
步骤2:解析服务器为客户端指定一台文件服务器,并在所述文件服务器上生成一个包括上传时间及文件类型的文件名,然后将所述文件服务器上的一个有效存储路径Lnf(location of newfile)返回给客户端。在其他实施例中,解析服务器根据各个文件服务器处理负载的情况(简称为负载信息)为客户端指定文件服务器,而每个文件服务器会定时向解析服务器发送包含其当前负载信息及分组信息的心跳包。
步骤3:客户端按照所述存储路径将文件上传到所述文件服务器上。在其他实施例中,客户端通过获取到文件服务器地址和路径后,向其发送传输数据请求,文件服务器验证请求有效后返回同意发送的消息。客户端收到同意发送的消息后将文件上传到文件服务器上。更具体的作法可以是,客户端将文件以数据块为单位发送到其中一台文件服务器,如文件服务器F1,文件服务器F1接收到数据块后通过附带的验证消息检测其正确性,若收到的数据块无错误则向同组的其他文件服务器建立一个发送请求,开始向其他文件服务器同步备份数据,而不需要其他的文件服务器再次从客户端接收相同的文件数据。
步骤4:所述文件服务器接收并存储所述客户端上传的文件,并向解析服务器返回操作成功的消息;再将所述客户端上传的文件传输给同组的其他文件服务器。
在其他实施例中也可是这样做:当文件传输完成后,若文件服务器F1验证文件完整,则将成功消息回复给解析服务器。
步骤5:解析服务器收到操作成功的消息后,将文件所属的分组、路径及文件名一起组合编码后返回给客户端,作为用户以后操作该文件的路径及凭证。由于对文件所属的分组、路径及文件名进行了编码,用户并不能获知文件存储的路径信息而直接访问文件存储器。提高了系统的安全性。
如图3,基于图1的分布式文件系统的数据更新方法包括:
步骤1:用户将需要更新的文件的分组、存储路径及文件名组合编码输出给客户端。这里所说的文件的分组是指存储该文件的文件服务器所在组。
步骤2:客户端将所述编码传输给解析服务器;
步骤3:解析服务器解析所述编码得到需要更新的文件的分组、存储路径及文件名,并将所述文件的存储路径Luf(location of update file)返回给客户端;
步骤4:客户端根据存储路径访问文件存储服务器,向文件存储服务器发出文件更新请求;
步骤5:文件存储服务器验证请求,如无误则返回同意更新的消息;
步骤6:客户端收到同意更新的消息后,将新的文件副本上按照文件存储路径传给文件服务器;
步骤7:文件服务器接收、存储新的文件副本,并更新文件名中的上传时间,删除被所述新的文件副本更新掉的文件,再将所述新的文件副本传输给同组的其他文件服务器并通知其他文件服务器删除被所述新的文件副本更新掉的文件;最后文件服务器向解析服务器返回操作成功的消息;
步骤8:解析服务向客户端返回操作更新的消息。
文件上传方法提出的某一文件服务器向同组其他文件服务器同步备份数据的实施例同样适用于本数据更新方法。
考虑到使用过程中很可能出现某一文件服务器出现故障的情况,为了保证每组的备份数量要求,需要及时使用好的服务器替换掉宕机的文件服务器。
如图4,本发明还提供了替换故障文件服务器的方法。
所有文件服务器上均配置有解析服务器的ip地址,以及与该文件服务器同组的其他文件服务器地址。所有文件服务器每过一段时间就会向解析服务器发送心跳包,其中包含该文件服务器当前的各种状态信息,最主要的就是负载信息。解析服务器通过检查心跳包来维护文件服务器的一个状态列表。
当解析服务器在一定时间间隔中未收到某文件服务器的心跳包时,解析服务器则判断与该文件服务器失去信号连接,解析服务器将该失联文件服务器标示为失效并通知该文件服务器同组的其他文件服务器,之后解析服务器及该组的其他文件服务器均不再与该文件服务器进行数据交互。
再判断该组中的文件服务器数量是否小于阈值Nmin:若小于阈值Nmin,解析服务器则从后备文件服务器队列中选取一台未使用的有效服务器FN作为坏掉的文件服务器FD的替补,并将替补文件服务器FN的地址传给该失联文件服务器FD同组的其他文件服务器,将该失联文件服务器FD同组的其他文件服务器的地址传给替补文件服务器FN;所述替补文件服务器FN通过地址访问同组的其他文件服务器,请求文件备份;其他文件服务器收到文件备份请求后,将自身存储的文件传输给替补文件服务器FN。所述解析服务器具有后备文件服务器队列中的文件服务器地址。
之后,所述替补文件服务器每间隔一段时间便将包含自身当前负载信息及分组信息的心跳包发送给解析服务器。
最后解析服务器和同组内的其他文件服务器均将替补文件服务器加入到配置列表中,使该组内的文件服务器数目保持在一个安全的阈值。
考虑到发生故障的文件服务器可能恢复正常工作,本发明还提供了一种重连恢复正常工作的文件服务器的方法。如图5,当解析服务器收到新的文件服务器传来的心跳包时,先根据心跳包找到新增文件服务器所在的组,再判断该组中的文件服务器数量是否小于阈值Nmin:若小于阈值Nmin,解析服务器将该新增文件服务器标示为有效并通知该文件服务器同组的其他文件服务器,解析服务器通知所述新增文件服务器更新其文件,之后新增文件服务器读取同组其他文件服务器的操作日志,将自身的操作日志与其他文件服务器的操作日志进行对比并根据对比结果更新自身存储的文件及操作日志,从而与同组其他文件服务器的文件及操作日志内容相同。
所述操作日志保存有所属文件服务器上存储的文件的名称、类型及上传时间。也就是说,当新增的文件服务器发现自身的操作日志内容比其他的操作日志少或者与其他操作日志不同时,则请求其他文件服务器将其没有记录信息的文件传输给它,将其他的操作日志上没有记录信息的文件删除。
若大于阈值Nmin,解析服务器通知新增文件服务器删除其上的所有文件,并将其加入后备文件服务器队列。在其他实施例中,加入后备文件服务器队列的服务器处于休眠状态,等待解析服务器将其唤醒。
本发明并不局限于前述的具体实施方式。本发明扩展到任何在本说明书中披露的新特征或任何新的组合,以及披露的任一新的方法或过程的步骤或任何新的组合。
Claims (10)
1.一种分布式文件系统的数据备份方法,其特征在于,包括:
步骤1:客户端向解析服务器发起文件服务器上传文件请求;
步骤2:解析服务器为客户端指定一台文件服务器,并在所述文件服务器上生成一个包括上传时间及文件类型的文件名,然后将所述文件服务器上的一个有效存储路径返回给客户端;
步骤3:客户端按照所述存储路径将文件上传到所述文件服务器上;
步骤4:所述文件服务器接收并存储所述客户端上传的文件,并向解析服务器返回操作成功的消息;再将所述客户端上传的文件传输给其他文件服务器;
步骤5:解析服务器收到操作成功的消息后,将客户端上传文件的存储路径及文件名组合编码返回给客户端告知用户。
2.根据权利要求1所述的一种分布式文件系统的数据备份方法,其特征在于,所述文件服务器分为多组,每个文件服务器组具有若干文件服务器,且每台文件服务器具有与其同组的其他文件服务器的地址;
解析服务器还具有每个文件服务器的实时负载信息及分组信息;
在所述步骤2中,解析服务器根据文件服务器的实时负载信息为客户端分配文件服务器;
在所述步骤4中,所述文件服务器将所述客户端上传的文件传输给与其同组的其他文件服务器;
在所述步骤5中,解析服务器收到操作成功的消息后,将客户端上传文件的分组、存储路径及文件名组合编码返回给客户端告知用户。
3.根据权利要求2所述的一种分布式文件系统的数据备份方法,其特征在于,每个文件服务器每间隔一段时间便将包含自身分组信息及当前负载信息的心跳包发送给解析服务器;解析服务器在收到每个文件服务器发来的心跳包后,更新解析服务器存储的各个文件服务器的实时负载信息。
4.根据权利要求3所述的一种分布式文件系统的数据备份方法,其特征在于,当解析服务器在一定时间间隔中未收到某文件服务器的心跳包时,解析服务器则判断与该文件服务器失去信号连接,解析服务器将该失联文件服务器标示为失效并通知该文件服务器同组的其他文件服务器,之后解析服务器及该组的其他文件服务器均不再与该文件服务器进行数据交互;
再判断该组中的文件服务器数量是否小于阈值Nmin:若小于阈值Nmin,解析服务器则从后备文件服务器队列中选取一台未使用的有效服务器作为替补,并将替补文件服务器的地址传给该失联文件服务器同组的其他文件服务器,将该失联文件服务器同组的其他文件服务器的地址传给替补文件服务器;所述替补文件服务器通过地址访问同组的其他文件服务器,请求文件备份;其他文件服务器收到文件备份请求后,将自身存储的文件传输给替补文件服务器;
之后,所述替补文件服务器每间隔一段时间便将包含自身当前负载信息及分组信息的心跳包发送给解析服务器;
所述解析服务器具有后备文件服务器队列中的文件服务器地址。
5.根据权利要求3所述的一种分布式文件系统的数据备份方法,其特征在于,当解析服务器收到新的文件服务器传来的心跳包时,先根据心跳包找到新增文件服务器所在的组,再判断该组中的文件服务器数量是否小于阈值Nmin:若小于阈值Nmin,解析服务器将该新增文件服务器标示为有效并通知该文件服务器同组的其他文件服务器,解析服务器通知所述新增文件服务器更新其文件,之后新增文件服务器读取同组其他文件服务器的操作日志,将自身的操作日志与其他文件服务器的操作日志进行对比并根据对比结果更新自身存储的文件及操作日志,从而与同组其他文件服务器的文件及操作日志内容相同;
若大于阈值Nmin,解析服务器通知新增文件服务器删除其上的所有文件,并将其加入后备文件服务器队列;
所述操作日志保存有所属文件服务器上存储的文件的名称、类型及上传时间。
6.一种分布式文件系统的数据更新方法,其特征在于,包括:
步骤1:用户将需要更新的文件的分组、存储路径及文件名组合编码输出给客户端;
步骤2:客户端将所述编码传输给解析服务器;
步骤3:解析服务器解析所述编码得到需要更新的文件的分组、存储路径及文件名,并将所述文件的存储路径返回给客户端;
步骤4:客户端根据存储路径访问文件存储服务器,向文件存储服务器发出文件更新请求;
步骤5:文件存储服务器验证请求,如无误则返回同意更新的消息;
步骤6:客户端收到同意更新的消息后,将新的文件副本上按照文件存储路径传给文件服务器;
步骤7:文件服务器接收、存储新的文件副本,并更新文件名中的上传时间,删除被所述新的文件副本更新掉的文件,再将所述新的文件副本传输给同组的其他文件服务器并通知其他文件服务器删除被所述新的文件副本更新掉的文件;最后文件服务器向解析服务器返回操作成功的消息;
步骤8:解析服务向客户端返回操作更新的消息。
7.根据权利要求6所述的一种分布式文件系统的数据更新方法,其特征在于,所述文件服务器分为多组,每个文件服务器组具有若干文件服务器,且每台文件服务器具有与其同组的其他文件服务器的地址。
8.根据权利要求7所述的一种分布式文件系统的数据更新方法,其特征在于,每个文件服务器每间隔一段时间便将包含自身分组信息及当前负载信息的心跳包发送给解析服务器;解析服务器在收到每个文件服务器发来的心跳包后,更新解析服务器存储的各个文件服务器的实时负载信息。
9.根据权利要求8所述的一种分布式文件系统的数据更新方法,其特征在于,当解析服务器在一定时间间隔中未收到某文件服务器的心跳包时,解析服务器则判断与该文件服务器失去信号连接,解析服务器将该失联文件服务器标示为失效并通知该文件服务器同组的其他文件服务器,之后解析服务器及该组的其他文件服务器均不再与该文件服务器进行数据交互;
再判断该组中的文件服务器数量是否小于阈值Nmin:若小于阈值Nmin,解析服务器则从后备文件服务器队列中选取一台未使用的有效服务器作为替补,并将替补文件服务器的地址传给该失联文件服务器同组的其他文件服务器,将该失联文件服务器同组的其他文件服务器的地址传给替补文件服务器;所述替补文件服务器通过地址访问同组的其他文件服务器,请求文件备份;其他文件服务器收到文件备份请求后,将自身存储的文件传输给替补文件服务器;
之后,所述替补文件服务器每间隔一段时间便将包含自身当前负载信息及分组信息的心跳包发送给解析服务器;
所述解析服务器具有后备文件服务器队列中的文件服务器地址。
10.根据权利要求8所述的一种分布式文件系统的数据更新方法,其特征在于,当解析服务器收到新的文件服务器传来的心跳包时,先根据心跳包找到新增文件服务器所在的组,再判断该组中的文件服务器数量是否小于阈值Nmin:若小于阈值Nmin,解析服务器将该新增文件服务器标示为有效并通知该文件服务器同组的其他文件服务器,解析服务器通知所述新增文件服务器更新其文件,之后新增文件服务器读取同组其他文件服务器的操作日志,将自身的操作日志与其他文件服务器的操作日志进行对比并根据对比结果更新自身存储的文件及操作日志,从而与同组其他文件服务器的文件及操作日志内容相同;
若大于阈值Nmin,解析服务器通知新增文件服务器删除其上的所有文件,并将其加入后备文件服务器队列;
所述操作日志保存有所属文件服务器上存储的文件的名称、类型及上传时间。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410426213.0A CN104202385A (zh) | 2014-08-27 | 2014-08-27 | 一种分布式文件系统的数据备份及更新方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410426213.0A CN104202385A (zh) | 2014-08-27 | 2014-08-27 | 一种分布式文件系统的数据备份及更新方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN104202385A true CN104202385A (zh) | 2014-12-10 |
Family
ID=52087610
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410426213.0A Pending CN104202385A (zh) | 2014-08-27 | 2014-08-27 | 一种分布式文件系统的数据备份及更新方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104202385A (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104754031A (zh) * | 2015-02-15 | 2015-07-01 | 四川长虹电器股份有限公司 | 一种上传文件的方法和空调 |
CN105187552A (zh) * | 2015-09-29 | 2015-12-23 | 北京奇艺世纪科技有限公司 | 一种文件异地灾备的方法和装置 |
CN105208078A (zh) * | 2015-08-13 | 2015-12-30 | 飞狐信息技术(天津)有限公司 | 一种文件存储系统及方法 |
CN104780211B (zh) * | 2015-04-13 | 2016-09-07 | 努比亚技术有限公司 | 数据同步方法和装置 |
CN108933803A (zh) * | 2017-05-26 | 2018-12-04 | 杭州海康威视数字技术股份有限公司 | 前端设备、云存储服务器、流数据直存方法及系统 |
CN108984560A (zh) * | 2017-06-01 | 2018-12-11 | 杭州海康威视数字技术股份有限公司 | 文件存储方法及装置 |
CN111405008A (zh) * | 2020-03-06 | 2020-07-10 | 精英数智科技股份有限公司 | 一种煤矿数据传输方法、装置及系统 |
TWI735521B (zh) * | 2017-01-24 | 2021-08-11 | 香港商阿里巴巴集團服務有限公司 | 一種分布式儲存系統升級方法和裝置 |
CN113377728A (zh) * | 2021-06-11 | 2021-09-10 | 重庆农村商业银行股份有限公司 | 一种文件共享方法及系统 |
CN115460227A (zh) * | 2022-11-14 | 2022-12-09 | 成都怡康科技有限公司 | 同步数据的方法、装置、系统、计算机设备及存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101877008A (zh) * | 2010-05-27 | 2010-11-03 | 开心人网络科技(北京)有限公司 | 一种海量小文件的存储方法及装置 |
CN102437925A (zh) * | 2011-12-01 | 2012-05-02 | 中兴通讯股份有限公司 | 分布式系统中的数据备份方法、装置及系统 |
CN103176860A (zh) * | 2011-12-21 | 2013-06-26 | 腾讯科技(深圳)有限公司 | 数据备份方法和系统 |
CN203289491U (zh) * | 2013-05-23 | 2013-11-13 | 浙江闪龙科技有限公司 | 一种故障节点可自动修复的集群存储系统 |
CN103763383A (zh) * | 2014-01-27 | 2014-04-30 | 西安雷迪维护系统设备有限公司 | 一体化云存储系统及其存储方法 |
-
2014
- 2014-08-27 CN CN201410426213.0A patent/CN104202385A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101877008A (zh) * | 2010-05-27 | 2010-11-03 | 开心人网络科技(北京)有限公司 | 一种海量小文件的存储方法及装置 |
CN102437925A (zh) * | 2011-12-01 | 2012-05-02 | 中兴通讯股份有限公司 | 分布式系统中的数据备份方法、装置及系统 |
CN103176860A (zh) * | 2011-12-21 | 2013-06-26 | 腾讯科技(深圳)有限公司 | 数据备份方法和系统 |
CN203289491U (zh) * | 2013-05-23 | 2013-11-13 | 浙江闪龙科技有限公司 | 一种故障节点可自动修复的集群存储系统 |
CN103763383A (zh) * | 2014-01-27 | 2014-04-30 | 西安雷迪维护系统设备有限公司 | 一体化云存储系统及其存储方法 |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104754031A (zh) * | 2015-02-15 | 2015-07-01 | 四川长虹电器股份有限公司 | 一种上传文件的方法和空调 |
CN104780211B (zh) * | 2015-04-13 | 2016-09-07 | 努比亚技术有限公司 | 数据同步方法和装置 |
CN105208078A (zh) * | 2015-08-13 | 2015-12-30 | 飞狐信息技术(天津)有限公司 | 一种文件存储系统及方法 |
CN105187552B (zh) * | 2015-09-29 | 2019-02-22 | 北京奇艺世纪科技有限公司 | 一种文件异地灾备的方法和装置 |
CN105187552A (zh) * | 2015-09-29 | 2015-12-23 | 北京奇艺世纪科技有限公司 | 一种文件异地灾备的方法和装置 |
TWI735521B (zh) * | 2017-01-24 | 2021-08-11 | 香港商阿里巴巴集團服務有限公司 | 一種分布式儲存系統升級方法和裝置 |
CN108933803A (zh) * | 2017-05-26 | 2018-12-04 | 杭州海康威视数字技术股份有限公司 | 前端设备、云存储服务器、流数据直存方法及系统 |
CN108933803B (zh) * | 2017-05-26 | 2021-11-19 | 杭州海康威视数字技术股份有限公司 | 前端设备、云存储服务器、流数据直存方法及系统 |
CN108984560A (zh) * | 2017-06-01 | 2018-12-11 | 杭州海康威视数字技术股份有限公司 | 文件存储方法及装置 |
CN108984560B (zh) * | 2017-06-01 | 2021-06-11 | 杭州海康威视数字技术股份有限公司 | 文件存储方法及装置 |
CN111405008A (zh) * | 2020-03-06 | 2020-07-10 | 精英数智科技股份有限公司 | 一种煤矿数据传输方法、装置及系统 |
CN113377728A (zh) * | 2021-06-11 | 2021-09-10 | 重庆农村商业银行股份有限公司 | 一种文件共享方法及系统 |
CN115460227A (zh) * | 2022-11-14 | 2022-12-09 | 成都怡康科技有限公司 | 同步数据的方法、装置、系统、计算机设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104202385A (zh) | 一种分布式文件系统的数据备份及更新方法 | |
US20180150501A1 (en) | Database system, server device, computer program product, and information processing method | |
US10831741B2 (en) | Log-shipping data replication with early log record fetching | |
US8839031B2 (en) | Data consistency between virtual machines | |
CN105830033B (zh) | 用于在分布式数据网格中支持持久存储装置版本化和完整性的系统和方法 | |
WO2009048728A1 (en) | Smart access to a dispersed data storage network | |
CN102255974A (zh) | 一种云计算服务器的云存储方法 | |
US8930751B2 (en) | Initializing replication in a virtual machine | |
CN101771548A (zh) | 文件同步方法及系统 | |
US11620087B2 (en) | Implicit leader election in a distributed storage network | |
CN113010496B (zh) | 一种数据迁移方法、装置、设备和存储介质 | |
CN110633168A (zh) | 一种分布式存储系统的数据备份方法和系统 | |
CN104754048A (zh) | 服务器集群的一种拟态组织结构 | |
CN107357800A (zh) | 一种数据库高可用零丢失解决方法 | |
CN104486438A (zh) | 分布式存储系统的容灾方法及装置 | |
CN104753987A (zh) | 一种分布式会话管理方法及系统 | |
CN113326251B (zh) | 数据管理方法、系统、设备和存储介质 | |
US20160139996A1 (en) | Methods for providing unified storage for backup and disaster recovery and devices thereof | |
JP6671708B2 (ja) | バックアップリストアシステム及びバックアップリストア方法 | |
US20150331752A1 (en) | Method of data storage on cloud data center for reducing processing and storage requirements by engaging user equipment | |
CN114363350B (zh) | 一种服务治理系统及方法 | |
US10067998B2 (en) | Distributed sync list | |
US10157021B2 (en) | Processing incomplete data access transactions | |
CN112416878A (zh) | 一种基于云平台的文件同步管理方法 | |
US10594793B2 (en) | Read-prepare requests to multiple memories |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20141210 |