CN109033391B

CN109033391B - Method and system for synchronizing data among multiple data centers and computer readable storage medium

Info

Publication number: CN109033391B
Application number: CN201810856478.2A
Authority: CN
Inventors: 余汶龙
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2018-07-31
Filing date: 2018-07-31
Publication date: 2019-12-31
Anticipated expiration: 2038-07-31
Also published as: CN109033391A

Abstract

The application discloses a method, a system and a computer readable storage medium for data synchronization among data centers, wherein the method comprises the steps that a first data center acquires at least one piece of data to be synchronized; each data to be synchronized corresponds to a data sequence number, and the data sequence number reflects the time sequence of the corresponding data to be synchronized, which is acquired by the first data center; the first data center writes the data to be synchronized into at least one storage device of the first data center; and the first data center sends the data to be synchronized to the second data center for synchronization based on the time sequence reflected by the data sequence number and the receiving state of the data to be synchronized on the second data center.

Description

Method and system for synchronizing data among multiple data centers and computer readable storage medium

Technical Field

The application relates to the field of data storage, in particular to a system and a method for on-line instant synchronization of data among multiple data centers.

Background

With the development of internet technology, O2O services, such as online taxi service and delivery service, play an increasingly important role in people's daily life. When people use O2O service, a large amount of data (e.g., order data) is generated, and how to perform efficient storage and utilization is a current hot issue.

The O2O service platform will typically store these data in a database service, and to ensure high availability of the database service, it is common to construct a database service across a computer room, i.e., data stored in a computer room of multiple different network environments, using "ex-situ multi-live" techniques. When the data of one machine room is unavailable for any reason, the access can be quickly switched to the database of another machine room, and the service interruption time is reduced. One of the key technical points in the "ex-situ multi-activity" technology lies in how to perform online real-time synchronization of data. Existing online real-time data synchronization schemes typically rely on a third party intermediary such as: message middleware of MQ class. After the user writes data into the database, the database service depends on the MQ message middleware to realize multi-room synchronization in the background. However, in this data synchronization method, the reliability of the synchronization data depends heavily on the MQ-like message middleware, and if the data is lost in the MQ-like message middleware, the reliable synchronization of the data cannot be guaranteed. Therefore, how to ensure the reliability of data synchronization without relying on third-party middleware becomes a problem to be solved in the field of data synchronization between multiple databases.

Disclosure of Invention

One aspect of the present application relates to a method for data synchronization between multiple data centers. The method comprises the steps that a first data center obtains at least one piece of data to be synchronized; each data to be synchronized corresponds to a data sequence number, and the data sequence number reflects the time sequence of the corresponding data to be synchronized, which is acquired by the first data center; the first data center writes the data to be synchronized into at least one storage device of the first data center; and the first data center sends the data to be synchronized to the second data center for synchronization based on the time sequence reflected by the data sequence number and the receiving state of the data to be synchronized at the second data center.

In some embodiments, the first data center sending the data to be synchronized to the second data center for synchronization based on the chronological order reflected by the data sequence number further comprises: and the first data center sequentially sends the data to be synchronized to the second data center for synchronization according to the time sequence reflected by the data sequence number.

In some embodiments, the first data center maintains at least one transmit queue; the sending queue is at least used for recording at least one data sequence number of sent data to be synchronized;

and the first data center sends the data to be synchronized to a second data center for synchronization based on the sending queue.

In some embodiments, after the first data center sends some data to be synchronized to the second data center, the first data center records a data sequence number corresponding to the data to be synchronized in a sending queue.

In some embodiments, the first data center maintaining at least one transmit queue further comprises the steps of: the first data center judges whether arrival information of the data to be synchronized, corresponding to a certain data sequence number in the sending queue, fed back by the second data center is received or not, and if yes, the data sequence number is deleted from the sending queue; if not, the data sequence number in the sending queue is reserved, and the data sequence number reflected in the sending queue and following the data sequence number is reserved.

In some embodiments, the first data center sending the data to be synchronized to the second data center for synchronization based on the sending queue further comprises: and the first data center judges whether the retention time of a certain data sequence number in the sending queue is overtime, and if yes, the first data center sends the data to be synchronized corresponding to the data sequence number and the data to be synchronized corresponding to the data sequence number with the time sequence after the data sequence number reflected in the sending queue to the second data center again.

In some embodiments, the transmit queue is stored in at least one storage device of the first data center.

Yet another aspect of the present application relates to a system for data synchronization between multiple data centers. The system comprises: the acquisition module, write in module and sending module, wherein: the acquisition module is used for acquiring at least one piece of data to be synchronized; each data to be synchronized corresponds to a data sequence number, and the data sequence number reflects the time sequence of the corresponding data to be synchronized, which is acquired by the first data center; the writing module is used for writing the data to be synchronized into at least one storage device of a first data center; the sending module is used for sending the data to be synchronized to a second data center for synchronization based on the time sequence reflected by the data sequence number and the receiving state of the data to be synchronized at the second data center.

Yet another aspect of the present application relates to a computer-readable storage medium for storing computer instructions, wherein when the computer instructions stored in the storage medium are read by a computer, the computer executes the method for data synchronization between multiple data centers.

Yet another aspect of the present application relates to an apparatus for data synchronization between multiple data centers, the apparatus comprising at least one processor and at least one storage medium; the at least one storage medium is configured to store computer instructions; the at least one processor is configured to execute the computer instructions to implement the method for data synchronization between multiple servers.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments will be briefly introduced below. It is obvious that the drawings in the following description are only some embodiments of the application, and that it is also possible for a person skilled in the art to apply the application to other similar scenarios without inventive effort on the basis of these drawings. Unless otherwise apparent from the context of language or otherwise indicated, like reference numerals in the figures refer to like structures and operations.

FIG. 1 is a schematic diagram of an exemplary fusion location recommendation system, shown in accordance with some embodiments of the present application;

FIG. 2 is a diagram illustrating exemplary hardware and/or software components of an exemplary computing device that may implement a processing engine according to some embodiments of the present application;

FIG. 3 is a schematic diagram of the hardware and/or software components of an exemplary mobile device according to some embodiments of the present application;

FIG. 4 is a block diagram of an exemplary processing engine shown in accordance with some embodiments of the present application;

FIG. 5 is a block diagram illustrating an exemplary processing module shown in accordance with some embodiments of the present application;

FIG. 6 is an exemplary flow diagram illustrating synchronization of data between services according to some embodiments of the present application; and

FIG. 7 is an exemplary flow diagram illustrating ensuring data arrives in order according to some embodiments of the present application.

Detailed Description

In the following detailed description, specific details of embodiments are set forth by way of example in order to provide a thorough understanding of the related applications. It will be apparent, however, to one skilled in the art that the present application may be practiced without these specific details. In other instances, well-known methods, procedures, systems, components, and/or circuits have been described at a high-level (without detail) in order to avoid unnecessarily obscuring aspects of the present application. Various modifications to the embodiments of the present application will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present application. Thus, the present application is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should be understood that the terms "system," "engine," "unit," "module," and/or "block" as used herein are a hierarchical approach to distinguish different components, elements, components, parts, or assemblies in an ascending order. However, these terms may be replaced by other expressions if the other expressions achieve the same purpose.

Generally, "module," "unit," or "block" as used herein refers to logic embodied in hardware or a set of firmware or software instructions. The modules, units, or blocks described herein may be executed on software and/or hardware and may be stored in any type of non-transitory computer-readable medium or other storage device. In some embodiments, software modules, units, blocks may be compiled and linked into an executable program. It should be understood that software modules may be called from other modules, units, blocks, or themselves and/or may be called in response to detected events or interrupts. Software modules/units/blocks configured for execution on a computing device (e.g., processing engine 112 as shown in fig. 1) may be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, magnetic disk, or any other tangible medium or as a digital download (and may be originally stored in a compressed or installable format requiring installation, decompression, or decryption prior to execution). The software code may be stored in part or in whole on a storage device executing the computing device for execution by the computing device. The software instructions may be embedded in firmware, such as an EPROM. It should be understood that hardware modules, units or blocks may be included in connected logic components, such as gates and flip-flops, and/or may be included in programmable units such as programmable gate arrays or processors. The modules, units, blocks or computing device functions described herein may be implemented as software modules/units/blocks, but may be represented in hardware or firmware. Generally, the modules, units, blocks described herein refer to logical modules, units, blocks that may be combined with other modules, units, blocks or divided into sub-modules, sub-units, sub-blocks, despite their physical organization or storage. The description may apply to the system, the engine, or a portion thereof.

It will be understood that when an element, engine, module or block is referred to as being "on" … "," connected to "or" coupled to "another element, engine, module or block, it can communicate directly with the other element, engine, module or block or there may be elements, engines, modules or blocks unless the context clearly dictates otherwise. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

These and other features of the present application, as well as related structural elements and components of manufacture and methods of operation and function that are economically incorporated, may become more apparent and form a part of the present application upon consideration of the following description with reference to the accompanying drawings. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the application. It should be understood that the drawings are not to scale.

FIG. 1 is a schematic diagram illustrating an exemplary O2O service system 100 in accordance with some embodiments of the present application. As shown, the O2O service system 100 may be an online transportation service platform that may be used for transportation related services such as taxi calling services, designated driving services, express delivery services, bus sharing services, bus services, driver employment, pickup services, and the like. The O2O service system 100 may also be an online service platform for providing online shopping and network services, such as housekeeping, appliance maintenance, and online friend-making. The O2O service system 100 may be an online platform including a server 110, a network 120, one or more requester terminals 130, one or more provider terminals 140, and a database 150. Processor 110 may include a processing engine 112.

In some embodiments, the server 110 may be a single server or a group of servers. The server groups may be centralized or decentralized (e.g., the servers 110 may be decentralized systems). In some embodiments, the server 110 is a decentralized server system comprising a plurality of data centers. The data center may be co-located or off-site. Data in a plurality of the data centers can be synchronized with each other in real time. In some embodiments, the server 110 may be local or remote. For example, server 110 may access data and/or information stored in requester terminal 130, provider terminal 140, and/or database 150 via network 120. As another example, server 110 may be directly connected to requester terminal 130, provider terminal 140, and/or database 150 to access the data and/or information stored therein. In some embodiments, the server 110 may be implemented in a cloud platform. By way of example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a decentralized cloud, a cross-cloud, a multi-cloud, and the like, or any combination thereof. In some embodiments, the server 110 may be implemented in a computing device 200 having one or more components as shown in FIG. 2 herein.

In some embodiments, the server 110 may include a processing engine 112. Processing engine 112 may process data and/or information related to the service request to perform one or more of the functions described herein. For example, the processing engine 112 may be a customer service provider (e.g., a transportation service provider, a home service provider, etc.) based on a service request obtained from the requester terminal 130. In some embodiments, processing engine 112 may include one or more processing engines (e.g., a single core processing engine or a multi-core processor). By way of example only, the processing engine 112 may include a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), an application specific instruction set processor (ASIP), a Graphics Processing Unit (GPU), a Physical Processing Unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller, a Reduced Instruction Set Computer (RISC), a microprocessor, and the like, or any combination thereof.

Network 120 may facilitate the exchange of data and/or information. In some embodiments, one or more components of the O2O service system 100 (e.g., the server 110, the requester terminal 130, the provider terminal 140, and the database 150) may send data and/or information to any other component of the O2O service system 100 via the network 120. For example, the server 110 may obtain/obtain a service request from the requester terminal 130 via the network 120. In some embodiments, the network 120 may be any type or combination of wired or wireless network. By way of example only, network 120 may include a cable network, a fiber optic network, a telecommunications network, an intranet, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), an interurban network (MAN), a Public Switched Telephone Network (PSTN), a bluetooth network, a ZigBee network, a near field communication Network (NFC), and the like, or any combination thereof. In some embodiments, network 120 may include one or more network access points. For example, the network 120 may include wired or wireless network access points, such as base stations and/or network switching points 120-1, 120-2 … …, via which one or more components of the O2O service system 100 may connect to the network 120 for the exchange of data and/or information.

In some embodiments, the requester may be a user of requester terminal 130. In some embodiments, the user of requester terminal 130 may be someone other than the requester. For example, user A of requester terminal 130 may use requester terminal 130 to send a service request to user B, or to receive services and/or information or instructions from server 110. In some embodiments, the provider may be a user of the provider terminal 140. In some embodiments, the user of provider terminal 140 may be someone other than the provider. For example, user C of provider terminal 140 may receive a service request for user D using provider terminal 140, and may also receive information or instructions from server 110. In some embodiments, "requester" and "requester terminal" may be used interchangeably, as may "provider" and "provider terminal".

In some embodiments, requester terminal 130 may include a mobile device 130-1, a tablet computer 130-2, a laptop computer 130-3, an in-vehicle device 130-4, and the like, or any combination thereof. In some embodiments, mobile device 130-1 may include a smart home device, a wearable device, a smart mobile device, a virtual reality device, an augmented reality device, and the like, or any combination thereof. In some embodiments, the smart home devices may include smart lighting devices, smart appliance control devices, smart monitoring devices, smart televisions, smart cameras, interphones, and the like, or any combination thereof. In some embodiments, the wearable device may include a smart bracelet, smart footwear, smart glasses, smart helmet, smart watch, smart garment, smart backpack, smart accessory, and the like, or any combination thereof. In some embodiments, the smart mobile device may include a smart phone, a Personal Digital Assistant (PDA), a gaming device, a navigation device, a point of sale (POS) device, and the like, or any combination thereof. In some embodiments, the virtual reality device and/or the augmented reality device may include a virtual reality helmet, virtual reality glasses, virtual reality eyeshields, augmented reality helmets, augmented reality glasses, augmented reality eyeshields, and the like, or any combination thereof. For example, virtual reality devices and/or augmented reality devices may include Google Glass, Oculus Rift, Hololens, Gear VR, and the like. In some embodiments, the in-vehicle device 130-4 may include an on-board computer, an on-board television, or the like. In some embodiments, the requester terminal 130 may be a device having a positioning technology for determining the location of the requester and/or the requester terminal 130.

In some embodiments, the provider terminal 140 may be similar to or the same as the requester terminal 130. In some embodiments, provider terminal 140 may be a device having location technology for determining the location of the provider and/or provider terminal 140. In some embodiments, requester terminal 130 and/or provider terminal 140 may communicate with other location devices to determine the location of the requester, requester terminal 130, provider, and/or provider terminal 140. In some embodiments, the requester terminal 130 and/or the provider terminal 140 may send the location information to the server 110.

Database 150 may store data and/or instructions. In some embodiments, database 150 may be built through a framework form of "place and live". For example: database 150 may contain multiple data centers. The data center is a globally coordinated network of devices that can be used to communicate, accelerate, present, compute, and store data information over a network infrastructure. Each data center may be geographically displaced. Each data center is active and can be charged with real-time traffic (e.g., data access such as historical order data for the user). Regardless of which data center in database 150 is experiencing problems, other data centers may take over their work directly.

In some embodiments, database 150 may store data obtained from requester terminal 130 and/or provider terminal 140. In some embodiments, database 150 may store data and/or instructions executable by or used by server 110 to perform the example methods described herein. In some embodiments, database 150 may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), and the like, or any combination thereof. Exemplary mass storage may include magnetic disks, optical disks, solid state drives, and the like. Exemplary removable storage may include flash memory, floppy disks, optical disks, memory cards, compact disks, magnetic tape, and the like. Exemplary volatile read and write memories can include Random Access Memory (RAM). Exemplary RAM may include Dynamic RAM (DRAM), double-data-rate synchronous dynamic RAM (DDRSDRAM), Static RAM (SRAM), thyristor RAM (T-RAM), zero-capacitance RAM (Z-RAM), and the like. Exemplary ROMs may include shielded ROM (MROM), Programmable ROM (PROM), erasable programmable ROM (PEROM), Electrically Erasable Programmable ROM (EEPROM), compact disk ROM (CD-ROM), digital versatile disk ROM, and the like. In some embodiments, database 150 may be implemented on a cloud platform. By way of example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a decentralized cloud, a cross-cloud, a multi-cloud, and the like, or any combination thereof.

In some embodiments, database 150 may be in communication with one or more components of O2O service system 100 (e.g., server 110, requester terminal 130, provider terminal 140, etc.) via network 120. One or more components of O2O service system 100 may access data or instructions stored in database 150 via network 120. In some embodiments, database 150 may be directly connected or in communication with one or more components of O2O service system 100 (e.g., server 110, requester terminal 130, provider terminal 140, etc.). In some embodiments, database 150 may be part of server 110.

In some embodiments, one or more components of O2O service system 100 (e.g., server 110, requestor terminal 130, provider terminal 140, etc.) may have access to database 150. In some embodiments, one or more components of O2O service system 100 may read and/or modify information related to requesters, providers, and/or the public when one or more conditions are satisfied. For example, server 110 may read and/or modify information for one or more users after servicing. For another example, when a service request is received from the requester terminal 130, the provider terminal 140 may access information related to the requester, but the provider terminal 140 may not modify the information related to the requester.

In some embodiments, the exchange of information by one or more components in O2O service system 100 may be accomplished via a request service. The object of the service request may be any product. In some embodiments, the product may be a tangible product or an intangible product. Tangible products may include food, pharmaceuticals, commodities, chemical products, appliances, clothing, automobiles, homes, luxury goods, and the like, or any combination thereof. Intangible products may include service products, financial products, knowledge products, internet products, and the like, or any combination thereof. The internet products may include personal host products, web products, mobile internet products, business host products, embedded products, and the like, or any combination thereof. The mobile internet product may be software, a program or a system for use on a mobile terminal, etc. or any combination thereof. The mobile terminal may include a tablet, a laptop, a mobile phone, a Personal Digital Assistant (PDA), a smart watch, a point of sale (POS) device, an onboard computer, an onboard television, a wearable device, and the like, or any combination thereof. For example, the product may be any software and/or application used on a computer or mobile phone. The software and/or applications may be related to social interaction, shopping, transportation, entertainment, learning, investment, and the like, or any combination thereof. In some embodiments, the transportation-related software and/or applications may include travel software and/or applications, vehicle scheduling software and/or applications, mapping software and/or applications, and/or the like. In the vehicle scheduling software and/or application, the vehicle may include horses, rickshaws (e.g., carts, bicycles, tricycles, etc.), cars (e.g., taxis, buses, personal cars, etc.), trains, subways, ships, aircraft (e.g., airplanes, helicopters, space shuttles, rockets, hot air balloons), and the like, or any combination thereof.

The above description is for illustrative purposes only and does not limit the scope of the present application. Many alternatives, modifications, and variations will be apparent to those skilled in the art. The features, structures, methods, and other features of the exemplary embodiments described herein may be combined in various ways to obtain additional and/or alternative exemplary embodiments. For example, the memory 130 may be a data storage comprising a cloud computing platform, which may be a public cloud, a private cloud, a community cloud, a hybrid cloud, and the like. However, variations and modifications may not depart from the scope of the present application.

FIG. 2 is a schematic diagram of exemplary hardware and/or software components of an exemplary computing device 200 that may implement the processing engine 112, according to some embodiments of the present application. As shown in fig. 2, computing device 200 may include a processor 210, a memory 220, input/output (I/O) ports 230, and communication ports 240.

Processor 210 may execute computer instructions (e.g., program code) and perform the functions of processing engine 112 in accordance with the techniques described herein. The computer instructions may include, for example, routines, programs, objects, components, data structures, procedures, modules, and functions that perform particular functions described herein. For example, processor 210 may process data obtained from server 110, requester terminal 130, provider terminal 140, database 150, and/or any other component of O2O service system 100. In some embodiments, processor 210 may include one or more hardware processors, such as microcontrollers, microprocessors, reduced instruction computers (RISC), Application Specific Integrated Circuits (ASIC), application specific instruction set processors (ASIP), Central Processing Units (CPU), Graphics Processors (GPU), Physical Processors (PPU), microcontroller units, Digital Signal Processors (DSP), Field Programmable Gate Arrays (FPGA), advanced reduced instruction system computers (ARM), Programmable Logic Devices (PLD), any circuit or processor capable of executing one or more functions, or the like, or any combination thereof.

For illustration only, only one processor in computing device 200 is described. It should be noted, however, that the computing device 200 may include multiple processors, and thus operations and/or method steps described herein as being performed by one processor may also be performed by multiple processors, collectively or independently. For example, if in the present application, the processors of computing device 200 perform process A and process B, it should be understood that process A and process B may also be performed jointly or independently by two or more different processors in computing device 200 (e.g., a first processor performs process A and a second processor performs process B; or a first processor and a second processor perform processes A and B together).

Memory 220 may store data/information obtained from server 110, requester terminal 130, provider terminal 140, database 150, and/or any other component of O2O service system 100. In some embodiments, memory 220 may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), and the like, or any combination thereof. Exemplary mass storage may include magnetic disks, optical disks, solid state drives, and the like. Exemplary removable storage may include flash memory, floppy disks, optical disks, memory cards, compact disks, magnetic tape, and the like. Exemplary volatile read and write memories can include Random Access Memory (RAM). Exemplary RAM may include Dynamic RAM (DRAM), double-data-rate synchronous dynamic RAM (DDR SDRAM), Static RAM (SRAM), thyristor RAM (T-RAM), zero-capacitance RAM (Z-RAM), and the like. Exemplary ROMs may include shielded ROM (MROM), Programmable ROM (PROM), erasable programmable ROM (PEROM), Electrically Erasable Programmable ROM (EEPROM), compact disk ROM (CD-ROM), digital versatile disk ROM, and the like. In some embodiments, memory 220 may store one or more programs and/or instructions to perform the example methods described herein. For example, the memory 220 may store a program that may cause the processing engine 112 to determine location information of a requester.

I/O230 may input and/or output signals, data, information, and the like. In some embodiments, I/O230 may enable interaction with processing engine 112. In some embodiments, I/O230 may include one input device and one output device. Exemplary input devices may include a keyboard, mouse, touch screen, microphone, etc., or any combination thereof. Exemplary output devices may include a display device, speakers, printer, projector, etc., or any combination thereof. Exemplary display devices may include Liquid Crystal Displays (LCDs), Light Emitting Diode (LED) based displays, flat panel displays, curved screens, television devices, Cathode Ray Tubes (CRTs), touch screens, and the like, or any combination thereof.

The communication port 240 may be connected to a network (e.g., network 120) to facilitate data communication. Communication port 240 may establish a connection between processing engine 112 and server 110, requester terminal 130, provider terminal 140, memory 150, and/or any other component in O2O service system 100. The connection may be a wired connection, a wireless connection, any other communication connection capable of enabling data transmission and/or reception, and/or any combination of these connections. The wired connection may include, for example, an electrical cable, an optical cable, a telephone line, etc., or any combination thereof. The wireless connection may comprise Bluetooth^TMConnection, Wi-Fi^TMConnection, WiMax^TMA connection, a WLAN connection, a ZigBee connection, a mobile network connection (e.g., 3G, 4G, 5G, etc.), and the like or any combination thereof. In some embodiments, the communication port 240 may be (or include) a standardized communication port, such as RS232, RS485, and the like. In some embodiments, the communication port 240 may be a specially designed communication port.

Fig. 3 is a diagram illustrating exemplary hardware and/or software components of an exemplary mobile device 300, on which the requester terminal 130 and/or the provider terminal 140 may be implemented, according to some embodiments of the present application. As shown in FIG. 3, mobile device 300 may include a communication platform 310, a display 320, a Graphics Processing Unit (GPU)330, a Central Processing Unit (CPU)340, I/O350, memory 360, and memory 390. In some embodiments, the mobile device 300 may also include any other suitable components, including but not limited to a system bus or a controller (not shown). In some embodiments, an operating system 370 (e.g., iOS)^TM、Android^TM、Windows Phone^TMEtc.) and one or more application programs 380 may be loaded from memory 390 into memory 360 for execution by CPU 340. The application 380 may include a browser or any other suitable mobile application for receiving and presenting information regarding service requests or other information from the processing engine 112. Interaction of the information flow with the user may be accomplished through I/O350 and provided to processing engine 112 and/or other components of O2O service system 100 through network 120.

To implement the various modules, units and their functions described in this application, a computer hardware platform may be used as the hardware platform for one or more of the elements described in this application. A computer with user interface elements may be used to implement a Personal Computer (PC) or any other type of workstation or external device. The computer may also function as a server if suitably programmed.

FIG. 4 is a schematic diagram of an exemplary processing engine 112 shown in accordance with some embodiments of the present application. The processing engine 112 may include an acquisition module 402, a control module 404, a processing module 406, and a storage module 408. At least a portion of processing engine 112 may be implemented on a computing device as shown in fig. 2 or a mobile device as shown in fig. 3.

