CN108509298A - 一种数据处理的方法、装置及存储介质 - Google Patents
一种数据处理的方法、装置及存储介质 Download PDFInfo
- Publication number
- CN108509298A CN108509298A CN201810240907.3A CN201810240907A CN108509298A CN 108509298 A CN108509298 A CN 108509298A CN 201810240907 A CN201810240907 A CN 201810240907A CN 108509298 A CN108509298 A CN 108509298A
- Authority
- CN
- China
- Prior art keywords
- server
- main thread
- full dose
- data
- master server
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请实施例涉及数据处理技术领域,尤其涉及一种数据处理的方法、装置及存储介质。本申请实施例中,若主服务器确定将主线程对应的全量数据备份至从服务器,则主服务器通过调用主线程对应的第一子线程将全量数据备份至主服务器的第一存储区域;主服务器通过调用主线程对应的第二子线程从第一存储区域读取主线程对应的全量数据,并将读取到的全量数据发送至从服务器。由于主服务器可以通过第一子线程和第二子线程完成将全量数据备份至第一存储区域和备份至从服务器,因此,主线程可以在第一子线程或者第二子线程执行任务的同时处理其他的任务,如此,可以提高数据处理的效率。
Description
技术领域
本申请实施例涉及数据处理技术领域,尤其涉及一种数据处理的方法、装置及存储介质。
背景技术
随着互联网科技的飞速发展,互联网企业在应对越来越复杂的客户需求的同时,也产生了大量的数据。
现有技术中,Redis主服务器和从服务器复制方法分为:复制关系搭建、全量数据备份、增量数据备份及命令传递四个步骤。由于Redis服务器是一个单进程的服务器,复制关系搭建、全量复制、增量复制及命令传递四个步骤只能一个一个的进行,假设在全量数据从主服务器备份到从服务器的过程中,主服务器接收到从服务器的请求,必须暂停全量数据的备份过程,向从服务器发送该请求的反馈。
综上,亟需一种数据处理的方法用于提高数据的处理效率。
发明内容
本申请实施例提供一种数据处理的方法、装置及存储介质,用于提高数据的处理效率。
本申请实施例提供一种数据处理的方法,包括:若主服务器确定将主线程对应的全量数据备份至从服务器,则主服务器通过调用主线程对应的第一子线程将全量数据备份至主服务器的第一存储区域;其中,第一存储区域为持久化存储区域;主服务器通过调用主线程对应的第二子线程从第一存储区域读取主线程对应的全量数据,并将读取到的全量数据发送至从服务器。
可选的,主服务器通过调用主线程对应的第一子线程将全量数据备份至主服务器的第一存储区域,包括;主服务器调用主线程对应的第一子线程通过存储引擎将全量数据备份备份至主服务器的第一存储区域,其中,存储引擎为RockDB存储引擎。
可选的,主服务器通过调用主线程对应的第二子线程将读取到的全量数据发送至从服务器,包括主服务器调用主线程对应的第二子线程通过rsync同步工具将读取到的全量数据发送至从服务器。
可选的,主服务器确定将主线程对应的全量数据备份至从服务器,包括:主服务器通过调用主线程向从服务器发送第一信息,其中,第一信息用于指示主线程对应的全量数据将备份至从服务器;主服务器在确定发送第一信息之后,确定将主线程对应的全量数据备份至从服务器。
可选的,主服务器通过调用主线程对应的第一子线程将全量数据备份至主服务器的第一存储区域之后,还包括主服务器调用主线程将主线程对应的第一增量数据从主线程对应的内存区域备份至第二存储区域;主服务器将读取到的全量数据发送至从服务器之后,还包括:主服务器通过调用主线程接收从服务器发送的第二信息,其中,第二信息包括用于指示从服务器上已经备份的主线程对应的数据的标识的指示信息;主服务器若根据第二信息确定将主线程对应的增量数据备份至从服务器,则主服务器调用主线程对应的第三子线程获取从服务器上已经备份的主线程对应的数据的标识,从第二存储区域读取第二增量数据,并将读取到的第二增量数据发送至从服务器。
本申请实施例提供一种数据处理的装置,包括:处理单元,用于确定将主线程对应的全量数据备份至从服务器,则通过调用主线程对应的第一子线程将全量数据备份至主服务器的第一存储区域;其中,第一存储区域为持久化存储区域;通过调用主线程对应的第二子线程从第一存储区域读取主线程对应的全量数据;收发单元,用于将读取到的全量数据发送至从服务器。
可选的,处理单元,具体用于调用主线程对应的第一子线程通过存储引擎将全量数据备份至主服务器的第一存储区域,其中,存储引擎为RockDB存储引擎。
可选的,处理单元,具体用于:调用主线程对应的第二子线程通过rsync同步工具将读取到的全量数据通过收发单元发送至从服务器。
可选的,处理单元,具体用于:通过调用主线程通过收发单元向从服务器发送第一信息,其中,第一信息用于指示主线程对应的全量数据将备份至从服务器;在确定发送第一信息之后,确定将主线程对应的全量数据备份至从服务器。
可选的,处理单元,还用于调用主线程将主线程对应的第一增量数据从主线程对应的内存区域备份至第二存储区域;调用主线程通过接收单元接收从服务器发送的第二信息,其中,第二信息包括用于指示从服务器上已经备份的主线程对应的数据的标识的指示信息;若根据第二信息确定将主线程对应的增量数据备份至从服务器,则调用主线程对应的第三子线程获取从服务器上已经备份的主线程对应的数据的标识,从第二存储区域读取第二增量数据,并通过收发单元将读取到的第二增量数据发送至从服务器。
本申请实施例提供一种计算机存储介质,计算机存储介质存储有计算机可执行指令,计算机可执行指令在被计算机调用时,使计算机执行上述方法中任一方法。
本申请实施例提供一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述方法中任一方法。
本申请实施例中,若主服务器确定将主线程对应的全量数据备份至从服务器,则主服务器通过调用主线程对应的第一子线程将全量数据从主服务器的内存区域备份至主服务器的第一存储区域;其中,第一存储区域为持久化存储区域;主服务器通过调用主线程对应的第二子线程从第一存储区域读取主线程对应的全量数据,并将读取到的全量数据发送至从服务器。由于主服务器可以通过第一子线程和第二子线程完成将全量数据备份至第一存储区域和备份至从服务器,因此,主线程可以在第一子线程或者第二子线程执行任务的同时处理其他的任务,如此,可以提高数据处理的效率。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简要介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供一种适用的系统架构示意图;
图2为本申请实施例提供一种数据处理的方法的流程示意图;
图3为本申请实施例提供一种主服务器和从服务器交互的流程示意图;
图4为本申请实施例提供一种全量数据备份的流程示意图;
图5为本申请实施例提供一种增量数据备份的流程示意图;
图6为本申请实施例提供一种数据处理的装置的结构示意图。
具体实施方式
为了使本申请实施例的目的、技术方案及有益效果更加清楚明白,以下结合附图及实施例,对本申请实施例进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本申请实施例,并不用于限定本申请实施例。
图1示例性示出了本申请实施例适用的一种系统架构图,如图1,包括主服务器101和从服务器102。连接主服务器101的其它服务器和终端设备可以向该主服务器101发送数据,主服务器101和从服务器102可以在复制关系搭建之后,主服务器101将全量数据和增量数据备份至从服务器102。一种可选的实施方式中,主服务器101和从服务器102是Redis框架中的服务器,主服务器101对应的从服务器102的数量可以是1个或者多个。
本申请实施例中,全量数据是指主服务器在当前时间点时Redis数据库中的所有数据,当前时间点可以是主服务器确定要将数据备份至从服务器的时间点。增量数据可以是指在主服务器将全量数据备份至从服务器的过程中接收到的新的数据。举个例子,主服务器确定要将数据备份至从服务器时,确定数据库中存在编号为1-100的100条数据,那么这编号为1-100的100条数据就是全量数据,随后,主服务器又接收到编号为101-105的5条数据,那么这编号为101-105的5条数据为增量数据,在服务器将全量数据备份至从服务器之后,可以将增量数据也备份至从服务器。
本申请实施例中,主服务器可以被称为主节点,从服务器可以被称为从节点。
图2示例性示出了本申请实施例适用的一种数据处理的方法的流程示意图,如图2所示,包括:
步骤201,若主服务器确定将主线程对应的全量数据备份至从服务器,则主服务器通过调用主线程对应的第一子线程将全量数据从主服务器的内存区域备份至主服务器的第一存储区域;其中,第一存储区域为持久化存储区域;
步骤202,主服务器通过调用主线程对应的第二子线程从第一存储区域读取主线程对应的全量数据,并将读取到的全量数据发送至从服务器。
本申请实施例中,若主服务器确定将主线程对应的全量数据备份至从服务器,则主服务器通过调用主线程对应的第一子线程将全量数据从主服务器的内存区域备份至主服务器的第一存储区域;其中,第一存储区域为持久化存储区域;主服务器通过调用主线程对应的第二子线程从第一存储区域读取主线程对应的全量数据,并将读取到的全量数据发送至从服务器。由于主服务器可以通过第一子线程和第二子线程完成将全量数据备份至第一存储区域和备份至从服务器,因此,主线程可以在第一子线程或者第二子线程执行任务的同时处理其他的任务,如此,可以提高数据处理的效率。
上述步骤201中,一种可选的主服务器确定将主线程对应的全量数据备份至从服务器的实施方式中,主服务器可以通过调用主线程向从服务器发送第一信息,其中,第一信息用于指示主线程对应的全量数据将备份至从服务器。该主服务器在确定发送第一信息之后,确定将主线程对应的全量数据备份至从服务器。
本申请实施例中,主服务器可以有多个线程,包括一个主线程和一个或者多个子线程,从服务器可以有多个线程,包括一个主线程和一个或者多个子线程。一种可选的实施中,主线程和子线程可以在同一时间运行,执行不同的任务。
本申请实施例中,步骤201之前,即主服务器确定将主线程对应的全量数据备份至从服务器之前,一种可选的实施方式中,主服务器可以和从服务器建立传输协议控制(Transmission Control Protocolm,TCP)链路。该TCP链路可以用于传输主服务器和从服务器之间的请求和反馈。
下面介绍一种主服务器和从服务器之间建立TCP链路的方法,图3示例性示出了本申请实施例适用的一种主服务器和从服务器交互的流程示意图,如图3所示,包括:
步骤301,从服务器的主线程向主服务器发送连接请求。
步骤302,主服务器接收到该连接请求之后,主服务器的主线程可以向从服务器发送连接反馈,该连接反馈用于主服务器向从服务器反馈两者之间的TCP链路已经连接成功。
可选的,主服务器在接收到从服务器的连接请求的同时,可以获取该从服务器的网络协议(Internet Protoco,IP)地址。
步骤303,从服务器的主线程向主服务器发送检测请求,该检测请求用于检测该TCP链路的质量。
一种可选的实施方式中,检测请求可以表示为从服务器的主线程向主服务器发送ping,用于检测TCP链路的质量,检测TCP链路的质量可以包括检测该TCP链路是否有时延,是否有丢包等等情况。
步骤304,主服务器接收到检测请求后,主服务器的主线程可以向从服务器发送检测反馈,该检测反馈用于通知从服务器该TCP链路的质量。
一种可选的实施方式中,检测反馈可以表示为主服务器的主线程向从服务器发送pong,用于反馈该TCP链路的质量。
步骤305,从服务器接收到检测反馈后,从服务器的主线程可以向主服务器发送验证密码,该验证密码可以是用于向主服务器告知从服务器已经被主服务器授权,可以将主服务器的数据备份至从服务器。
步骤306,主服务器的主线程判断该验证密码是否正确,若正确,则转至步骤307,若错误,则结束流程。
步骤307,主服务器的主线程向从服务器发送确认反馈,可选的,主服务器的主线程可以向从服务器发送OK。
步骤308,从服务器接收到确认反馈后,从服务器的主线程向主服务器发送备份状态,该备份状态包括从服务器中存储的服务器的标识和已经备份的最新数据的标识。
一种可选的实施方式中,从服务器中存储的服务器的标识可以是该主服务器的标识;可以不是该主服务器的标识,而是其他的主服务器的标识,也可以是空,也就是说,从服务器并没有存储任何主服务器的标识。可选的,服务器的标识可以是服务器的ID号,在程序中可以用runid表示服务器的标识。
一种可选的实施方式中,已经备份的最新数据的标识可以是该从服务器之前备份的数据中的最后一条数据的标识,举个例子,该从服务器之前备份了编号为1-100的100条数据,则已经备份的最新数据的标识可以是最后一条数据的标识100。可选的,已经备份的最新数据的标识可以是空,这表明该从服务器没有备份过任何数据,在程序中可以用slave_max(sn)表示已经备份的最新数据的标识,slave_max(sn)也可以被称为是从服务器最新的复制偏移,<sn>为服务器的复制偏移。
步骤309,主服务器接收到从服务器发送的备份状态后,主服务器的主线程根据从服务器中存储的服务器的标识和已经备份的最新数据的标识进行判断,若从服务器中存储的服务器的标识和主服务器的标识一致,且已经备份的最新数据的标识小于主服务器中的最新数据的标识,则转至步骤310,否则转至步骤311。
一种可选的实施方式中,主服务器会根据以下的代码进行判断,若runid!=?&&slave_min(sn)!=-1&&master_max(sn)>slave_max(sn)为真,则满足备份增量数据的条件,若runid!=?&&slave_min(sn)!=-1&&master_max(sn)>slave_max(sn)为假,则满足备份全量数据的条件。runid!=?是指从服务器中存储的服务器的标识和主服务器的标识一致。slave_min(sn)可以被认为是从服务器最旧的复制偏移,即从服务器中备份的第一条数据的标识,若从服务器中备份的第一条数据的标识不等于-1,则表明从服务器中有备份的数据的标识。master_max(sn)>slave_max(sn)是指从服务器中已经备份的最新数据的标识小于主服务器中的最新数据的标识,也就是主服务器又接收到了新的数据,但还未备份至从服务器,这就是全量数据对应的增量数据。
步骤310,主服务器的主线程向从服务器发送第三信息,该第三信息用于告知从服务器接收增量数据。可选的,第三信息可以表示为+CONTINUE。
步骤311,主服务器的主线程向从服务器发送第一信息,该第一信息用于指示从服务器接收全量数据。
一种可选的实施方式中,第一信息可以表示为+FULLSYNC<runid><sn>,本申请实施例不仅告知了从服务器接收主服务器的全量数据,还告知了主服务器的标识,并指示从服务器中已经备份的最新数据的标识重置为0。如此,只要从服务器中存储的服务器的标识和主服务器的标识不一致,或者从服务器中已经备份的最新数据的标识不小于主服务器中的最新数据的标识,则主服务器可以认为从服务器是一个新的用于备份该主服务器中的数据的从服务器,因此,可以向该从服务器发送全量数据。
步骤312,从服务器接收到第一信息后,可以建立第四线程用于开启从服务器的rsync同步工具,准备接收主服务器发送的全量数据。
上述步骤301至步骤302是主服务器的主线程和从服务器的主线程之间通过建立的TCP链路进行的消息交互。
在从服务器还未和主服务器建立TCP链路之前,主服务器接收到的数据都保存在主服务器的内存区域,也就是Redis数据库中。该主服务器在确定发送第一信息之后,一种可选的实施方式中,步骤312之后,主服务器可以进行全量数据备份至从服务器的准备工作,图4示例性示出了本申请实施例适用的一种全量数据备份的流程示意图,如图4所示,包括:
步骤401,主服务器调用主线程对应的第一子线程通过存储引擎将全量数据备份从主服务器的内存区域备份至主服务器的第一存储区域,其中,存储引擎为RockDB存储引擎。
现有技术中,为了保证数据的安全性,以防主服务器的故障或者断电导致的全量数据的消失,主服务器需要在发送第一信息后,将全量数据备份至持久化存储区域中。具体地,主服务器在确定发送第一信息之后,主服务器的主进程调用生成子进程的fork函数生成子进程,子进程中包含该全量数据,随后子进程代替主进程将全量数据备份至持久化存储区域。这个过程可以被称为数据落盘。
这是由于Redis服务器是一个单进程的服务器,也就是一个时间点做处理一件事情,如果主进程自己将全量数据备份至持久化存储区域,主进程就不能在同一时间接收其它服务器或者终端设备发送至主服务器的数据。因此,需要子进程代替主进程将全量数据备份至持久化存储区域。
然而,随着主服务器存储的数据量越来越大,主服务器的主进程调用生成子进程的fork函数生成子进程的过程中所需的时间越来越多,根据测试,物理机上,主服务器中每增加1GB的数据,生成子进程的时间增加9毫秒;Xenia虚拟化的主机上,主服务器中每增加1GB的数据,生成子进程的时间增加424毫秒。
而本申请实施例中,使用主线程对应的第一子线程通过RockDB存储引擎将全量数据备份至主服务器的第一存储区域,通过RockDB存储引擎的全量数据备份接口完成数据备份,不再需要生成子进程完成数据落盘,可以提高数据备份的效率。
一种可选的实施方式中,持久化存储区域可以是磁盘,磁盘可以内设在主服务器器中,也可以是外设设备,通过接口和主服务器连接。
步骤402,主服务器的主线程的定时事件周期性检查finish_backup的状态,若finish_backup=1,则转至步骤403,若finish_backup=0,则转至步骤402。上述finish_backup是标志变量,finish_backup=0表示存储引擎将全量数据备份至持久性存储区域的过程还未完成或者还没有开始备份。finish_backup=1表示存储引擎备份结束。
步骤403,主服务器调用主线程对应的第二子线程通过rsync同步工具将读取到的全量数据发送至从服务器。
一种可选的实施方式中,主服务器可以在finish_backup=1建立第二子线程,也可以在确定发送第一信息之后,主服务器建立第二子线程,并使用第二子线程通过rsync同步工具将从持久化存储区域中读取到的全量数据发送至从服务器。
本申请实施例中,第二子线程可以是通过第一链路将全量数据发送给从服务器,其中,第一链路是主服务器根据从服务器的IP地址连接的,且第一链路不同于主服务器和从服务器之间的TCP链路,第一链路负责传输全量数据。
现有技术中,主服务器和从服务器之间的请求、反馈和全量数据都是通过TCP链路传输的,在传输全量数据的过程中,由于现有技术中的主服务器是一个单进程的服务器,一旦接收到从服务器发送的请求,就会暂停全量数据的传输,直到将该请求的反馈传输至从服务器,主服务器才能继续全量数据的传输。
举个例子,现有技术中从服务器可以每隔10秒向主服务器发送一个ping,用于检测TCP链路的质量,当主服务器接收到后,会暂停量数据的传输,直到反馈一个pong至从服务器之后,继续传输全量数据。
而本申请实施例中,由于TCP链路是用于传输请求和反馈,而第一链路是用于传输全量数据,两者互不干涉,因此可以提高全量数据的传输。
对应地,从服务器的第四子线程通过从服务器的rsync同步工具接收全量数据,即从服务器的第四子线程通过建立rsync服务接收全量数据。
步骤404,主服务器的主线程的定时事件周期性检查finish_send的状态,若finish_send=1,则转至步骤405,否则转至步骤404。
上述finish_backup是标志变量,finish_send=0表示全量数据还没有开始从主服务器发送至从服务器或者只发送了全量数据的一部分,还没有发送完全。finish_send=1表示全量数据已经被发送至从服务器。
步骤405,主服务器的主线程从服务器发送start_reply,start_reply用于指示从服务器可以回放接收到的全量数据。
本申请实施例中,回放全量数据是指从服务器获取当前的全量数据的数据量。
步骤406,从服务器回放完全量数据,并且关闭rsync同步工具。
步骤407,主服务器调用主线程接收从服务器发送的第二信息,该第二信息包括用于指示从服务器上已经备份的主线程对应的数据的标识的指示信息;
也就是说,从服务器的主线程将已经备份的最新数据的标识发送给主服务器。
举个例子,若全量数据为编号为0-500的数据,从服务器接收到全量数据并存储至从服务器的内存后,可以将已经备份的最新数据的标识500发送给主服务器。
步骤403之前,一种可选的实施方式中,主服务器的主线程可以将全量数据的长度发送至从服务器。
步骤310或者步骤407之后,主服务器可以将全量数据对应的增量数据传输给从服务器。在将增量数据传输给从服务器之前,一种可选的实施方式中,主服务器可以调用主线程将主线程对应的第一增量数据从主线程对应的内存区域备份至第二存储区域,其中,该第二存储区域可以是另一个持久化存储区域,第二存储区域也可以是第一存储区域。
现有技术中,由于主服务器的主进程将第一增量数据直接放置在一个内存中,该内存容量比较小,若全量数据从主服务器备份至从服务器所需的时间过长或者TCP链路断线期间,主服务器接收了大量的数据,超过了该内存的容量,会发生缓冲区溢出,从而导致全量数据中断备份至从服务器的问题。
而本申请使用持久化存储区域,且容量较大,有足够的空间存储增量数据,可以避免发生缓冲区溢出,全量数据中断备份至从服务器的问题。图5示例性示出了本申请实施例适用的一种增量数据备份的流程示意图,如图5所示,包括:
步骤501,主服务器建立第三子线程,用于传输增量数据。
本申请实施例中,第三子线程可以是通过第二链路将增量数据发送给从服务器,其中,第二链路是主服务器根据从服务器的IP地址连接的,且第二链路不同于主服务器和从服务器之间的TCP链路和第一链路,第二链路负责传输增量数据。
步骤502,主服务器的第三子线程的定时事件周期性检查当前的备份状态,若前一次的数据已发送完成,则转至步骤503;
其中,前一次的数据可以是增量数据,也可以是全量数据。
一种可选的方式中,步骤502之后,主服务器调用主线程对应的第三子线程获取从服务器上已经备份的主线程对应的数据的标识,使用存储引擎从第二存储区域读取第二增量数据。从服务器上已经备份的主线程对应的数据的标识就是从服务器上已经备份的最新数据的标识,主服务器的主线程接收到从服务器发送的已经备份的最新数据的标识,第三子线程可以获取该从服务器上已经备份的最新数据的标识。
步骤503,若master_max(sn)>slave_max(sn),则转至步骤504
一种可选的实施方式中,即从服务器中已经备份的最新数据的标识小于主服务器中的最新数据的标识,也就是主服务器又接收到了增量数据,则可以从第二存储区域读取第二增量数据,第二增量数据的数据量可以等于第一增量数据的数据量,也可以大于第一增量数据的数据量。这取决于发送完全量数据之后增量数据的数据量。可选的,第一增量数据可以是主服务器结束到的一条数据。
步骤504,主服务器的第三子线程确定增量数据的数据长度;
步骤505,主服务器的第三子线程将增量数据的数据长度发送给从服务器。
上述505步骤主要是用于告知从服务器增量数据的数据长度,让从服务器做好接收的准备,并可以使得从服务器确定是否接收完全增量数据。另一种了选的实施方式中,主服务器可以在增量数据中的最后一条数据中打一个结束的标记,使得从服务器确定是否接收完全增量数据。
步骤506,主服务器的第三子线程将增量数据发送给从服务器;
步骤507,从服务器将接收到的增量数据存储进内存中。
随后,主服务器和从服务器中间可以重复步骤502至步骤507的过程。
基于以上实施例及相同构思,图6示出了本申请实施例提供的一种数据处理的装置的结构示意图;如图6所示,数据处理装置600可以包括处理单元601和收发单元602。
本申请实施例提供一种数据处理的装置,包括:处理单元,用于确定将主线程对应的全量数据备份至从服务器,则通过调用主线程对应的第一子线程将全量数据从主服务器的内存区域备份至主服务器的第一存储区域;其中,第一存储区域为持久化存储区域;通过调用主线程对应的第二子线程从第一存储区域读取主线程对应的全量数据;收发单元,用于将读取到的全量数据发送至从服务器。
本申请实施例中,若确定将主线程对应的全量数据备份至从服务器,则通过调用主线程对应的第一子线程将全量数据从主服务器的内存区域备份至主服务器的第一存储区域;其中,第一存储区域为持久化存储区域,通过调用主线程对应的第二子线程从第一存储区域读取主线程对应的全量数据,并将读取到的全量数据发送至从服务器。由于可以通过第一子线程和第二子线程完成将全量数据备份至第一存储区域和备份至从服务器,因此,主线程可以在第一子线程或者第二子线程执行任务的同时处理其他的任务,如此,可以提高数据处理的效率。
一种可选的实施方式中,处理单元,具体用于调用主线程对应的第一子线程通过存储引擎将全量数据备份从主服务器的内存区域备份至主服务器的第一存储区域,其中,存储引擎为RockDB存储引擎。
一种可选的实施方式中,处理单元,具体用于:调用主线程对应的第二子线程通过rsync同步工具将读取到的全量数据通过收发单元发送至从服务器。
一种可选的实施方式中,处理单元,具体用于:通过调用主线程通过收发单元向从服务器发送第一信息,其中,第一信息用于指示主线程对应的全量数据将备份至从服务器;在确定发送第一信息之后,确定将主线程对应的全量数据备份至从服务器。
一种可选的实施方式中,处理单元,还用于调用主线程将主线程对应的第一增量数据从主线程对应的内存区域备份至第二存储区域;调用主线程通过接收单元接收从服务器发送的第二信息,其中,第二信息包括用于指示从服务器上已经备份的主线程对应的数据的标识的指示信息;若根据第二信息确定将主线程对应的增量数据备份至从服务器,则调用主线程对应的第三子线程获取从服务器上已经备份的主线程对应的数据的标识,从第二存储区域读取第二增量数据,并通过收发单元将读取到的第二增量数据发送至从服务器。
本申请实施例提供的数据处理的装置具体阐述可参考上述实施例提供的数据处理的方法,在这里不再赘述。
需要说明的是,本申请实施例中对单元的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。在本申请实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现、当使用软件程序实现时,可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个指令。在计算机上加载和执行计算机程序指令时,全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。指令可以存储在计算机存储介质中,或者从一个计算机存储介质向另一个计算机存储介质传输,例如,指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质,(例如,软盘、硬盘、磁带、磁光盘(MO)等)、光介质(例如,CD、DVD、BD、HVD等)、或者半导体介质(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(Solid State Disk,SSD))等。本领域内的技术人员应明白,本申请实施例可提供为方法、系统、或计算机程序产品。因此,本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。本领域内的技术人员应明白,本申请实施例可提供为方法、装置、或计算机程序产品。因此,本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请实施例是参照根据本申请实施例的方法、装置、和计算机程序产品的流程图和/或方框图来描述的。应理解可由指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
Claims (12)
1.一种数据处理的方法,其特征在于,包括:
若主服务器确定将主线程对应的全量数据备份至从服务器,则所述主服务器通过调用所述主线程对应的第一子线程将所述全量数据备份至所述主服务器的第一存储区域;其中,所述第一存储区域为持久化存储区域;
所述主服务器通过调用所述主线程对应的第二子线程从所述第一存储区域读取所述主线程对应的全量数据,并将读取到的全量数据发送至所述从服务器。
2.如权利要求1所述的方法,其特征在于,所述主服务器通过调用所述主线程对应的第一子线程将所述全量数据备份至所述主服务器的第一存储区域,包括;
所述主服务器调用所述主线程对应的所述第一子线程通过存储引擎将所述全量数据备份至所述主服务器的第一存储区域,其中,所述存储引擎为RockDB存储引擎。
3.如权利要求2所述的方法,其特征在于,所述主服务器通过调用所述主线程对应的第二子线程将读取到的全量数据发送至所述从服务器,包括:
所述主服务器调用所述主线程对应的第二子线程通过rsync同步工具将读取到的全量数据发送至所述从服务器。
4.如权利要求1至3任一项所述的方法,其特征在于,所述主服务器确定将主线程对应的全量数据备份至从服务器,包括:
所述主服务器通过调用所述主线程向所述从服务器发送第一信息,其中,所述第一信息用于指示所述主线程对应的全量数据将备份至从服务器;
所述主服务器在确定发送所述第一信息之后,确定将所述主线程对应的全量数据备份至所述从服务器。
5.如权利要求1所述的方法,其特征在于,所述所述主服务器通过调用所述主线程对应的第一子线程将所述全量数据备份至所述主服务器的第一存储区域之后,还包括:
所述主服务器调用所述主线程将所述主线程对应的第一增量数据从所述主线程对应的所述内存区域备份至第二存储区域;
所述主服务器将读取到的全量数据发送至所述从服务器之后,还包括:
所述主服务器通过调用所述主线程接收所述从服务器发送的第二信息,其中,所述第二信息包括用于指示所述从服务器上已经备份的所述主线程对应的数据的标识的指示信息;
所述主服务器若根据所述第二信息确定将所述主线程对应的增量数据备份至所述从服务器,则:
所述主服务器调用所述主线程对应的第三子线程获取所述从服务器上已经备份的所述主线程对应的数据的标识,从所述第二存储区域读取第二增量数据,并将读取到的所述第二增量数据发送至所述从服务器。
6.一种数据处理的装置,其特征在于,包括:
处理单元,用于确定将主线程对应的全量数据备份至从服务器,则通过调用所述主线程对应的第一子线程将所述全量数据备份至所述主服务器的第一存储区域;其中,所述第一存储区域为持久化存储区域;通过调用所述主线程对应的第二子线程从所述第一存储区域读取所述主线程对应的全量数据;
收发单元,用于将读取到的全量数据发送至所述从服务器。
7.如权利要求6所述的装置,其特征在于,所述处理单元,具体用于:
调用所述主线程对应的所述第一子线程通过存储引擎将所述全量数据备份至所述主服务器的第一存储区域,其中,所述存储引擎为RockDB存储引擎。
8.如权利要求7所述的装置,其特征在于,所述处理单元,具体用于:调用所述主线程对应的第二子线程通过rsync同步工具将读取到的全量数据通过所述收发单元发送至所述从服务器。
9.如权利要求6至8任一项所述的装置,其特征在于,所述处理单元,具体用于:
通过调用所述主线程通过所述收发单元向所述从服务器发送第一信息,其中,所述第一信息用于指示所述主线程对应的全量数据将备份至从服务器;
在确定发送所述第一信息之后,确定将所述主线程对应的全量数据备份至所述从服务器。
10.如权利要求6所述的装置,其特征在于,所述处理单元,还用于:
调用所述主线程将所述主线程对应的第一增量数据从所述主线程对应的所述内存区域备份至第二存储区域;
调用所述主线程通过接收单元接收所述从服务器发送的第二信息,其中,所述第二信息包括用于指示所述从服务器上已经备份的所述主线程对应的数据的标识的指示信息;
若根据所述第二信息确定将所述主线程对应的增量数据备份至所述从服务器,则:
调用所述主线程对应的第三子线程获取所述从服务器上已经备份的所述主线程对应的数据的标识,从所述第二存储区域读取第二增量数据,并通过收发单元将读取到的所述第二增量数据发送至所述从服务器。
11.一种计算机存储介质,其特征在于,所述计算机存储介质存储有计算机可执行指令,所述计算机可执行指令在被计算机调用时,使所述计算机执行如权利要求1至5任一权利要求所述的方法。
12.一种包含指令的计算机程序产品,其特征在于,当其在计算机上运行时,使得所述计算机执行权利要求1至5任一权利要求所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810240907.3A CN108509298B (zh) | 2018-03-22 | 2018-03-22 | 一种数据处理的方法、装置及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810240907.3A CN108509298B (zh) | 2018-03-22 | 2018-03-22 | 一种数据处理的方法、装置及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108509298A true CN108509298A (zh) | 2018-09-07 |
CN108509298B CN108509298B (zh) | 2022-02-18 |
Family
ID=63378155
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810240907.3A Active CN108509298B (zh) | 2018-03-22 | 2018-03-22 | 一种数据处理的方法、装置及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108509298B (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110362432A (zh) * | 2019-07-23 | 2019-10-22 | 深信服科技股份有限公司 | 一种备份方法、装置、设备及存储介质 |
CN110896406A (zh) * | 2018-09-13 | 2020-03-20 | 华为技术有限公司 | 数据存储方法、装置及服务器 |
CN111736996A (zh) * | 2020-06-17 | 2020-10-02 | 上海交通大学 | 一种面向分布式非易失内存系统的进程持久化方法及装置 |
CN112863582A (zh) * | 2021-02-23 | 2021-05-28 | 广东申菱环境系统股份有限公司 | 一种数据掉电保持方法、装置、计算机设备和存储介质 |
CN113534708A (zh) * | 2021-07-12 | 2021-10-22 | 三一汽车制造有限公司 | 一种工控机热备份方法、装置及系统 |
CN114661523A (zh) * | 2022-03-18 | 2022-06-24 | 车主邦(北京)科技有限公司 | 数据备份方法、装置、程序产品、介质及电子设备 |
CN114760356A (zh) * | 2020-12-29 | 2022-07-15 | 北京金山云网络技术有限公司 | 数据读取请求处理方法、装置及数据读取请求处理系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102236588A (zh) * | 2010-04-23 | 2011-11-09 | 阿里巴巴集团控股有限公司 | 数据远程备份方法、设备及系统 |
US8191078B1 (en) * | 2005-03-22 | 2012-05-29 | Progress Software Corporation | Fault-tolerant messaging system and methods |
CN105302676A (zh) * | 2014-07-28 | 2016-02-03 | 浙江大华技术股份有限公司 | 一种分布式文件系统的主备机制数据传输方法及装置 |
CN105677515A (zh) * | 2016-01-08 | 2016-06-15 | 上海达梦数据库有限公司 | 一种数据库联机备份方法及系统 |
CN106528335A (zh) * | 2016-10-25 | 2017-03-22 | 广东欧珀移动通信有限公司 | 一种数据备份方法、装置和终端 |
-
2018
- 2018-03-22 CN CN201810240907.3A patent/CN108509298B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8191078B1 (en) * | 2005-03-22 | 2012-05-29 | Progress Software Corporation | Fault-tolerant messaging system and methods |
CN102236588A (zh) * | 2010-04-23 | 2011-11-09 | 阿里巴巴集团控股有限公司 | 数据远程备份方法、设备及系统 |
CN105302676A (zh) * | 2014-07-28 | 2016-02-03 | 浙江大华技术股份有限公司 | 一种分布式文件系统的主备机制数据传输方法及装置 |
CN105677515A (zh) * | 2016-01-08 | 2016-06-15 | 上海达梦数据库有限公司 | 一种数据库联机备份方法及系统 |
CN106528335A (zh) * | 2016-10-25 | 2017-03-22 | 广东欧珀移动通信有限公司 | 一种数据备份方法、装置和终端 |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110896406A (zh) * | 2018-09-13 | 2020-03-20 | 华为技术有限公司 | 数据存储方法、装置及服务器 |
US11403227B2 (en) | 2018-09-13 | 2022-08-02 | Huawei Technologies Co., Ltd. | Data storage method and apparatus, and server |
CN110362432A (zh) * | 2019-07-23 | 2019-10-22 | 深信服科技股份有限公司 | 一种备份方法、装置、设备及存储介质 |
CN110362432B (zh) * | 2019-07-23 | 2023-12-29 | 深信服科技股份有限公司 | 一种备份方法、装置、设备及存储介质 |
CN111736996A (zh) * | 2020-06-17 | 2020-10-02 | 上海交通大学 | 一种面向分布式非易失内存系统的进程持久化方法及装置 |
CN111736996B (zh) * | 2020-06-17 | 2022-08-16 | 上海交通大学 | 一种面向分布式非易失内存系统的进程持久化方法及装置 |
CN114760356A (zh) * | 2020-12-29 | 2022-07-15 | 北京金山云网络技术有限公司 | 数据读取请求处理方法、装置及数据读取请求处理系统 |
CN112863582A (zh) * | 2021-02-23 | 2021-05-28 | 广东申菱环境系统股份有限公司 | 一种数据掉电保持方法、装置、计算机设备和存储介质 |
CN112863582B (zh) * | 2021-02-23 | 2022-10-11 | 广东申菱环境系统股份有限公司 | 一种数据掉电保持方法、装置、计算机设备和存储介质 |
CN113534708A (zh) * | 2021-07-12 | 2021-10-22 | 三一汽车制造有限公司 | 一种工控机热备份方法、装置及系统 |
CN114661523A (zh) * | 2022-03-18 | 2022-06-24 | 车主邦(北京)科技有限公司 | 数据备份方法、装置、程序产品、介质及电子设备 |
Also Published As
Publication number | Publication date |
---|---|
CN108509298B (zh) | 2022-02-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108509298A (zh) | 一种数据处理的方法、装置及存储介质 | |
US9053240B2 (en) | Computer program testing | |
US8104043B2 (en) | System and method for dynamic cooperative distributed execution of computer tasks without a centralized controller | |
KR100575497B1 (ko) | 내고장성 컴퓨터 시스템 | |
CN105302676B (zh) | 一种分布式文件系统的主备机制数据传输方法及装置 | |
CN108419279A (zh) | 网络切换系统 | |
US20100250698A1 (en) | Automated tape drive sharing in a heterogeneous server and application environment | |
US9946721B1 (en) | Systems and methods for managing a network by generating files in a virtual file system | |
CN113382056A (zh) | 数据上报方法、装置、设备、存储介质及系统 | |
US20050234919A1 (en) | Cluster system and an error recovery method thereof | |
CN113626054A (zh) | 一种业务服务更新方法及装置 | |
CN118193238A (zh) | 一种业务信息的处理方法、装置、设备及存储介质 | |
CN111880947B (zh) | 一种数据传输方法及装置 | |
CN113238780A (zh) | 云服务器的升级方法、升级设备及云服务器 | |
JP6577901B2 (ja) | 計算機システムおよびシステム状態再現方法 | |
US6990609B2 (en) | System and method for isolating faults in a network | |
CN113992433B (zh) | 基于变异策略的网络设备并发模糊测试方法及装置 | |
CN105677515B (zh) | 一种数据库联机备份方法及系统 | |
CN110134628B (zh) | 消息传输方法、装置、设备及存储介质 | |
CN117215635B (zh) | 任务处理方法、装置及存储介质 | |
CN109672573B (zh) | 一种配置文件的部署方法、确定方法、服务器及存储介质 | |
CN110471739A (zh) | 指令重试方法及装置 | |
CN110633164B (zh) | 一种面向消息的中间件故障恢复方法及装置 | |
CN114579036B (zh) | 存储设备管理方法及相关设备 | |
CN111240749B (zh) | 一种集群系统中实例的挂起控制方法、装置、设备、存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |