CN108345516B - Account back-moving method, device and equipment - Google Patents

Abstract

The embodiment of this specification discloses an account retrieval method, device and equipment. Reflect the frequency of bookkeeping and business importance of accounts by integrating historical transaction data of user accounts, account bookkeeping modes, account types, etc. move back.

Description

A method, device and equipment for retrieving an account

technical field

This specification relates to the field of computer technology, and in particular to an account retrieval method, device and equipment.

Background technique

The database unexpectedly experiences a network failure or is unexpectedly terminated abnormally, resulting in the unavailability of all services, which is called database Failover, or FO for short (usually occurs on the main database). The process of restoring the database, components or services that were previously in a fault state to the original working state, and restoring the standby system from the recovery state to the standby state is called database failback, or FB for short.

In the FB process, after the disaster of the main database, it generally takes a certain amount of time to pull up the standby database. During this period, in order to ensure the normal operation of the business, the account data will be written into the FO (Failover) database (also called the temporary master database). library). Therefore, after the standby database is pulled up, the account data in the FO database needs to be written into the main database (standby database), which is called account transfer. During the process of account relocation, due to business needs, it is necessary to ensure that hot accounts (accounts with frequent transactions or high importance) are relocated first.

Based on this, a more effective method for account retrieval is needed.

Contents of the invention

The embodiment of this specification provides an account retrieval method, device and equipment, which are used to solve the following problem: to provide a more effective account retrieval method.

Based on this, the embodiment of this specification provides an account retrieval method, including:

Obtain relevant information about the account to be returned;

Determine the relocation weight of each account to be relocated according to the relevant information;

Perform account retrieval according to the order of retrieval weights;

Wherein, the relevant information of the account to be retrieved includes at least one of the size of historical transaction data of the account to be retrieved, account accounting mode and account number.

At the same time, the embodiment of this specification also provides an account retrieval device, including:

An acquisition module that acquires information about the account to be relocated, wherein the information about the account to be relocated includes at least one of the size of the historical transaction data of the account to be relocated, the account accounting mode, and the account number;

A determining module, which determines the relocation weight of each account to be relocated according to the relevant information;

The fetching module performs account fetching according to the order of the fetching weights.

Correspondingly, the embodiment of this specification also provides an account retrieval device, including:

The memory stores the account retrieval program;

The processor calls the account retrieval program in the memory, and executes:

Obtain relevant information about the account to be returned;

Determine the relocation weight of each account to be relocated according to the relevant information;

Perform account retrieval according to the order of retrieval weights;

Wherein, the relevant information of the account to be retrieved includes at least one of the size of historical transaction data of the account to be retrieved, account accounting mode and account number.

Correspondingly, the embodiments of this specification also provide a non-volatile computer storage medium storing computer-executable instructions, and the computer-executable instructions are set to:

Obtain relevant information about the account to be returned;

Determine the relocation weight of each account to be relocated according to the relevant information;

Perform account retrieval according to the order of retrieval weights;

Wherein, the relevant information of the account to be retrieved includes at least one of the size of historical transaction data of the account to be retrieved, account accounting mode and account number.

The above at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

Reflect the frequency of bookkeeping and business importance of accounts by integrating historical transaction data of user accounts, account bookkeeping modes, account types, etc. Move back, reduce the retention time of hot accounts with frequent transactions in the FB stage, minimize the number of affected transactions, and improve user experience.

Description of drawings

Figure 1 is a schematic diagram of the account snapshot data provided by the embodiment of this specification;

FIG. 2 is a schematic diagram of the system architecture involved in the embodiment of this specification;

Fig. 3 is a schematic flow chart of the account retrieval method provided by the embodiment of this specification;

FIG. 4 is a schematic diagram of a business process provided by an embodiment of this specification;

Fig. 5 is a schematic structural diagram of an account retrieval device provided by an embodiment of this specification.

Detailed ways

In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in conjunction with specific embodiments of the present application and corresponding drawings. Apparently, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the protection scope of the present application.