The acquisition module 402 may obtain service request related data. In some embodiments, the acquisition module 402 may obtain service request related data from the server 110, the requester terminal 130, the provider terminal 140, the database 150, and/or an external data source (not shown). In some embodiments, the service request related data may include raw data (e.g., location data), instructions, and the like, or a combination thereof. For example, raw coordinate data representing the location of the requester may be obtained based on a positioning technology (e.g., GPS positioning technology) possessed by the requester terminal 130. The instructions may be executed by a processor of the processing engine 112 to implement the example methods described herein. In some embodiments, the acquired data may be transmitted to the storage module 408 for storage.

The control module 404 may control the acquisition module 402, the storage module 408, the processing module 406 (e.g., by generating one or more control parameters), the server 110, and the like, or any combination thereof. For example, the control module 404 may control the acquisition module 402 to acquire data related to the service request, to acquire the data at a certain time, and the like. As another example, the control module 404 may control the processing module 406 to process service request related data that has been acquired by the acquisition module 402. In some embodiments, the control module 404 may receive real-time instructions or predetermined instructions from a user to control one or more operations of the acquisition module 402 and/or the processing module 406. For example, the control module 404 may adjust the acquisition module 402 and/or the processing module 406 to generate one or more service request related data according to real-time instructions and/or predetermined instructions. In some embodiments, the control module 404 may communicate with one or more other modules of the processing engine 112 for information and/or data exchange.

The storage module 408 may store service request related data, control parameters, processed service request related data, and the like, or any combination thereof. In some embodiments, the memory module 408 may store one or more programs and/or instructions that may be executed by a processor of the processing engine 112 to implement the example methods described herein. For example, the memory module 408 may store programs and/or instructions that may be executed by a processor of the processing engine 112 to obtain service request related data based on which a service provider (e.g., a candidate vehicle) may be determined.

Processing module 406 may process information provided by multiple modules of processing engine 112. The processing module 406 may process service request related data that has been obtained by the acquisition module 402, service request related data obtained from the storage module 408 and/or the memory 130, and the like. In some embodiments, the processing module 406 may process the acquired service related data to synchronize the service related data. For example: when the passenger completes the order for placing the car, the O2O service system 100 may retrieve and update the data related to the completed passenger order. After updating the passenger order related data, the processing module 406 may synchronize the updated data between the various data centers in the database 150 via a sliding window mechanism.

In some embodiments, one or more of the modules shown in FIG. 4 may be implemented in at least a portion of O2O service system 100 shown in FIG. 1. For example, the acquisition module 402, the control module 404, the storage module 408, and/or the processing module 406 may be integrated into the requester terminal 130 and/or the provider terminal 140. In some embodiments, the service requester may set relevant parameters of the service request, a start time of the service request, and the like through the requester terminal 130. In some embodiments, the O2O service system 110 may automatically allocate a service provider satisfying a condition for a service requester according to the relevant parameters of the service request set by the service requester and the start time information of the service request. In some embodiments, through the provider terminal 140, the service provider may select whether to provide the service for the service requester according to the obtained parameters set by the service requester.

Fig. 5 is a block diagram illustrating an exemplary processing module 406 according to some embodiments of the present application. The processing module 406 may include an acquisition module 502, a write module 504, a send module 506, and a send queue maintenance module 508. The processing module 406 may be implemented on a plurality of components (e.g., the processor 210 of the computing device 200 shown in fig. 2). For example, at least a portion of the processing module 406 may be implemented on a computing device as shown in fig. 2 or a mobile device as shown in fig. 3.

The obtaining module 502 may obtain and obtain at least one data to be synchronized. Each piece of data to be synchronized corresponds to a data sequence number, and the data sequence number reflects the time sequence of the corresponding data to be synchronized, which is acquired by the first data center. In some embodiments, the time information of the data to be synchronized acquired by the first data center may also be directly used as the data sequence number. For example, the data to be synchronized may be D1, D2, D3 and D4, and the corresponding times acquired by the first data center are T1, T2, T3 and T4. The processing module 406 may assign a data sequence number to each data to be synchronized, such as Seq1, Seq2, Seq3, and Seq 4. The size of the data sequence number can reflect the sequence of the data to be synchronized acquired by the first data center. For example, the data sequence number may monotonically increase, or monotonically decrease, with the time that the first data center acquires the data to be synchronized. The obtaining module 502 may also directly use the times T1, T2, T3, and T4 when the data D1, D2, D3, and D4 to be synchronized are obtained by the first data center as the data sequence numbers of the data to be synchronized.

In some embodiments, the data to be synchronized may be user-related data, e.g., registration information of a user. The registration information of the user may include the user's name, gender, age, preferences, etc., or any combination thereof. The user-related data also includes order data for the user. The order data includes time, place, type, etc. of the order. The user-related data also includes other data that is predicted based on the user's order data, such as the probability that the user will use a certain type of service (e.g., taxi-taking service, take-away service, etc.). In some embodiments, the obtaining module 502 may communicate with the requester terminal 130 and/or the provider terminal 140 via the network 120 to obtain the desired data to be synchronized.

The write module 504 may write the data to be synchronized into a storage device of the first memory. In some embodiments, the first data center may include a plurality of storage devices, and the writing module 504 may write the acquired data to be synchronized into any one or more storage devices in the first data center.

The sending module 506 may send the data to be synchronized to the second data center for synchronization based on the time sequence reflected by the data sequence number and the receiving status of the data to be synchronized on the second data center.

The transmit queue maintenance module 508 can maintain at least one transmit queue. The transmission queue may record a data sequence number of at least one transmitted data to be synchronized. The sending module 506 may send the data to be synchronized to the second data center for synchronization based on the sending queue. After the data to be synchronized is sent to the second data center, the sending queue maintenance module 508 may further record the data sequence number corresponding to the data to be synchronized into the sending queue.

The sending queue maintenance module 508 may further determine whether arrival information of the to-be-synchronized data corresponding to the data sequence with the earliest time sequence reflected in the sending queue, which is fed back by the second data center, is received, and if yes, delete the data sequence from the sending queue; if not, the data sequence number in the sending queue is reserved, and the data sequence number reflected in the sending queue and following the data sequence number is reserved.

