CN116089169A

CN116089169A - Account returning method, device and equipment

Info

Publication number: CN116089169A
Application number: CN202310092112.3A
Authority: CN
Inventors: 李立
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced Nova Technology Singapore Holdings Ltd
Priority date: 2018-01-09
Filing date: 2018-01-09
Publication date: 2023-05-09
Also published as: CN108345516A; CN108345516B

Abstract

The embodiment of the specification discloses an account returning method, device and equipment. The account number billing frequency and the business importance are reflected by integrating the historical transaction data of the user account, account billing modes, account number types of the account and other factors, and the returning importance degree of the account number is comprehensively obtained, so that the account number is returned according to the high-low order of the importance degree.

Description

Account returning method, device and equipment

The application is a divisional application of Chinese patent application CN108345516A, and the application date of the original application is as follows: 2018, 1 month and 9 days; the application number is: 201810018524.1; the invention is named as follows: an account returning method, device and equipment.

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method, an apparatus, and a device for account migration.

Background

The database is unexpectedly network failed or is unexpectedly terminated abnormally, resulting in the unavailability of all services, called database failure, FO (typically occurring on the master repository). The process of restoring the database, component or service in the fault state to the original working state and restoring the standby system from the restored working state to the standby state is called database fallback, abbreviated FB.

In the FB process, when the disaster of the master repository is difficult, a certain time is generally required to pull up the standby repository, and in this time, in order to ensure that the service is performed normally, account data is written into a FO (factory) repository (which may also be referred to as a temporary master repository). Thus, after the backup library is pulled, the account data in the FO library needs to be rewritten to the master library (backup library), referred to as account migration. In the account returning process, for business needs, it should be ensured that hot accounts (accounts with frequent transactions or high importance) are returned preferentially.

Based on this, a more efficient account migration method is needed.

Disclosure of Invention

The embodiment of the specification provides an account returning method, device and equipment, which are used for solving the following problems: to provide a more efficient method of account migration.

Based on this, the embodiment of the present disclosure provides an account returning method, including:

acquiring related information of an account to be reverted;

determining the returning weight of each account to be returned according to the related information;

performing account returning according to the sequence of the returning weights;

the related information of the account to be reverted comprises at least one of the size, account billing mode and account number of historical transaction data of the account to be reverted.

Meanwhile, the embodiment of the present disclosure further provides an account returning device, including:

the method comprises the steps of obtaining relevant information of an account to be reverted, wherein the relevant information of the account to be reverted comprises at least one of the size of historical transaction data of the account to be reverted, an account billing mode and an account number;

the determining module is used for determining the returning weight of each account to be returned according to the related information;

and the returning module is used for returning the account according to the sequence of the returning weights.

Correspondingly, the embodiment of the specification also provides account returning equipment, which comprises:

a memory storing an account returning program;

and the processor calls an account returning program in the memory and executes:

acquiring related information of an account to be reverted;

Correspondingly, embodiments of the present specification also provide a non-volatile computer storage medium storing computer executable instructions arranged to:

acquiring related information of an account to be reverted;

The above-mentioned at least one technical scheme that this description embodiment adopted can reach following beneficial effect:

the account counting frequency and the business importance of the account are reflected by integrating the historical transaction data of the user account, the account counting mode, the account number type of the account and other factors, and the returning importance degree of the account is comprehensively obtained, so that the returning importance degree is sequentially carried out according to the importance degree, the residence time of the hot-spot account with frequent transaction in the FB stage is reduced, the number of the affected transactions is reduced as much as possible, and the user experience is improved.

Drawings

FIG. 1 is a schematic diagram of account snapshot data provided in an embodiment of the present disclosure;

FIG. 2 is a schematic diagram of a system architecture according to an embodiment of the present disclosure;

FIG. 3 is a flowchart illustrating an account migration method according to an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of a business process provided in an embodiment of the present disclosure;

fig. 5 is a schematic structural diagram of an account returning device according to an embodiment of the present disclosure.

Detailed Description

For the purposes, technical solutions and advantages of the present application, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present application based on the embodiments herein.

In general, a database that provides database services for applications for a long time is called a master, and at the same time, there is a database (backup) for backup, where the backup is used as a backup of the master, and data consistency is ensured through synchronization of the master and the backup, and the master is responsible for assuming the role of the master after a disaster, and becomes a new master. Meanwhile, in some fields (such as payment field and financial field), a snapshot database exists in case of a higher security level. The snapshot database is different Yu Beiku, and is mainly used for performing snapshot backup on data of an account in the main database (for example, for recording account balance, daily variation, account funds variation details, etc.) when the main database is operating normally, as shown in fig. 1, fig. 1 is a schematic diagram of account snapshot data provided in the embodiment of the present disclosure. In other words, the snapshot database is not a complete backup, but it reflects schematically the situation of the account history transactions. Obviously, if the hardware can support, the historical transaction data in the snapshot database can snapshot more records and can also more fully reflect the historical situation of one account. In other words, snapshot data is one of the historical transaction data, which may also be other more detailed transaction data.

When the main library is in disaster, a certain time is needed for pulling up the standby library as a new main library due to reasons such as data synchronization, so that in order to reduce service loss, the FO library bears temporary main library responsibilities during the pulling up of the standby library, receives normal service requests, processes the service, for example, supports main services such as account opening and accounting in the FO scene, and ensures the high availability of the main service in the downed scene of the main library.

After the new main library is established (generally, the standby library is successfully started), the data of the account, the accounting certificate, the xts transaction and the like which are subjected to the business in the FO library are required to be migrated back to the new main library, in this case, due to the requirement of the business (for example, two account numbers of the same accounting request are migrated back to the new main library, and the other account number is not migrated back to the FO library, because the two account numbers are routed to two different databases, the request is intercepted by the transaction, the accounting is failed, so that the user requests refund), in order to reduce the accounting failure in the stage as much as possible, the transaction number of automatic refund is reduced, the importance degree of the account is required to be analyzed for the migration of the account, and the account number with high importance degree is ensured to be quickly migrated.

Based on the foregoing, the embodiments of the present disclosure provide an account migration method, which reflects the billing frequency and the business importance of an account by integrating multiple factors of the user account, and comprehensively obtains the migration weight of the account, so as to migrate according to the order of the migration weight,

in the embodiment of the present disclosure, the account returning method may adopt an architecture shown in fig. 2, fig. 2 is a schematic diagram of a system architecture according to the embodiment of the present disclosure, and the account returning process provided in the embodiment of the present disclosure will be described in detail based on the architecture shown in fig. 2, where the process specifically includes the following steps, as shown in fig. 3, and fig. 3 is a schematic flow diagram of the account returning method provided in the embodiment of the present disclosure, where the method includes:

s301, acquiring relevant information of the account to be migrated.

The related information of the account to be reverted comprises at least one of the size of historical transaction data of the account to be reverted, an account billing mode and an account number.

Specifically, in the architecture, account history transaction data is stored in a snapshot database, and the FO library serves as a temporary master library to see from the snapshot database that any account history transaction snapshot data can be obtained. The account billing mode is generally configured by the user according to the user's requirement, and the account is obtained from the FO database, and is mainly used for distinguishing the category of the account, including public account, private account, internal account, and the like, so as to determine the importance of the account according to the category.

S303, determining the returning weight of each account to be returned according to the related information.

Based on the foregoing, in this process, the calculation of the transition weight may be performed according to a certain information, for example, the weight is directly given based on the size of the account historical transaction snapshot data, and the greater the historical transaction snapshot data, the higher the weight is given; the calculation of the transition weight may be performed by integrating a plurality of pieces of information. For example, the weights of the accounts are determined together based on the account billing pattern and the size of the account history transaction snapshot data for account rejections.

S305, performing account returning according to the order of the returning weights.

Generally, the active account and the important account have higher weight, and account returning is performed according to the weight sequence.

By integrating historical transaction data of a user account, account billing modes, account number types of the account and other factors reflect billing frequency and business importance of the account, the returning importance degree of the account is comprehensively obtained, so that the returning importance degree is sequentially carried out according to the importance degree, the residence time of the hot-spot account with frequent transaction in the FB stage is reduced, the number of affected transactions is reduced as much as possible, and the user experience is improved.

As a specific implementation manner, for the step S303, determining the return weight of each account to be returned according to the related information, and when calculating the weight according to the historical transaction data of the account to be returned, the following manner may be adopted:

determining an average size of account historical transaction data; for any account to be reverted, calculating the ratio of the size of historical transaction data of the account to be reverted to the average size of the historical transaction data of the account to be reverted, and generating a first weight factor; and calculating the returning weight of the account according to the first weight factor.