Generally speaking, the database that provides database services to applications for a long time is called the main database. At the same time, there will also be a database (standby database) for backup. The standby database is used as the backup of the main database, and the data consistency is ensured through the synchronization of the master and the backup. OK, after the disaster of the main library, assume the responsibility of the main library and become the new main library. At the same time, in some fields (such as the payment field and the financial field), there is also a snapshot database when a higher level of security is required. The snapshot database is different from the standby database. It is mainly used for snapshot backup of the data of the account in the main database when the main database is running normally (for example, to record account balance, daily changes, details of account fund changes, etc.), as shown in Figure 1 As shown, FIG. 1 is a schematic diagram of account snapshot data provided by the embodiment of this specification. In other words, the snapshot database is not a full backup, but it briefly reflects the historical transactions of the account. Obviously, if the hardware can support it, the historical transaction data in the snapshot database can take snapshots of more records, and can more fully reflect the historical situation of an account. In other words, snapshot data is a type of historical transaction data, and historical transaction data can also be other more detailed transaction data.

When the main library is in disaster, due to reasons such as data synchronization, it takes a certain amount of time to pull up the standby library as the new main library. In order to reduce business losses, the FO library assumes the role of the temporary main library during the standby library startup period, receives normal business requests, and performs Business processing, for example, supports main businesses such as account opening and bookkeeping in the FO scenario, and ensures high availability of the main business when the main database is down.

After the new main database is established (usually the standby database is activated successfully), it is necessary to move back the data such as accounts, accounting vouchers, and xts transactions that have done business in the FO database to the new main database. In this case, due to business needs (for example, for both accounts requested by the same note account, one account is migrated back to the new main database, and the other is still in the FO database before the migration is completed. Since the two accounts are routed to two different databases, the request is intercepted by the transaction, resulting in account failure, so the user requests a refund), in order to reduce the account failure at this stage as much as possible and reduce the number of transactions that are automatically refunded, it is necessary to analyze the importance of the account transfer to ensure that the account with high importance is quickly move back.

Based on the foregoing, the embodiment of this specification provides an account retrieval method, which reflects the accounting frequency and business importance of the account by integrating various factors of the user account, and obtains the retrieval weight of the account comprehensively, so that according to the retrieval weight high and low order fetch,

In the embodiment of this specification, the account retrieval method can adopt the architecture shown in Figure 2, which is a schematic diagram of the system architecture involved in the embodiment of this specification, and the following will be based on the architecture shown in Figure 2, and the details Describe the account reset process provided by the embodiment of this manual. The process specifically includes the following steps, as shown in Figure 3. Figure 3 is a schematic flow chart of the account reset method provided by the embodiment of this manual, including:

S301. Obtain relevant information about the account to be transferred back.

The relevant information of the account to be retrieved includes at least one of the size of historical transaction data of the account to be retrieved, account accounting mode and account number.

Specifically, in the described architecture, the account history transaction data is stored in the snapshot database, and the FO library acts as a temporary master library, and any account history transaction snapshot data can be obtained from the snapshot database. Generally speaking, the account accounting mode can be configured according to the user's requirements, and can be obtained from the FO database. The account number is mainly used to distinguish the category of the account, including public accounts, private accounts, and internal accounts, etc., so that according to the category Determine the importance of the account.

S303. Determine the retrieval weight of each account to be retrieved according to the related information.

Based on the above, in this process, the calculation of the reversion weight can be performed based on a certain information, for example, based on the size of the historical transaction snapshot data of the account, the weight is directly assigned, and the larger the historical transaction snapshot data, the higher the weight; Alternatively, multiple pieces of information may be integrated to calculate the retrieval weight. For example, based on the accounting mode of the account and the size of the historical transaction snapshot data of the account, the weight of the account is jointly determined for account reversion.

S305. Perform account retrieval according to the order of retrieval weights.

Generally speaking, active accounts and important accounts will have higher weights, and account retrieval will be performed in order of weight.

Through comprehensive user account historical transaction data, account bookkeeping mode, account type and other factors to reflect the bookkeeping frequency and business importance of the account, the importance of account relocation is obtained comprehensively, and then the order of the importance is determined. Move back, reduce the retention time of hot accounts with frequent transactions in the FB stage, minimize the number of affected transactions, and improve user experience.

As a specific implementation, for the step S303, the relocation weight of each account to be relocated is determined according to the relevant information, and the following method can be used when calculating the weight based on the historical transaction data of the account to be relocated:

Determine the average size of account historical transaction data; for any account to be relocated, calculate the ratio of the size of the account’s historical transaction data to be relocated to the average size of the account’s historical transaction data, and generate a first weighting factor; according to the first The weight factor calculates the fetch weight of the account.

Specifically, the average size of account historical transaction data may be the average size of snapshot data of all accounts in the snapshot database, or the average size of snapshot data of all accounts to be retrieved. That is, the first weighting factor α is set to represent the importance of the historical transaction data of the account, where: α=snapshot size of the account/average snapshot size of the snapshot database, or α=snapshot size of the account/average snapshot of the account to be retrieved size. Generally speaking, it is more convenient to use the former calculation method, and the account reversion may be carried out in batches, and the latter calculation method is more targeted.

As a specific implementation, for the step S303, the relocation weight of each account to be relocated is determined according to the relevant information, and the following method can be used when calculating the weight according to the account bookkeeping mode:

For any account to be returned, determine the second weight factor of the account according to its account bookkeeping mode; wherein, the bookkeeping mode includes real-time bookkeeping, buffer bookkeeping or summary bookkeeping; calculate according to the second weight factor Feedback weight for this account.

Specifically, in payment applications, general bookkeeping accounts support three bookkeeping modes: real-time bookkeeping, summary bookkeeping, or buffer bookkeeping. The accounting mode can be set in advance according to the actual needs of the account.

Real-time bookkeeping, as the name suggests, means that the balance of the account changes in real time after the bookkeeping is completed. Summary bookkeeping is the opposite of real-time bookkeeping, that is, after the account bookkeeping is completed, only the summary bookkeeping details are recorded, and the account balance is not modified. When the day is cut, the overall change is summarized and reflected in the balance at one time. Buffer bookkeeping is a compromise result of real-time bookkeeping and summary bookkeeping. The account for buffer bookkeeping is configured. When bookkeeping is completed, only the details of buffer bookkeeping are recorded. When the buffer bookkeeping resumes the scheduled task, the specified quantity details are calculated. After this change, it will be reflected in the balance once. At this time, the change frequency of the account balance depends on the frequency of the scheduled task.

In other words, the accounts that need to be set up for aggregate bookkeeping or buffer bookkeeping are usually Yihotspot accounts, which have a large amount of transactions and are more important. Therefore, a higher weight factor should be given to the accounts of summary bookkeeping or buffer bookkeeping.

For example, setting the second weight factor β to represent the importance of the account accounting mode, wherein: if the current account is configured with summary accounting or buffer accounting, then β=0.6; if the current account accounting mode is real-time accounting, then β = 0.4.

As a specific implementation manner, for the step S303, the relocation weight of each account to be relocated is determined according to the relevant information, and the following method can be used when calculating the weight according to the user account:

For any account to be retrieved, obtain a specified field in the account; determine a third weight factor of the account according to the value of the specified field; calculate the retrieve weight of the account according to the third weight factor.

As mentioned above, the accounts of customer accounts are mainly classified into public accounts, private accounts and some internal accounts. Public accounts include company and merchant accounts, and private accounts are users' balance accounts (including buyers and sellers); For the above-mentioned different types of accounts, it is usually distinguished by specifying the field of the account code.

For example, the code 21881XXXXXXXXXXXXXX is a merchant account, 21882XXXXXXXXXXXXXX is a personal balance account, and 21883XXXXXXXXXXXXXX is an internal account. Different account types are determined by the first 5 digits at the beginning.

Generally speaking, the business volume of transfers, loans, and refunds of merchant accounts is greater than that of personal balance accounts; a small number of internal accounts are usually transitional accounts, guarantee accounts, etc., and the amount of bookkeeping is also much larger than that of personal balance accounts. Based on this, a higher weight factor can be given to internal accounts or merchant accounts in advance.

For example, the third weight factor γ is set to represent the importance of the account category, where: if the current account is an account starting with 21881 or 21883, then γ=0.6; if the current account is an account starting with 21882, then γ=0.4.

The above-mentioned second weight factor β and third weight factor γ can be set artificially based on experience, and can also be dynamically adjusted according to the retrieval business results in practical applications.

As mentioned above, the retrieval weight of the account to be retrieved can be based on a certain weight factor, or based on the joint calculation of several weight factors. For example, the retrieval weight of the current account is set as: retrieval 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 above calculation of the retrieval weight may be performed in real time. As a specific implementation manner, the aforementioned method further includes: storing the retrieval weight locally. The local here refers to the FO database that acts as the temporary master database. For example, assign this value to the FO record table (ip_failover_record). When it is necessary to perform account reversion, it can be performed in the order of the reversion weight. Pre-stored reversion weight values can be It is more convenient and efficient to make scheduled tasks. In the specific application of account fetching based on the fetching weight, its flow chart is shown in FIG. 4 , which is a schematic diagram of the business process provided by the embodiment of this specification.

An example of a specific application is given below to make the solution of the embodiment of this specification more clear.

In an exemplary fetching scheme, the fetching weight of an account determined in advance is calculated as follows: fetching weight Weight(account)=α*β*γ*100. Among them, the first weight factor α=the snapshot size of the account/the average snapshot size of the snapshot database, and the average snapshot size of the current snapshot database is 50K; if the current account is configured with summary accounting or buffer accounting, the second weighting factor β =2; if the current account bookkeeping mode is real-time bookkeeping, then the second weight factor β=1; if the current account is an account starting with 21881 or 21883, then the third weight factor γ=0.6, if the current account is an account starting with 21882, Then the third weighting factor γ=0.4.

There are two accounts, account A is 21883XXXXXXXXXXXXXX, which adopts aggregate bookkeeping, and the snapshot size of this account is 150K; account B is 21882XXXXXXXXXXXXXX, which uses real-time bookkeeping, and the snapshot size of this account is 500K. Through the above retrieving scheme, it can be obtained: for account A, its α=3, β=2, γ=0.6, so the retrieving weight Weight(A)=3*2*0.6*100=360, for account B, Its α=10, β=1, γ=0.4, so the recall weight Weight(B)=10*1*0.4*100=400. That is to say, it is reflected from the reversion weight that account B is a more active account with more frequent transactions, and account B should be relocated first.

Based on the same idea, the present invention also provides an account retrieval device, as shown in Figure 5, which is a schematic structural diagram of the account retrieval device provided by the embodiment of this specification, including:

Obtaining module 501, acquiring relevant information of the account to be relocated, wherein the relevant information of the account to be relocated includes at least one of the size of historical transaction data of the account to be relocated, account accounting mode, and account number;

Determining module 503, determining the relocation weight of each account to be relocated according to the relevant information;

The fetching module 505 performs account fetching according to the order of the fetching weights.

Further, the determination module 503 determines the average size of account historical transaction data; for any account to be relocated, calculate the ratio of the size of the account’s historical transaction data to be relocated to the average size of the account’s historical transaction data, and generate the first A weight factor; calculate the recall weight of the account according to the first weight factor.

Further, the determination module 503, for any account to be returned, determines the second weight factor of the account according to its account bookkeeping mode; calculates the return weight of the account according to the second weight factor; wherein, the bookkeeping Accounting modes include real-time accounting, buffer accounting or summary accounting.

Further, the determination module 503, for any account to be relocated, obtains the specified field in the account; according to the value of the specified field, determines the third weight factor of the account; calculates the third weight factor according to the third weight factor. Feedback weight of an account; wherein, the specified field is used to distinguish account categories.

Further, the device further includes a storage module 507, which stores the retrieved weight locally.

Correspondingly, the embodiment of the present application also provides an account retrieval device, the device includes:

The memory stores the account retrieval program;

The processor calls the account retrieval program in the memory, and executes:

Obtain relevant information about the account to be returned;

Determine the relocation weight of each account to be relocated according to the relevant information;

Perform account retrieval according to the order of retrieval weights;

Wherein, the relevant information of the account to be retrieved includes at least one of the size of historical transaction data of the account to be retrieved, account accounting mode and account number.

Based on the same inventive idea, the embodiment of the present application also provides a corresponding non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions are set to:

Obtain relevant information about the account to be returned;

Determine the relocation weight of each account to be relocated according to the relevant information;

Perform account retrieval according to the order of retrieval weights;

Wherein, the relevant information of the account to be retrieved includes at least one of the size of historical transaction data of the account to be retrieved, account accounting mode and account number.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the apparatus, equipment and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple. For the relevant parts, please refer to the description of the method embodiments, and details will not be repeated here.

The foregoing describes specific embodiments of this specification. Other implementations 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 an order different from that 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. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

In the 1990s, the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow). However, with the development of technology, the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (Programmable Logic Device, PLD) (such as a Field Programmable Gate Array (Field Programmable Gate Array, FPGA)) is such an integrated circuit, and its logic function is determined by programming the device by a user. It is programmed by the designer to "integrate" a digital system on a PLD, instead of asking a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when writing programs, but before compiling The original code of the computer must also be written in a specific programming language, which is called a hardware description language (Hardware Description Language, HDL), and there is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., currently the most commonly used is VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logical programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain a hardware circuit for realizing the logic method flow.

The controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers, and embedded microcontrollers, examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that, in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, 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 Combinations of any of these devices.