In some embodiments, the first data center may maintain a sending queue, and sequentially write the data sequence numbers into the sending queue according to the time sequence. Further, the first data center may send the at least one piece of data to be synchronized to the second data center based on the data sequence numbers in the sending queue, where a sending sequence of the at least one piece of data to be synchronized is consistent with a time sequence reflected by the data sequence numbers in the sending queue.

It should be noted that the above description of processing module 406 is for illustrative purposes only and is not intended to limit the scope of the present application. Many variations or modifications may be made as indicated by the teaching of the present application to those skilled in the art. However, such variations and modifications do not depart from the scope of the present application.

FIG. 6 is an exemplary flow diagram illustrating synchronization of data between services according to some embodiments of the present application. In some embodiments, flow 600 may include: a first data center acquires at least one piece of data to be synchronized; each piece of data to be synchronized corresponds to a data sequence number, the data sequence number reflects a time sequence 602 that the corresponding piece of data to be synchronized is acquired by the first data center, the piece of data to be synchronized is written into the storage device 604, and the piece of data to be synchronized is sent to the second data center for synchronization 606 based on the time sequence reflected by the data sequence number and a receiving state of the piece of data to be synchronized on the second data center. In some embodiments, one or more operations of flow 600 shown in FIG. 6 for data synchronization among a plurality of services may be implemented in O2O service system 100 shown in FIG. 1. For example, the flow 600 illustrated in fig. 6 may be stored in the memory 130 in the form of instructions and invoked and/or executed by the processing engine 112 (e.g., the processor 210 of the computing apparatus 200 illustrated in fig. 2, the CPU 340 of the mobile device 300 illustrated in fig. 3).

In step 602, a first data center may obtain at least one data to be synchronized. Each piece of data to be synchronized corresponds to a data sequence number, and the data sequence number reflects the time sequence of the corresponding data to be synchronized, which is acquired by the first data center.

Step 602 may be performed by acquisition module 502. In some embodiments, the time information of the data to be synchronized acquired by the first data center may also be directly used as the data sequence number. For example, the data to be synchronized may be D1, D2, D3 and D4, and the corresponding times acquired by the first data center are T1, T2, T3 and T4. The processing module 406 may assign a data sequence number to each data to be synchronized, such as Seq1, Seq2, Seq3, and Seq 4. The size of the data sequence number can reflect the time sequence of the first data center acquiring the data to be synchronized. The processing module 406 may also directly use the times T1, T2, T3, and T4 of the data D1, D2, D3, and D4 acquired by the first data center as the data sequence numbers of the data to be synchronized.

In step 604, the first data center may write the data to be synchronized to its storage device. Step 604 may be performed by write module 504. In some embodiments, the first data center may include a plurality of storage devices, and the writing module 504 may write the acquired data to be synchronized into any one or more storage devices in the first data center.

In step 606, the data to be synchronized may be sent to the second data center for synchronization based on the time sequence reflected by the data sequence number and the receiving status of the data to be synchronized on the second data center. Step 606 may be performed by sending module 506.

In some embodiments, the first data center may maintain a sliding window, and sequentially write the data sequence numbers into the sliding window according to the time sequence. Further, the first data center may send the at least one piece of data to be synchronized to the second data center based on the data sequence number in the sliding window, where a sending order of the at least one piece of data to be synchronized corresponds to the data sequence number in the sliding window.

In some embodiments, the first data center directly sends a plurality of data to be synchronized and their corresponding data sequence numbers reflecting the time sequence to the second data center in a parallel manner. The second data center may reorder the plurality of data to be synchronized according to the data sequence number.

It should be noted that the above description is for illustrative purposes only and is not intended to limit the scope of the present application. Many variations or modifications may be made as indicated by the teaching of the present application to those skilled in the art. However, such variations and modifications do not depart from the scope of the present application. For example, flow 600 may include a step before 604 for examining the data to be synchronized to determine its accuracy.

FIG. 7 is an exemplary flow diagram 700 illustrating ensuring data arrives in order, according to some embodiments of the present application. Flow 700 may be performed by processing module 406. In some embodiments, step 606 shown in FIG. 6 may be performed in accordance with flow 700. In some embodiments, one or more operations of flow 700 shown in fig. 7 may be implemented in O2O service system 100 shown in fig. 1. For example, the flow 700 shown in fig. 7 may be stored in the memory 130 in the form of instructions and invoked and/or executed by the processing engine 112 (e.g., the processor 210 of the computing apparatus 200 shown in fig. 2, the CPU 340 of the mobile device 300 shown in fig. 3).

In step 702, at least one sending queue for recording data sequence numbers of sent data to be synchronized may be maintained. Step 702 may be performed by transmit queue maintenance module 508. In some embodiments, the processing module 406 may maintain a send queue in the first data center according to a sliding window mechanism. The transmission queue may include a data sequence number of data to be synchronized, where a transmission order of the transmission queue corresponds to the data sequence number of the data to be synchronized. For example, the data sequence number of the data to be synchronized that is sent first is smaller than the data sequence number of the data to be synchronized that is sent later. In some embodiments, the transmission queue may further include transmission time information of data to be synchronized.

In step 704, the data to be synchronized may be transmitted to a second data center for synchronization based on the transmit queue. Step 704 may be performed by sending module 506. In some embodiments, after writing the data sequence numbers into the sending queue, the sending module 506 may send the corresponding data to be synchronized to the second data center in sequence based on the size of the data sequence in the sending queue. In some embodiments, the first data center may send the data to be synchronized to the second data center in sequence according to the time sequence of obtaining the data to be synchronized, that is, the time sequence reflected by the data sequence number of the data to be synchronized, and then write the data sequence number corresponding to the sent data to be synchronized into the sliding window. In some embodiments, a plurality of data sequence numbers corresponding to a plurality of data to be synchronized may also be stored in the sending queue.

In some embodiments, when receiving the data to be synchronized sent by the first data center, the second data center feeds back arrival information of the data to be synchronized to the first data center.