Specifically, the average size of the account history transaction data may be the average size of the snapshot data of all accounts in the snapshot database, or the average size of the snapshot data of all accounts to be migrated. That is, a first weighting factor α is set that characterizes the importance of account history transaction data, wherein: α=the snapshot size of the account/the average snapshot size of the snapshot database, or α=the snapshot size of the account/the average snapshot size of the account to be reverted. Generally, the former calculation is more convenient, and account reversion can be performed in batches, and the latter calculation is more targeted.

As a specific implementation manner, for the step S303, determining the returning weight of each account to be returned according to the related information, when the weight calculation is performed according to the account billing mode, the following manner may be adopted:

determining a second weight factor of any account to be reverted according to the account billing mode of the account; wherein the billing mode comprises real-time billing, buffer billing or summary billing; and calculating the returning weight of the account according to the second weight factor.

Specifically, in payment applications, a general billing account supports three billing modes: real-time billing, aggregate billing, or buffered billing. The billing mode can be set in advance according to the actual needs of the account.

Real-time billing, as the name suggests, is that the balance varies in real time after account billing is completed. And (3) summarizing and accounting, wherein the summary and accounting is opposite to the real-time accounting, namely, only recording summary and accounting details after the account accounting is completed, not modifying the account balance, summarizing the whole change amount when the day is cut, and reflecting the whole change amount on the balance once. The buffer billing is a compromise result of real-time billing and summary billing, an account of the buffer billing is configured, when the billing is completed, the list of the buffer billing is recorded, the specified number list is fetched by a timing task of the recovery of the buffer billing, after the change amount is calculated, the change amount is reflected on the balance at one time, and the change frequency of the balance of the account depends on the frequency of the timing task.

In other words, an account for summary accounting or buffer accounting needs to be set, which is usually a hot spot account, and the account transaction amount is more, and the account is more important. Thus, the account for aggregate billing or buffer billing should be given a higher weighting factor.

For example, setting a second weight factor β characterizes the importance of the account billing mode, wherein: if the current account is configured with aggregate billing or buffered billing, then β=0.6; if the current account billing mode is real-time billing, β=0.4.

As a specific implementation manner, for the step S303, determining the returning weight of each account to be returned according to the related information, when the weight is calculated according to the user account, the following manner may be adopted:

aiming at any account to be migrated, acquiring a designated field in the account; determining a third weight factor of the account according to the value of the designated field; and calculating the returning weight of the account according to the third weight factor.

As described above, the account numbers of the customer account are mainly classified into public account numbers, private account numbers and partial internal account numbers, wherein the public account numbers include company and merchant accounts, and the private account numbers are balance accounts (including buyers and sellers) of users; the different types of account numbers are typically distinguished by being distinguished on a specified field of the account number code.

For example, code 21881 XXXXXXXXXXXXXXXX is a merchant account, 21882XXXXXXXXXXXXX is a personal balance user, 21883 XXXXXXXXXXXXXXXX is an internal account, and the different account categories are determined by the first 5 digits.

In general, business volume such as account transfer, money release, refund and the like of merchants are larger than that of individual balance users; the small number of households, typically transitional households, vouchers, etc., account for a much larger amount than the individual balance households. Based on this, the internal account or merchant account may be given a higher weighting factor in advance.

For example, a third weight factor γ is set to characterize the importance of the account category, wherein: γ=0.6 if the current account is 21881 or 21883 head account, and γ=0.4 if the current account is 21882 head account.

The second weight factor beta and the third weight factor gamma can be set manually based on experience, and can be dynamically adjusted according to the returning service result in practical application.

As described above, for the return weight of the account to be returned, the return weight of the current account may be set to be: the back transition weight Weight (account) =α×β×γ×100. Obviously, the specific calculation formula can be adjusted according to the actual situation, and is not limited to the above formula.

The calculation of the migration weight may be performed in real time, and as a specific embodiment, the method further includes: and storing the back migration weight to the local. The local is referred to herein as a FO database serving as a temporary master, for example, the value is given to an FO record table (ip_failure_record), and when account migration is required, the value is performed according to the order of the size of the migration weight, and the timing task formulation can be performed by storing the migration weight value in advance, so that the convenience is improved, and the efficiency is improved. In a specific application of account number returning according to the returning weight, a flowchart of the specific application is shown in fig. 4, and fig. 4 is a schematic business flow provided in the embodiment of the present disclosure.

An example of a specific application is given below to make the solution of the embodiments of the present specification more apparent.