For the convenience of description, when describing the above devices, functions are divided into various units and described separately. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more pieces of software and/or hardware.

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention can 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, etc.) 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 should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

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

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media 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 Disc (DVD) or other optical storage, Magnetic tape cartridge, tape magnetic disk storage or other magnetic storage device or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include transitory media, such as modulated data signal numbers and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

Those skilled in the art should understand that one or more of the embodiments in this specification may be provided as a method, system or computer program product. Accordingly, the embodiments of the present specification may take the form of an entirely hardware embodiment, an entirely software embodiment or a combination of software and hardware aspects. Furthermore, embodiments of the present specification 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, etc.) having computer-usable program code embodied therein. .

Embodiments of the specification 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 specification may also be practiced in distributed computing environments where transactions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Claims (11)

1. An account migration method comprising:

acquiring relevant information of an account to be migrated back before a main database is in network failure or is abnormally terminated accidentally and a standby database is started;

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

according to the size sequence of the migration weight, carrying out account migration, wherein the account migration refers to writing account data generated from a network fault or unexpected abnormal termination time point of a main database to a standby database pull-up time point into the main database;

the related information of the account to be moved back comprises at least one of the size of historical transaction data of the account to be moved back, an account billing mode and an account number;

and the historical transaction data of the account to be migrated back is stored in a snapshot database.

2. The method according to claim 1, wherein determining a migration weight of each account to be migrated back according to the related information comprises:

determining an average size of historical transaction data of the account;

for any account to be returned, calculating the ratio of the historical transaction data of the account to be returned to the average size of the historical transaction data of the account to be returned to generate a first weight factor;

and calculating the back migration weight of the account according to the first weight factor.

3. The method of claim 1, wherein determining a migration weight for each account to be migrated according to the relevant information comprises:

for any account to be migrated, determining a second weight factor of the account according to the account billing mode of the account;

calculating the back-migration weight of the account according to the second weight factor;

wherein the accounting mode comprises real-time accounting, buffer accounting or summary accounting.

4. The method of claim 1, wherein determining a migration weight for each account to be migrated according to the relevant information comprises:

aiming at any account to be migrated, acquiring a specified field in the account number of the account to be migrated;

determining a third weight factor of the account according to the value of the designated field;

calculating the back migration weight of the account according to the third weight factor;

wherein the designated field is used to distinguish between account categories.

5. The method according to claim 1, after determining the migration weight of each account to be migrated according to the related information, further comprising:

and storing the backtracking weight to the local.

6. An account migration apparatus comprising:

the system comprises an acquisition module, a storage module and a management module, wherein the acquisition module is used for acquiring the relevant information of an account to be returned when a network fault or unexpected abnormal termination occurs in a main database and before a standby database is started, wherein the relevant information of the account to be returned comprises at least one of the size of historical transaction data of the account to be returned, an account billing mode and an account number;

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

the migration module carries out account migration according to the sequence of the migration weights; the account migration refers to writing account data generated from a network fault or unexpected abnormal termination time point of a main database to a standby database pull-up time point into the main database;

and the historical transaction data of the account to be migrated back is stored in a snapshot database.

7. The apparatus of claim 6, the determination module to determine an average size of the account historical transaction data; for any account to be returned, calculating the ratio of the historical transaction data of the account to be returned to the average size of the historical transaction data of the account to be returned to generate a first weight factor; and calculating the back migration weight of the account according to the first weight factor.

8. The apparatus of claim 6, the determining module determines, for any account to be migrated, the second weighting factor for the account according to its account billing mode; calculating the back migration weight of the account according to the second weight factor; wherein the accounting mode comprises real-time accounting, buffer accounting or summary accounting.

9. The apparatus of claim 6, the determining module obtains a designated field in an account number of any account to be migrated; determining a third weight factor of the account according to the value of the designated field; calculating the back-migration weight of the account according to the third weight factor; wherein the designated field is used to distinguish between account categories.

10. The apparatus of claim 6, further comprising a storage module that stores the backover weight locally.

11. An account migration apparatus comprising:

a memory storing an account migration program;

the processor calls the account back-migration program in the memory and executes:

acquiring relevant information of an account to be migrated back before a main database is in network failure or is abnormally terminated accidentally and a standby database is started;

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

according to the sequence of the migration weight, account migration is carried out; the account migration refers to writing account data generated from a network fault or unexpected abnormal termination time point of a main database to a standby database pull-up time point into the main database;

the information related to the account to be migrated back comprises at least one of the size of the historical transaction data of the account to be migrated back, an account billing mode and an account number; and the historical transaction data of the account to be migrated back is stored in a snapshot database.

Images