In step 706, it may be determined whether arrival information of the to-be-synchronized data corresponding to a data sequence number in the sending queue fed back by the second data center is received, and the data sequence number in the sending queue is further processed based on the determination result. Step 706 may be performed by transmit queue maintenance module 508. In some embodiments, after sending the data to be synchronized to the second data, the data sequence number corresponding to the sent data to be synchronized still exists in the sending queue maintained by the first data center. At this time, the sending queue maintaining module 508 needs to further determine whether the first data center receives the arrival information of the to-be-synchronized data fed back by the second data center. If the reaching information is received, step 708 is executed to delete the data sequence number of the data to be synchronized, which has been received by the second data center, from the sliding window. If the reaching information is not received, step 710 is executed, and the data sequence number needs to be reserved in the sliding window.

In step 708, when receiving arrival information of the to-be-synchronized data corresponding to a certain data sequence number in the sending queue fed back by the second data center, the data sequence number may be deleted from the sending queue. In some instances, if the time sequence reflected by the data sequence number is the earliest in the transmit queue, the data sequence number is deleted, and if there are other data sequence numbers in the transmit queue and the reflected time sequence is earlier than the data sequence number, the data sequence number continues to be retained in the transmit queue.

After the data sequence number corresponding to the data to be synchronized that has been sent and has been confirmed to be received is deleted from the sending sequence, the sending queue maintaining module 508 may further write the subsequent data sequence number of the data to be synchronized that has not been sent into the sending sequence to send the corresponding data to be synchronized. In some embodiments, the processing module 406 may determine the size of the data to be synchronized corresponding to the data sequence number of the data to be synchronized that has not been sent yet, and the size of the data to be synchronized that can be accepted in the second data center. If the size of the data to be synchronized sent by the tape is larger than the data to be synchronized which can be accepted in the second data center, temporarily not writing the data sequence number of the data to be synchronized which is not sent yet into the sending queue, and waiting for the second data center to release space until the space in the second data center is larger than the size of the data to be synchronized which is not sent yet. At this time, the data sequence number corresponding to the data to be synchronized that has not been sent is written into a sending queue, and the data to be synchronized that has not been sent is further sent to the second data center.

In step 710, the data sequence number in the send queue may be retained, and the data sequence number reflected in the send queue that follows the data sequence number may be retained. Step 710 may be performed by transmit queue maintenance module 508. When the data arrival information fed back by the second data center is not received, the sending queue maintenance module 508 will keep the data sequence number corresponding to the data to be synchronized in the sending queue.

In some embodiments, it may happen that arrival information of data to be synchronized corresponding to a certain data sequence number in a certain sending queue is not received, and arrival information of data to be synchronized corresponding to a data sequence number that is reflected in a time sequence after the data sequence number is received. At this time, the processing module 406 does not delete the data sequence number after the data sequence number, which is reflected in the time sequence after the data sequence number, while keeping the data sequence number of the to-be-synchronized data, which does not receive the data arrival fed back by the second data center. For example, the sending queue includes four data sequence numbers of Seq1, Seq2, Seq3, and Seq4, and the corresponding data to be synchronized are D1, D2, D3, and D4. The first data center does not receive the arrival information of the data to be synchronized D2 fed back by the second data center, but receives the arrival information of the data to be synchronized D1, D3 and D4. At this time, the processing module 406 deletes the data sequence number Seq1 corresponding to the data to be synchronized D1 in the sliding window, and retains all the data sequence numbers Seq2, Seq3 and Seq4 which follow the earliest data to be synchronized D2 which has not received the feedback information.

In step 712, it may be determined whether the retention time of the data sequence number in the sending queue is overtime, and if yes, the data to be synchronized corresponding to the data sequence number and the data to be synchronized corresponding to the data sequence number reflected in the sending queue after the data sequence number are sent to the second data center again. Step 712 may be performed by sending module 506. In some embodiments, after the data to be synchronized is sent to the second data center, a timer is further started, and when the data arrival information fed back by the second data center is not received after the set time is exceeded, the processing module 406 will re-send the data sequence number corresponding to the data to be synchronized in the queue. In some embodiments, after the data to be synchronized is sent to the second data center, a timer is further started, and the sending module 506 determines whether the time for retaining the data sequence number in the sending queue exceeds a time threshold. The retention time may be determined based on a current time and a transmission time of the data to be synchronized. In some embodiments, when the retention time exceeds the time threshold, the sending module 506 will resend the data to be synchronized corresponding to the data sequence and the data to be synchronized corresponding to the data sequence number reflected in the sending queue after the data sequence number to the second server. In some embodiments, when the retention time exceeds the time threshold, the sending module 506 may resend the data sequence number and the corresponding data to be synchronized to the second data center only. And the data to be synchronized, which is sent and received the data arrival information fed back by the second data center, does not need to be sent again. At this time, in the second data center, the data to be synchronized may be rearranged according to the data sequence number of the data to be synchronized that has been received, so as to realize in-order reception of the data.

In some embodiments, when the first data center fails to receive the feedback information of the second service due to an emergency such as a downtime, a power outage, or a connection interruption of the first data center, the data sequence number corresponding to the to-be-synchronized data that does not receive the arrival information may be kept in the sliding window. And when the first data center returns to normal until the condition is relieved, the first data center resends the data to be synchronized corresponding to the data sequence which is reflected with the earliest time sequence and does not receive the arrival information fed back by the second data center and the data to be synchronized corresponding to the data sequence which is reflected in the sending queue and is behind the data sequence.

It should be noted that the description regarding the flow 700 is for illustrative purposes and is not intended to limit the scope of the present application. It will be apparent to those skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope of the invention. However, such variations and modifications do not depart from the scope of the present application. For example, steps 702 and 704 may be performed simultaneously. As another example, step 704 may be performed after step 702.

Compared with the prior art, the beneficial effects that the above embodiments of the present application may bring include but are not limited to: :

firstly, direct point-to-point data transmission among different databases can be realized based on a sliding window mechanism without a third-party middleware, and the efficiency of data synchronization can be effectively improved.

And secondly, a sliding window mechanism is adopted to ensure that data can arrive reliably and sequentially and realize the function of breakpoint continuous transmission. Where reliable arrival of data refers to ensuring that each sent data to be synchronized has been received by the receiving end data center. The sequential arrival refers to synchronizing the data to be synchronized to other data centers according to the acquisition time sequence of the data to be synchronized, so that the condition that the same variable is covered by different numerical values in different sequences to cause different values of the same variable on different data centers is prevented. It is to be noted that different embodiments may produce different advantages, and in different embodiments, any one or combination of the above advantages may be produced, or any other advantages may be obtained.