In an exemplary migration scheme, the following calculation method is adopted for determining the migration weight of the account in advance: the back transition weight Weight (account) =α×β×γ×100. Wherein the first weight factor α = the snapshot size of the account/the average snapshot size of the snapshot database, the average snapshot size of the current snapshot database being 50K; if the current account is configured with summary billing or buffered billing, then the second weight factor β=2; if the current account billing mode is real-time billing, the second weight factor β=1; if the current account is 21881 or 21883 head account, the third weight factor γ=0.6, and if the current account is 21882 head account, the third weight factor γ=0.4.

Two accounts exist, wherein the account A is 21883XXXXXXXXXXXX, and summary accounting is adopted, and the snapshot size of the account is 150K; the B account is 21882XXXXXXXXXXXXXX, and the snapshot size of the account is 500K by real-time billing. The method is characterized by comprising the following steps: for account a, α=3, β=2, γ=0.6, thus the back Weight (a) =3×2×0.6×100=360, and for account B, α=10, β=1, γ=0.4, thus the back Weight (B) =10×1×0.4×100=400. That is, the account B is reflected in the migration weight as a more active and more frequent transaction account, and the migration should be performed preferentially on the account B.

Based on the same idea, the invention further provides an account returning device, as shown in fig. 5, fig. 5 is a schematic structural diagram of the account returning device provided in the embodiment of the present specification, including:

the obtaining module 501 obtains relevant information of an account to be migrated, wherein the relevant information of the account to be migrated comprises at least one of the size, account billing mode and account number of historical transaction data of the account to be migrated;

a determining module 503, configured to determine a returning weight of each account to be returned according to the related information;

and the returning module 505 performs account returning according to the order of the returning weights.

Further, the determining module 503 determines an average size of the account history transaction data; for any account to be reverted, calculating the ratio of the size of historical transaction data of the account to be reverted to the average size of the historical transaction data of the account to be reverted, and generating a first weight factor; and calculating the returning weight of the account according to the first weight factor.

Further, the determining module 503 determines, for any account to be migrated, a second weight factor of the account according to the account billing mode thereof; calculating the returning weight of the account according to the second weight factor; wherein the billing mode includes real-time billing, buffered billing or aggregate billing.

Further, the determining module 503 obtains, for any account to be migrated, a specified field in the account; determining a third weight factor of the account according to the value of the designated field; calculating the returning weight of the account according to the third weight factor; wherein the specified field is used to distinguish account categories.

Further, the apparatus further comprises a storage module 507 for storing the back-migration weight locally.

Correspondingly, the embodiment of the application also provides account returning equipment, which comprises:

a memory storing an account returning program;

acquiring related information of an account to be reverted;

Based on the same inventive concept, the embodiments of the present application further provide a corresponding non-volatile computer storage medium, storing computer executable instructions, where the computer executable instructions are configured to:

acquiring related information of an account to be reverted;

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for the apparatus, device and medium embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and the relevant parts will be referred to in the description of the method embodiments, which is not repeated herein.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps or modules recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., a field programmable gate array (Field Programmable gate array, FPGA)) is an integrated circuit whose logic function is determined by the user programming the device. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell UniversityProgramming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmelAT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of the units may be implemented in the same one or more pieces of software and/or hardware when implementing the embodiments of the present specification.

It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. The computer-readable medium, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signal numbers and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

It will be apparent to one of ordinary skill in the art that one or more embodiments in the present description may be provided as a method, system, or computer program product. Accordingly, embodiments of the present specification may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, embodiments of the present description may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

Embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular transactions or implement particular abstract data types. Embodiments of the present description may also be practiced in distributed computing environments where transactions are performed by remote processing devices that are connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

Claims

1. An account migration method, comprising:

acquiring related information of an account to be reverted;

determining the returning weight of each account to be returned according to the related information; the migration weight is used for reflecting the importance degree of the migration of the account to be migrated;

and according to the size sequence of the returning weights, writing account data generated from the time point when the main database fails to the time point when the standby database is pulled up into the standby database after the standby database is pulled up.

2. The method of claim 1, the determining the return weight of each account to be returned according to the related information, comprising:

determining an average size of account historical transaction data;

calculating the ratio of the size of the historical transaction data of the account to be reverted to the average size of the historical transaction data of the account aiming at any account to be reverted to generate a first weight factor;

and calculating the returning weight of the account to be returned according to the first weight factor.

3. The method of claim 2, wherein the historical transaction data for the account to be reverted and the historical transaction data for the account are each stored in a snapshot database.

4. The method of claim 1, the determining the return weight of each account to be returned according to the related information, comprising:

determining a second weight factor of the account to be reverted according to the billing mode of the account to be reverted aiming at any account to be reverted;