Those skilled in the art will appreciate that various modifications and improvements may be made to the disclosure herein. For example, the different system components described above are implemented by hardware devices, but may also be implemented by software solutions only. For example: the system is installed on an existing server. Further, the location information disclosed herein may be provided via a firmware, firmware/software combination, firmware/hardware combination, or hardware/firmware/software combination.

The foregoing describes the present application and/or some other examples. The present application is susceptible to various modifications in light of the above teachings. The subject matter disclosed herein can be implemented in various forms and examples, and the present application can be applied to a wide variety of applications. All applications, modifications and variations that are claimed in the following claims are within the scope of this application.

Also, this application uses specific language to describe embodiments of the application. Reference throughout this specification to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the present application is included in at least one embodiment of the present application. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or more embodiments of the present application may be combined as appropriate.

Additionally, the order in which elements and sequences of the processes described herein are processed, the use of alphanumeric characters, or the use of other designations, is not intended to limit the order of the processes and methods described herein, unless explicitly claimed. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it is to be understood that such detail is solely for that purpose and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements that are within the spirit and scope of the embodiments herein. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by software-only solutions, such as installing the described system on an existing server or mobile device.

Similarly, it should be noted that in the preceding description of embodiments of the application, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the embodiments. This method of disclosure, however, is not intended to require more features than are expressly recited in the claims. Indeed, the embodiments may be characterized as having less than all of the features of a single embodiment disclosed above.

Numbers describing attributes, quantities, etc. are used in some embodiments, it being understood that such numbers used in the description of the embodiments are modified in some instances by the use of the modifier "about", "approximately" or "substantially". Unless otherwise indicated, "about", "approximately" or "substantially" indicates that the number allows a variation of ± 20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximations that may vary depending upon the desired properties of the individual embodiments. In some embodiments, the numerical parameter should take into account the specified significant digits and employ a general digit preserving approach. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of the range are approximations, in the specific examples, such numerical values are set forth as precisely as possible within the scope of the application.

Each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, articles, and the like, cited in this application is hereby incorporated by reference in its entirety. Except where the application is filed in a manner inconsistent or contrary to the present disclosure, and except where the claim is filed in its broadest scope (whether present or later appended to the application) as well. It is noted that the descriptions, definitions and/or use of terms in this application shall control if they are inconsistent or contrary to the statements and/or uses of the present application in the material attached to this application.

Finally, it should be understood that the embodiments described herein are merely illustrative of the principles of the embodiments of the present application. Other variations are also possible within the scope of the present application. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the present application can be viewed as being consistent with the teachings of the present application. Accordingly, embodiments of the present application are not limited to those explicitly described and depicted herein.

Claims

1. A method for data synchronization between multiple data centers, comprising:

a first data center acquires at least one piece of data to be synchronized; each data to be synchronized corresponds to a data sequence number, and the data sequence number reflects the time sequence of the corresponding data to be synchronized, which is acquired by the first data center;

the first data center writes the data to be synchronized into at least one storage device of the first data center;

the first data center sends the data to be synchronized to a second data center for synchronization based on the time sequence reflected by the data sequence number and the receiving state of the data to be synchronized at the second data center;

the first data center maintains at least one sending queue, the sending queue is at least used for recording at least one data sequence number of sent data to be synchronized, the first data center judges whether the retention time of a certain data sequence number in the sending queue is overtime, and if yes, the data to be synchronized corresponding to the data sequence number and the data to be synchronized corresponding to the data sequence number of which the time sequence reflected in the sending queue is behind the data sequence number are sent to the second data center again.

2. The method of claim 1, wherein the first data center sending data to be synchronized to a second data center for synchronization based on the chronological order reflected by the data sequence numbers further comprises: and the first data center sequentially sends the data to be synchronized to the second data center for synchronization according to the time sequence reflected by the data sequence number.

3. The method of claim 1, wherein the first data center maintaining at least one send queue further comprises:

after the first data center sends some data to be synchronized to the second data center, the data sequence number corresponding to the data to be synchronized is recorded in the sending queue.

4. The method of claim 1, wherein the first data center maintaining at least one send queue further comprises: the first data center judges whether the arrival information of the data to be synchronized corresponding to the data sequence number with the earliest time sequence reflected in the sending queue fed back by the second data center is received or not,

if yes, deleting the data sequence number from the sending queue;

if not, the data sequence number in the sending queue is reserved, and the data sequence number reflected in the sending queue and following the data sequence number is reserved.

5. The method of claim 1, wherein the transmit queue is stored in at least one storage device of the first data center.

6. A system for data synchronization between multiple data centers, located in a first data center, comprising: an acquisition module, a write-in module and a sending module,

the acquisition module is used for acquiring at least one piece of data to be synchronized; each data to be synchronized corresponds to a data sequence number, and the data sequence number reflects the time sequence of the corresponding data to be synchronized, which is acquired by the first data center;

the writing module is used for writing the data to be synchronized into at least one storage device of a first data center;

the sending module is used for sending the data to be synchronized to a second data center for synchronization based on the time sequence reflected by the data sequence number and the receiving state of the data to be synchronized at the second data center;

7. The system according to claim 6, wherein the sending module is further configured to send the data to be synchronized to the second data center in sequence according to the time sequence reflected by the data sequence number for synchronization.

8. The system of claim 6, wherein the transmit queue maintenance module is further configured to:

and after a certain data to be synchronized is sent to the second data center, recording the data sequence number corresponding to the data to be synchronized into a sending queue.

9. The system of claim 6, wherein the transmit queue maintenance module is further configured to:

judging whether arrival information of the data to be synchronized corresponding to the data sequence number with the earliest time sequence reflected in the sending queue fed back by the second data center is received or not,

if yes, deleting the data sequence number from the sending queue;

10. The system of claim 6, wherein the transmit queue is stored in at least one storage device of the first data center.

11. A computer-readable storage medium for storing computer instructions, wherein the computer instructions stored in the storage medium, when read by a computer, cause the computer to perform the method for data synchronization between multiple data centers as recited in any one of claims 1-5.

12. An apparatus for synchronizing data between multiple data centers, comprising at least one processor and at least one storage medium;

the at least one storage medium is configured to store computer instructions;

the at least one processor is configured to execute the computer instructions to implement the method for data synchronization between multiple data centers as recited in any of claims 1-5.