and calculating the returning weight of the account to be returned according to the second weight factor.

5. The method of claim 4, the billing mode comprising real-time billing, buffered billing, or aggregate billing.

6. The method of claim 1, the determining the return weight of each account to be returned according to the related information, comprising:

aiming at any account to be reverted, acquiring a designated field in an account of the account to be reverted;

determining a third weight factor of the account to be reverted according to the value of the appointed field;

calculating the returning weight of the account to be returned according to the third weight factor;

wherein the specified field is used to distinguish account categories.

7. The method of claim 1, wherein the information regarding the account to be migrated comprises at least one of a size, a billing mode, and an account number of historical transaction data of the account to be migrated.

8. The method of claim 7, wherein the historical transaction data of the account to be reverted is sized to calculate a first weight factor, the billing mode of the account to be reverted is sized to calculate a second weight factor, and the account of the account to be reverted is sized to calculate a third weight factor.

9. The method of claim 8, wherein the back-off weight is a weight calculated based on a combination of weight factors of any combination of the first weight factor, the second weight factor, and the third weight factor.

10. The method of claim 1, the method being applied to a temporary master library;

after determining the returning weight of each account to be returned according to the related information, the method further comprises the following steps:

and storing the returning weight to the temporary main library.

11. The method of claim 10, wherein writing account data generated by the account to be migrated from a time point when the primary database fails to an end of a standby pull time point, to the standby after the pull, further comprises:

receiving the account data by using the temporary master library during a period from a time point when the master database fails to a time point when the backup library is pulled up;

writing account data generated during the period from the time point when the main database fails to the time point when the standby database is pulled up into the pulled standby database, wherein the method specifically comprises the following steps of:

and writing the account data into the standby library after being pulled up by the temporary main library.

12. An account migration apparatus comprising:

the acquisition module is used for acquiring the related information of the account to be reverted;

the determining module is used for determining the returning weight of each account to be returned according to the related information; the migration weight is used for reflecting the importance degree of the migration of the account to be migrated;

and the writing module is used for writing account data generated from the time point when the main database fails to the time point when the standby database is pulled up into the standby database after the standby database is pulled up according to the sequence of the returning weights.

13. The apparatus of claim 12, the determination module comprising:

a first determining unit configured to determine an average size of account history transaction data;

the first calculation unit is used for calculating the ratio of the size of the historical transaction data of any account to be reverted to the average size of the historical transaction data of the account to be reverted to generate a first weight factor;

and the second calculation unit is used for calculating the returning weight of the account to be returned according to the first weight factor.

14. The apparatus of claim 13, the historical transaction data for the account to be reverted and the historical transaction data for the account are each stored in a snapshot database.

15. The apparatus of claim 12, the determination module comprising:

the second determining unit is used for determining a second weight factor of any account to be restored according to the billing mode of the account to be restored;

and the third calculation unit is used for calculating the returning weight of the account to be returned according to the second weight factor.

16. The apparatus of claim 15, the billing mode comprising real-time billing, buffered billing, or aggregate billing.

17. The apparatus of claim 12, the determination module comprising:

the obtaining unit is used for obtaining the appointed field in the account number of the account to be restored aiming at any account to be restored;

a third determining unit, configured to determine a third weight factor of the account to be migrated according to the value of the specified field;

a fourth calculation unit, configured to calculate a return weight of the account to be returned according to the third weight factor;

wherein the specified field is used to distinguish account categories.

18. The apparatus of claim 12, the information regarding the account to be migrated comprising at least one of a size, a billing mode, and an account number of historical transaction data for the account to be migrated.

19. The apparatus of claim 18, the historical transaction data of the account to be reverted being sized to calculate a first weight factor, the billing mode of the account to be reverted being sized to calculate a second weight factor, the account of the account to be reverted being sized to calculate a third weight factor.

20. The apparatus of claim 19, the back-off weight is a weight calculated jointly based on weight factors of any combination of the first weight factor, the second weight factor, and the third weight factor.

21. The apparatus of claim 12, the apparatus being applied to a temporary master library, further comprising:

and the storage module is used for storing the returning weight to the temporary main library.

22. The apparatus of claim 22, further comprising:

the receiving module is used for receiving the account data by utilizing the temporary main database in the period from the time point when the main database fails to the time point when the standby database is pulled up;

the writing module specifically comprises:

and the writing unit is used for writing the account data into the standby library after being pulled up by the temporary main library.

23. An account migration apparatus comprising:

a memory storing an account returning program;

acquiring related information of an account to be reverted;