CN107239370B - Data writing method, transaction processing method and device - Google Patents
Data writing method, transaction processing method and device Download PDFInfo
- Publication number
- CN107239370B CN107239370B CN201610189000.XA CN201610189000A CN107239370B CN 107239370 B CN107239370 B CN 107239370B CN 201610189000 A CN201610189000 A CN 201610189000A CN 107239370 B CN107239370 B CN 107239370B
- Authority
- CN
- China
- Prior art keywords
- server
- database
- data
- message
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
- G06F11/2069—Management of state, configuration or failover
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
Abstract
The embodiment of the application discloses a data writing method, a transaction processing method and a device, and aims to solve the problem that the prior art cannot complete internet transactions when a service system is in a failure transfer state. The data writing method comprises the following steps: the method comprises the steps that a first server receives a confirmation instruction which is sent by a terminal and used for writing certificate data into a database; the first server checks whether the service system is in a failover state; when the service system is not in a failure transfer state, the first server writes the certificate data into a first database; the first database is inquired by the first server when the service system is not in the failure transfer state; when the service system is not in a failure transfer state, the first server sends a message carrying the certificate data to the second server; the second server is used for writing the certificate data into a second database after receiving the message, and the second database is inquired by the first server when the service system is in the failure transfer state.
Description
Technical Field
The present application relates to the field of database technologies, and in particular, to a data writing method, a transaction processing method, and an apparatus.
Background
In the failover (failover), when a service system includes a main database and a failover database, if a service is normal (non-failover), the service system uses the main database to store service data, and if the service is abnormal (failover), the service system switches to the failover database to store the service data, and when the main database is restored, the service data stored in the failover database is migrated back to the main database.
Currently, various internet transactions corresponding to accounts logged on a terminal can be completed through a computer network. In some specific application scenarios, before completing the internet transaction, the computer needs to query the database for whether credential data corresponding to the current account exists. The credential data is used as a credential for the account to perform the internet transaction, and may be generally written into the database during account opening. In the prior art, the credential data may be written into the master database during account opening, so that when the service is normal, the service system may query the master database to perform the internet transaction.
In the prior art, only the master database stores the credential data corresponding to each account, and when the service system fails to transfer, although the service system may switch to the failover database to store the service data, the service system cannot query the credential data from the master database during the failure transfer (when the credential data cannot be queried, the service system may generally report an exception), so that the service system cannot complete the internet transaction corresponding to the account during the failure transfer.
Disclosure of Invention
An embodiment of the present invention provides a data writing method, a transaction processing method, and a device, so as to solve the problems in the prior art.
In order to solve the above problems, embodiments of the present application provide a data writing method, a transaction processing method, and an apparatus, which are implemented by the following technical solutions:
a data writing method, comprising:
the method comprises the steps that a first server receives a confirmation instruction which is sent by a terminal and used for writing certificate data into a database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
the first server checks whether the service system is in a failover state;
when the service system is not in a failure transfer state, the first server writes the certificate data into a first database; wherein the first database is queried by the first server when the service system is not in a failover state;
when the service system is not in a failure transfer state, the first server sends a message carrying the certificate data to the second server; the second server is used for writing the credential data into a second database after receiving the message, and the second database is inquired by the first server when the service system is in a failure transfer state.
A data writing method, comprising:
the method comprises the steps that a first server receives a confirmation instruction which is sent by a terminal and used for writing certificate data into a database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
the first server checks whether the service system is in a failover state;
when the service system is not in a failure transfer state, the first server writes the certificate data into a first database; wherein the first database is queried by the first server when the service system is not in a failover state;
when the service system is not in a failure transfer state, the first server writes the certificate data into a second database; wherein the second database is queried by the first server when the service system is in a failover state.
A transaction processing method, comprising:
a first server receives a transaction request which is sent by a terminal and corresponds to an account logged in the terminal;
the first server checks whether the service system is in a failover state;
when the service system is in a failure transfer state, the first server inquires whether credential data corresponding to the account is stored in a second database; the second database is inquired by the first server when the service system is in a failure transfer state, and the second database is written into the certificate data when the service system is not in the failure transfer state, wherein the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
if the certificate data are inquired in the second database, the first server writes the service data corresponding to the transaction request into a failover database; the failover database is used by the first server when the service system is in the failover state.
A data writing apparatus comprising:
the instruction receiving unit is used for receiving a confirmation instruction which is sent by the terminal and used for writing the certificate data into the database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
the checking unit is used for checking whether the service system is in a failure transfer state;
the data writing unit is used for writing the certificate data into a first database when the service system is not in a failure transfer state; wherein the first database is queried when the business system is not in a failover state;
the message sending unit is used for sending a message carrying the certificate data to a second server when the service system is not in the failure transfer state; the second server is used for writing the certificate data into a second database after receiving the message, and the second database is inquired when the service system is in a failure transfer state.
A data writing apparatus comprising:
the instruction receiving unit is used for receiving a confirmation instruction which is sent by the terminal and used for writing the certificate data into the database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
the checking unit is used for checking whether the service system is in a failure transfer state;
the first writing unit is used for writing the certificate data into a first database when the service system is not in a failure transfer state; wherein the first database is queried when the business system is not in a failover state;
the second writing unit is used for writing the certificate data into a second database when the service system is not in a failure transfer state; wherein the second database is queried when the business system is in a failover state.
A transaction processing device, comprising:
the request receiving unit is used for receiving a transaction request which is sent by a terminal and corresponds to an account logged in the terminal;
the checking unit is used for checking whether the service system is in a failure transfer state;
the query unit is used for querying whether the second database stores the certificate data corresponding to the account or not when the service system is in the failover state; the second database is inquired when the business system is in a failure transfer state, and the second database is written into the certificate data when the business system is not in the failure transfer state, wherein the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
a service data writing unit, configured to write service data corresponding to the transaction request into a failover database when the credential data is queried in the second database; wherein the failover database is used when the business system is in a failover state.
According to the technical scheme provided by the embodiment of the application, when the business system is not in the failure transfer state, the certificate data (the certificate of the account for the preset internet transaction) is written into the first database through the first server, and meanwhile, the certificate data is written into the second database. Wherein the first database is queried when the business system is not in a fail-over state and the second database is queried when the business system is in a fail-over state. Compared with the prior art, in the embodiment of the application, whether the service system is not in the failover state or the service system is in the failover state, whether credential data corresponding to the account exists in the first database or the second database or not can be inquired, so that internet transactions corresponding to the accounts are completed. The embodiment of the application solves the problem that the prior art cannot complete the internet transaction when the service system is in the failure transfer state.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative effort.
FIG. 1 is a schematic diagram of an exemplary system architecture provided by an embodiment of the present application;
fig. 2 is a flowchart of a data writing method according to an embodiment of the present application;
FIG. 3 is a flowchart illustrating a data writing method mainly performed by a first server according to an embodiment of the present disclosure;
FIG. 4 is a flowchart of a transaction processing method according to an embodiment of the present application;
fig. 5 is a block diagram of a data writing apparatus according to an embodiment of the present application;
FIG. 6 is a block diagram of a data writing apparatus according to another embodiment of the present application;
fig. 7 is a block diagram of a transaction processing apparatus according to an embodiment of the present application.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Fig. 1 is a schematic structural diagram of a business system including a master database and a faiover database according to an embodiment of the present application. In the embodiment of the present application, the system architecture may include a first server 100, a second server 200, a first database 10, a failover database 20, a second database 30, a terminal 300, and a message delivery component 400. The first server communicates with the terminal 300 to perform internet transactions (e.g., transferring funds in or out of an account) corresponding to an account logged in the terminal, and the terminal may have a client application corresponding to the first server 100 installed thereon. In a failover (failover) mode, when the first database 10 (referred to as a primary database) is available, the failover database 20 is not used by the service system, but is used as a backup database. Herein, when the first database 10 cannot be used due to some factor (for example, a database failure, etc.), the state of the service system is referred to as a failover (failover) state, and when the service system is in the failover state, the service system may switch to the failover database 20 for use, so as to ensure that the service system can keep normal operation. Among them, failover (failover) is a technique well known to those skilled in the art, and a detailed description thereof will be omitted.
In the process of implementing the internet transaction, generally, the first server 100 needs to query whether credential data corresponding to an account logged in the terminal 300 exists in a database, and the credential data may be used as a credential for the account to perform the internet transaction. If the voucher data corresponding to the account exists in the query database, the current internet transaction is legal or safe, and then the related operation of the internet transaction is executed (for example, a certain amount of money is transferred into a designated account); otherwise, if the voucher data do not exist in the query database, the current internet transaction is not legal or safe, so that the operation is refused to be executed, and an exception can be reported to the terminal or the current account is prompted to have no corresponding voucher data. In general, the credential data corresponding to the account may be written into the database by the first server 100 by the user sending a confirmation command (which may be a command for confirming writing of the credential data into the database) to the first server 100 through the terminal 300 during the account opening process.
In the prior art, the credential information corresponding to the account is written into the first database 10. Thus, when the business system is not in the failover state, the first server 100 may determine whether the internet transaction corresponding to the account is legal or safe by querying whether the first database 10 has the credential information corresponding to the account. However, when the service system is in the fail-over state, the first database 10 cannot be used by the service system, that is, the service system cannot query the credential information corresponding to the account from the first database 10, so that the service system refuses to execute the internet transaction corresponding to the account (because the credential information cannot be found, and actually, the credential information corresponding to the account already exists in the first database 10, that is, the current internet transaction is legal or secure).
The reason why the credential information is not written into the failover database 20 mainly includes:
when the service system is in a failover state (the first database 10 is not available), the failover database 20 is used by the service system, so that the service system can store service data corresponding to an internet transaction occurring in the failover state in the failover database 20. When the first database 10 recovers the available state, the first server 100 may generally migrate the service data stored in the failover database 20 back to the first database 10 to ensure the integrity of the service data in the first database 10 (the master library). In view of this situation, if the credential information is backed up in the above failover database, when the first database 10 is restored to be usable, it is necessary to migrate the transaction data and the credential information stored in the failover database 20 back to the first database 10.
In view of the above problems in the prior art, the embodiments of the present application provide a data writing method, which writes credential data into the first database 10 and the second database 30 simultaneously, so that when a business system is in a failover state (the first database is not available), it can be ensured that an internet transaction can be performed normally by querying whether credential data corresponding to an account exists in the second database.
It should be noted that the first server 100 and the second server 200 may be a server cluster including a plurality of servers, and the above mentioned databases may also be any form of database, and the present application is not limited thereto. The terminal 300 may be a mobile phone or a computer. The server and the terminal, the server and the database, and the server may communicate with each other through any type of network. In addition, fig. 1 illustrates only an exemplary system architecture of the present application, and the system architecture may be changed in a specific implementation process. For example, messages are not passed between the first server 100 and the second server 200 through the message delivery component; alternatively, the second server 200 is omitted, and the first server 100 performs the operation of writing the credential data into the second database 30.
Fig. 2 is a flowchart of a data writing method according to an embodiment of the present application, including:
s101: the terminal sends a confirmation instruction to write the credential data into the database.
The certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal. In some application scenarios, the account needs to sign a contract with a financial institution (such as a third-party payment platform, a fund platform, or the like) during the account opening process, the signing process generates signing data, and the signing data is written into a database, so in this scenario, the signing data is the credential data. Of course, the credential data is not limited to the subscription data, and in other scenarios, the credential data may be any data that can be used as a credential for an internet transaction. For example, different permissions are set for different accounts, and when a preset internet transaction is performed, a database needs to be queried to obtain permission data corresponding to the account, so as to determine whether the current account has the permission to perform the preset internet transaction.
Generally, when a terminal requests to perform an internet transaction (e.g., fund transfer-in or transfer-out), if the credential data corresponding to the current account exists in the first server query database, which indicates that the internet transaction corresponding to the current account is legal or secure, the internet transaction may be further performed. Otherwise, if the voucher data is not inquired in the database, the current internet transaction is not legal or safe, and the internet transaction is refused to be executed. In addition, after the credential data is not queried, the first server may push a message to the terminal to prompt the user that the credential data is not queried, and notify the user to trigger an action of writing the credential data of the account into the database, and the user may confirm that the credential data is written into the database by sending the confirmation instruction to the server through the terminal.
S102: the first server receives the confirmation instruction.
Taking a fund transaction scenario as an example, after receiving the confirmation instruction, the first server indicates that the user agrees to the relevant terms in the contract to be signed with a certain financial institution, confirms the contract with the financial institution, and generates the contract data.
S103: and when the business system is not in the fail-over state, the first server writes the credential data in the initial state into the first database.
As described above, the first database is the (primary database of the business system) used by the business system in non-failover. Therefore, when an account is opened, the credential data corresponding to the account needs to be written into the first database, so that when an internet transaction corresponding to an account is performed, whether the current internet transaction is legal or safe can be determined by inquiring whether the credential data corresponding to the account exists in the first database.
In an embodiment of the present application, the credential data may include an initial status and a success status. According to a general flow, a contract signing (i.e., contract signing) process between a user and a financial institution is a two-party contract signing process, and requires an action of performing contract confirmation on the user side and the financial institution side, respectively, wherein a confirmation instruction sent by the user to a first server through a terminal is a contract confirmation on behalf of the user side, and at this time, although the credential data is already created on the database side, the state of the contract data is an initial state because only one party of the user side confirms the contract. After creating the credential data in the initial state, the financial institution may validate the signing process to validate the signing data validated by the user, and after validating by the financial institution, the first server may receive a validation command from the financial institution, at which time, the state of the credential data may be changed from the initial state to a successful state. It should be noted that the present application does not limit the signing targets (such as the user and the financial institution) of the signing data, for example, the signing may be performed between the user and the financial institution, or between the financial institution and the financial institution, and the number of signing targets may be larger than two.
S104: when the service system is not in the failure transfer state, the first server sends a message carrying credential data in an initial state to the second server; the second database is queried when the business system is in a failover state.
In the embodiment of the application, the first server is a core of the service system, and needs to perform transactions such as query of credential data, storage and change of service data of internet transactions, and control of failover, and the load of the first server is large, so that the credential data is written into the second database through the second server in order to reduce the load of the first server. The first server may trigger an action of writing the credential data into the second database by sending a message carrying the credential data in the initial state to the second server. It should be noted that, taking a subscription scenario as an example, the message may carry one or more parameters of subscription data, where the parameters may be, for example: a contract agreement number, an account ID, an institution number (e.g., financial institution), a status (e.g., initial status, successful status), a fund transaction number, a product code, etc. Wherein the state may be represented by "0" or "1".
In order to ensure that the credential data can be written into the second database while being written into the first database, so as to ensure consistency of the credential data in the first database and the second database, in this embodiment of the application, the message may be a transaction-type message. The transactional message is: when the delivery side sends out a message, the receipt message of the monitoring side needs to be acquired, and if the receipt message which indicates that the data writing is successful is received, the transaction type message is stopped from being sent to the monitoring side; if receiving the receipt message indicating that the data writing fails, the transaction message needs to be sent to the monitoring party again until receiving the receipt message indicating that the data writing succeeds. The delivery party may be a first server, and the monitoring party may be a second server. In this embodiment of the application, if the first server receives a receipt message indicating that data writing fails, which is returned by the second server, in order to ensure that credential data written in the first database is consistent with credential data carried in a message sent to the second server, the first server may perform rollback on an operation before the receipt message is received. It can be seen that if a transaction type message is sent to the second server, it can be ensured that the message sent by the first server (the delivery side) is successfully received by the second server (the subscriber side), and the second server successfully writes the credential data into the second database.
Referring to fig. 1, in the embodiment of the present application, it may be ensured by the message delivery component 400 that the transactional message sent by the first server 100 can be listened to by the second server 200, and the second server 200 writes the credential data into the second database 30. The message delivery component 400 is configured to configure a first type identifier corresponding to the transactional message sent by the first server 100 and a second type identifier corresponding to the transactional message received by the second server 200, where the first type identifier is consistent with the second type identifier. The first and second type identifiers may be identifiers that can be uniquely located with a message source: the Topic/EventCode is mainly used to distinguish the types of various messages so as to avoid interference from other message sources. Wherein, Topic may represent a large class of a message and EventCode may represent a subclass of a message.
In the above embodiment, the first server 100 sends the transactional message to the message delivery component 400, and after the message is received by the message delivery component 400, the first server 100 does not need to be concerned that the transactional message cannot be heard by the second server 200. Next, the message delivery component 400 may send the transaction-type message carrying the credential data to the second server 200 and request the second server 200 to send a response piece message, and if the message delivery component 400 does not receive the response piece message sent by the second server 200 indicating that the data was successfully written, the message delivery component 400 may resend the transaction-type message carrying the credential data to the second server 200 until receiving the response piece message indicating that the credential data was successfully written. That is, the successful writing of the credential data into the second database can be ensured by the message delivery component 400. In addition, the first server 100 may also request the message delivery component 400 to return a return receipt message after sending the transactional message to the message delivery component 400, and the return receipt message returned by the message delivery component 400 may include: the receipt message indicating successful message reception and the receipt message indicating failed message reception stop sending the transaction message to the message delivery component 400 after the first server 100 receives the receipt message indicating successful message reception, and otherwise, resends the transaction message to the message delivery component 400. Of course, as mentioned above, the first server 100 may directly send the above-mentioned transactional message to the second server 200, and request the second server 200 to return a corresponding receipt message to the first server 100, which is not limited in this application.
S105: and if the second server monitors the message, writing the initial state certificate data into the second database.
S106: the first server receives an instruction confirming that the change of the state of the credential data to the success.
As described above, in a fund-type transaction scenario, the credential data may be contract data between the user and the financial institution, after the user confirms the credential data, the financial institution may further confirm the credential data, and after the financial institution confirms the credential data, the first server may receive an instruction to change the state of the credential data to a successful state.
S107: and when the business system is not in the fail-over state, the first server changes the state of the certificate data written into the first database into a success state.
S108: and when the service system is not in the fail-over state, the first server sends a change message for changing the state of the credential data into a successful state to the second server.
S109: and when the second server monitors the change message, changing the state of the credential data written into the second database into a successful state.
Through the above process, in the embodiment of the application, when the service system is not in the failover state, the credential data (the credential for the account to perform the preset internet transaction) is written into the first database through the first server, and meanwhile, the credential data may be written into the second database through the second server in a manner that the first server sends a message to the second server. Wherein the first database is queried by the first server when the business system is not in the failover state, and the second database is queried by the first server when the business system is in the failover state. Compared with the prior art, whether the service system is in the failover state or not, the first server can judge the legality or security of the internet transaction corresponding to the account by inquiring whether the certificate data corresponding to the account exists in the first database or the second database, and then the internet transaction is completed when the legality or security of the internet transaction is determined, so that the problem that the internet transaction corresponding to each account cannot be normally completed when the service system is in the failover state in the prior art is solved.
In the embodiment of the present application, after the credential data (initial state or successful state) is written into the first database, the credential data may be written into the second database in a message manner. Of course, there may be no precedence order between writing the same credential data into the first database and the second database, and the credential data may be written into the second database first and then the same credential data may be written into the first database. Or, the act of writing the credential data into the first and second databases may be performed simultaneously, which is not limited in this application.
It should be noted that, in the above embodiment, the credential data may include an initial state and a success state, so that the credential data in the initial state needs to be created in the first database and the second database, respectively, and then the initial state of the credential data is changed to the success state, and it can be seen that the above process includes two data writing actions. Of course, in an alternative embodiment, the first database and the second database may perform the data writing operation only once, that is, when the credential data is in the initial state, the data writing operation is not performed, and when the state of the credential data is changed from the initial state to the successful state, the credential data is written into the first database and the second database. Or, the credential data is in a successful state after the user side confirms, and the credential data in the successful state may be directly written into the first database and the second database after the user side sends a confirmation instruction. There are many embodiments that can be implemented with respect to the above-described writing process of the status of the credential data, and this application is not intended to be exhaustive.
In the actual business process, there may be a problem that messages sent by the message delivery component are delivered multiple times. In order to solve the above problem, in the embodiment of the present application, a message delivered by a message delivery component is uniquely verified with a subscription protocol number and a status, so that, if a message with the same subscription protocol number and the same status is sent twice by the message delivery component (a second server also monitors twice correspondingly), after the message is monitored for the first time, the credential data successfully falls into a second database, and after the same message is monitored for the second time, the second server may query whether credential data required to be written exists in the second database, and if so, ignore the message and return a receipt message representing successful message processing to the message delivery component (avoid re-delivery).
Furthermore, in the actual business process, there may be problems with out-of-order messages sent by the message delivery component. To solve the above problem, in the embodiment of the present application, the second server generally needs to listen to the message from the second server twice, where once the credential data in the initial state is created, and once the credential data in the initial state is changed to the successful state. Generally, according to a normal flow, a first server sends a message written in credential data in an initial state first and then sends a message of changing a successful state, but if a delay or other situation occurs in a network, the message of changing the successful state may be heard by a second server before the message written in the credential data in the initial state, which is a messy message, and if the problem is not solved, the successful state of the credential data is covered by the initial state. In view of the above situation, when the message delivery component receives the message carrying the credential data in the initial state, it may determine the state of the credential data in the second database, and if the state of the credential data in the second database is already a successful state, it may ignore the state update and return a receipt message that the message processing is successful to the message delivery component, thereby effectively solving the problem of message disorder.
In the embodiment of the application, the first database is an Oracle database, and the second database is a MySQL database. The first database is a main database and stores business data and certificate data, and the Oracle database is adopted to enable the security of the data to be higher. Compared with an Oracle database, the MySQL database has lower cost, and is more suitable for being adopted because the second database is only used when the service system fails to transfer and only stores static voucher data.
It should be noted that, in the data writing method provided in the above embodiment, a process of writing the credential data corresponding to the account into the database in the account opening process is described. However, for the accounts which have completed the account opening and written the corresponding credential data into the first database, since the credential data already exists in these accounts, the writing action of the credential data by the above data writing method is not required to be performed again. In view of the above reasons, in the embodiment of the present application, during non-failover, the first server may backup the credential data of each account that has been opened, which is originally stored in the first database (the master database), to the second database, so as to ensure that the credential data of the first database and the second database are consistent.
Fig. 3 is a flowchart of a data writing method mainly based on a first server in an embodiment of the present application, and reference may be made to specific contents in the embodiment of fig. 2 corresponding to fig. 2. The data writing method may include:
s201: the method comprises the steps that a first server receives a confirmation instruction which is sent by a terminal and used for writing certificate data into a database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal.
In the scenario of a fund-like transaction, the credential data may be subscription data corresponding to each account. As described above, the contract data may be data generated by a contract operation between the user and the financial institution or between the financial institution and the financial institution. After the generated subscription data is written into the database, the subscription data may be used as a credential for determining whether a predetermined internet transaction (e.g., a fund transfer) corresponding to the account is legal or secure.
S202: the first server checks whether the business system is in a failover state.
As previously described, the first server may determine the state of the current business system by examining the failover flag. For example, if the failover flag is 1, it indicates that the current service system is in the failover state; if the failover state is 0, it indicates that the current service system is not in the failover state (or in the normal state).
S203: when the service system is not in a failure transfer state, the first server writes the certificate data into a first database; wherein the first database is queried by the first server when the service system is not in a failover state.
The step S203 can refer to the content of the step S103, which is not described herein again.
S204: when the service system is not in a failure transfer state, the first server sends a message carrying the certificate data to the second server; the second server is used for writing the credential data into a second database after receiving the message, and the second database is inquired by the first server when the service system is in a failure transfer state.
The step S204 can refer to the content of the step S104, which is not described herein again.
Through the embodiment provided by the above fig. 3, when the business system is in a failover state, whether the internet transaction corresponding to the account is legal or safe is determined by querying whether the credential data corresponding to the account exists in the second database, and the internet transaction is completed when the internet transaction is legal or safe.
It should be noted that, in an alternative embodiment of the present application, the step S204 may be implemented by the following processes: and when the service system is not in the failure transfer state, the first server writes the certificate data into the second database.
In addition, in this embodiment of the application, after the credential data is written into the first database and the second database, the credential data may be stored in a cache (may be stored for a preset time period), so that, in a subsequent credential data query process, the first server may preferentially query the cache to obtain the corresponding credential data, and if the cache does not have the credential data, query the first database or the second database.
Next, a transaction processing method for implementing an internet transaction of an account using the above-described first database and second database is described.
Fig. 4 is a flowchart of a transaction processing method according to an embodiment of the present application, including:
s301: the terminal sends a transaction request corresponding to the account logged in on the terminal to the first server. The transaction request is used for requesting to realize a preset internet transaction corresponding to the account.
In the above scenario of fund-based transaction, the account needs to store the subscription data in the database during the account opening process. The preset internet transaction may be a money transfer-in/out transaction for the account.
S302: after the first server receives the request sent by the terminal, the first server inquires whether credential data corresponding to the account exists in the cache.
S303: and when the service system is in a failure transfer state, the first server inquires whether the second database has the subscription data corresponding to the account. If the subscription data is queried, go to step S305; and if the subscription data is not inquired, judging that the preset internet affair corresponding to the current affair request is illegal or unsafe, and refusing to execute the preset internet affair.
S304: when the service system is not in the failover state, the first server inquires whether subscription data corresponding to the account exists in the first database. If the subscription data is inquired, entering step S306; and if the subscription data is not inquired, judging that the preset internet affair corresponding to the current affair request is illegal or unsafe, and refusing to execute the preset internet affair.
S305: and when the service system is in a failure transfer state, the first server writes service data corresponding to the preset internet transaction into the failover database.
S306: and the first server writes the service data corresponding to the preset internet transaction into the first database when the service system is not in the failover state.
Through the above process, in the process of performing the preset internet transaction of the account, the first server may first search whether the subscription data corresponding to the account exists by querying a cache (the cache may be a data storage unit located at an upper layer of the database). After the corresponding subscription data is not found from the cache, whether the current service system is in the failover state or not can be judged, whether the subscription data exists in the second database or not is inquired when the current service system is in the failover state, whether the subscription data exists in the first database or not is inquired when the current service system is not in the failover state, and therefore whether the subscription data corresponding to the account exists in the service system or not can be inquired, whether the preset internet transaction is legal or safe or not is judged according to the inquiry result, and the preset internet transaction of the account is completed.
In addition, when the service system is in a failover state, service data (such as a transfer amount, a transfer time, a transfer account number, and the like) of a preset internet transaction may be written into the failover database, and after the first database is recovered to be available, the service data temporarily stored in the failover database may be migrated back to the first database, so as to ensure integrity of the service data stored in the first database.
Next, a data writing device and a transaction processing device will be introduced, where the data writing device and the transaction processing device correspond to the data writing method and the transaction processing method, and the units included in the device are similar to the functions implemented by the steps included in the method, so that the device may refer to the details in the method, and will not be described again here. In addition, the above-mentioned means can be realized by software, hardware or a combination of software and hardware.
Fig. 5 is a block diagram of a data writing apparatus according to an embodiment of the present application. In an embodiment of the present application, a data writing apparatus includes:
the instruction receiving unit 101 is configured to receive a confirmation instruction sent by the terminal to write the credential data into the database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal.
The checking unit 102 is configured to check whether the service system is in a failover state.
A data writing unit 102, configured to write the credential data into a first database when the service system is not in a failover state; the first database is queried when the business system is not in a failover state.
A message sending unit 103, configured to send a message carrying the credential data to a second server when the service system is not in a failover state; the second server is configured to write the credential data into a second database after receiving the message, the second database being queried when the business system is in a failover state.
By the data writing device, whether the data is in a non-failure transfer state or in a failure transfer state, whether the current internet affairs are legal or safe can be judged by inquiring whether the first database or the second database has the certificate data corresponding to the account, and then the internet affairs corresponding to the accounts are completed on the premise of being legal or safe, so that the problem that the internet affairs corresponding to the accounts cannot be completed when the service system is in the failure transfer state in the prior art is solved.
In an embodiment of the present application, the apparatus further includes:
and the backup unit is used for backing up the certificate data stored in the first database to the second database when the certificate data is not in failover. The backup unit can backup the voucher data corresponding to the account which is opened to the second database, so that the voucher data in the first database and the voucher data in the second database are consistent.
In this embodiment of the application, the message sending unit 103 may be specifically configured to:
sending a transaction-type message carrying the credential data to a second server;
the apparatus may be further configured to:
when receiving a response message indicating data write failure from the second server, resending the transactional message to the second server;
and stopping sending the transaction type message to the second server when the first server receives a response message which is from the second server and indicates that the data writing is successful.
Through the transaction message, it can be ensured that the credential data can be successfully written into the second database.
In this embodiment of the application, the message sending unit 103 may be further specifically configured to:
sending a transaction-type message carrying the credential data to a message delivery component; the message delivery component is used for sending the transactional message to the second server until the message delivery component receives a response piece message which represents that the data writing is successful and comes from the second server;
the apparatus may be further configured to:
when receiving a receipt message which is from the message delivery component and indicates that the message is failed to be received, re-sending the transaction type message carrying the voucher data to the message delivery component;
and when receiving a receipt message which represents that the message is successfully received from the message delivery component, stopping sending the transaction type message carrying the voucher data to the message delivery component.
In an embodiment of the present application, the data writing unit 102 may be specifically configured to:
and writing the credential data in the initial state into the first database, and changing the state of the credential data in the first database when the state of the credential data is changed into the successful state.
In another embodiment, the data writing unit 102 may be specifically configured to: writing credential data for a success status into the first database;
in an embodiment of the present application, the message sending unit 103 may be specifically configured to:
sending a message carrying credential data in an initial state to a second server, and sending a state change message to the second server when the state of the credential data is changed into a successful state; the second server is configured to change the state of the credential data in the second database to a successful state after monitoring the state change message.
In another embodiment, the message sending unit 103 may specifically be configured to:
and sending a message carrying the credential data of the successful state to the second server.
Fig. 6 is a block diagram of a data writing apparatus according to another embodiment of the present application. In an embodiment of the present application, a data writing apparatus includes:
an instruction receiving unit 201, configured to receive a confirmation instruction sent by the terminal to write the credential data into the database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
a checking unit 202, configured to check whether the service system is in a failover state;
a first writing unit 203, configured to write the credential data into a first database when the service system is not in a failover state; the first database is queried when the business system is not in a failover state;
a second writing unit 204, configured to write the credential data into a second database when the service system is not in a failover state; the second database is queried when the business system is in a failover state.
Fig. 7 is a block diagram of a transaction processing apparatus according to an embodiment of the present application. In an embodiment of the present application, a transaction processing apparatus includes:
a request receiving unit 301, configured to receive a transaction request sent by a terminal and corresponding to an account logged in the terminal;
a checking unit 302, configured to check whether the service system is in a failover state;
the query unit 303 is configured to query whether credential data corresponding to the account is stored in the second database when the service system is in the failover state; the second database is inquired when the business system is in a failure transfer state, and the second database is written into the certificate data when the business system is not in the failure transfer state, wherein the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
a service data writing unit 304, configured to write the service data corresponding to the transaction request into the failover database when the credential data is queried in the second database; wherein the failover database is used when the business system is in a failover state.
By the transaction processing device provided by the embodiment, whether the service system is in the failover state or not can be judged whether the current internet transaction is legal or safe or not according to the inquiry result by inquiring whether the subscription data corresponding to the account exists in the first database or the second database, and the internet transaction of the account is completed on the premise of legality and safety. The problem that the internet affairs can not be normally carried out when the service system is in the failure transfer state in the prior art is solved.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.
As will be appreciated by one skilled in the art, 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 flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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 a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
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 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
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 an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application 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 application 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 tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks 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 memory storage devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.
Claims (12)
1. A method of writing data, comprising:
the method comprises the steps that a first server receives a confirmation instruction which is sent by a terminal and used for writing certificate data into a database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
the first server checks whether the service system is in a failover state;
when the service system is not in a failure transfer state, the first server writes the certificate data into a first database; the first database is queried by the first server when the service system is not in a failover state;
when the service system is not in a failure transfer state, the first server sends a message carrying the certificate data to the second server; the second server is configured to write the credential data into a second database after receiving the message, the second database being queried by the first server when the service system is in a failover state.
2. The method of claim 1, wherein the sending, by the first server, the message carrying the credential data to the second server specifically comprises:
the first server sends a transaction type message carrying the credential data to the second server;
then, after the first server sends the message carrying the credential data to the second server, the method further includes:
when the first server receives a response message which is from the second server and indicates that the data writing fails, the first server resends the transactional message to the second server;
and when the first server receives the response receipt message which represents that the data writing is successful from the second server, the first server stops sending the transactional message to the second server.
3. The method of claim 1, wherein the sending, by the first server, the message carrying the credential data to the second server specifically comprises:
the first server sends a transaction-type message carrying the voucher data to a message delivery component; the message delivery component is used for sending the transaction-type message from the first server to the second server until the message delivery component receives a response piece message which represents that the data writing is successful and is from the second server;
after the first server sends a transactional message carrying the credential data to a message delivery component, the method further comprises:
when the first server receives a receipt message which is from the message delivery component and indicates that the message is failed to be received, the first server resends the transactional message carrying the voucher data to the message delivery component;
and when the first server receives a receipt message which is from the message delivery component and indicates that the message is successfully received, the first server stops sending the transaction-type message carrying the voucher data to the message delivery component.
4. The method of claim 1, wherein the first server writing the credential data to the first database comprises:
the method comprises the steps that a first server writes credential data in an initial state into a first database, and when the state of the credential data is changed into a successful state, the first server changes the state of the credential data in the first database;
or, the first server writes the credential data of the success status into the first database;
the sending, by the first server, a message carrying the credential data to the second server specifically includes:
the method comprises the steps that a first server sends a message carrying credential data in an initial state to a second server, and when the state of the credential data is changed into a successful state, the first server sends a state change message to the second server; the second server is used for changing the state of the credential data in the second database into a successful state after monitoring the state change message;
or the first server sends a message carrying the credential data of the successful state to the second server.
5. A method of writing data, comprising:
the method comprises the steps that a first server receives a confirmation instruction which is sent by a terminal and used for writing certificate data into a database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
the first server checks whether the service system is in a failover state;
when the service system is not in a failure transfer state, the first server writes the certificate data into a first database; the first database is queried by the first server when the service system is not in a failover state;
when the service system is not in a failure transfer state, the first server writes the certificate data into a second database; the second database is queried by the first server when the service system is in a failover state.
6. A transaction processing method, comprising:
a first server receives a transaction request which is sent by a terminal and corresponds to an account logged in the terminal;
the first server checks whether the service system is in a failover state;
when the service system is in a failure transfer state, the first server inquires whether credential data corresponding to the account is stored in a second database; the second database is inquired by the first server when the service system is in a failure transfer state, and the second database is written into the certificate data when the service system is not in the failure transfer state, wherein the certificate data is a certificate for carrying out a preset internet transaction on an account logged in on the terminal;
if the certificate data are inquired in the second database, the first server writes the service data corresponding to the transaction request into a failover database; the failover database is used by the first server when the service system is in a failover state.
7. A data writing apparatus, comprising:
the instruction receiving unit is used for receiving a confirmation instruction which is sent by the terminal and used for writing the certificate data into the database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
the checking unit is used for checking whether the service system is in a failure transfer state;
the data writing unit is used for writing the certificate data into a first database when the service system is not in a failure transfer state; the first database is queried when the business system is not in a failover state;
the message sending unit is used for sending a message carrying the certificate data to a second server when the service system is not in the failure transfer state; the second server is configured to write the credential data into a second database after receiving the message, the second database being queried when the business system is in a failover state.
8. The apparatus as claimed in claim 7, wherein said message sending unit is specifically configured to:
sending a transaction-type message carrying the credential data to a second server;
the apparatus is further configured to:
when receiving a response message indicating data write failure from the second server, resending the transactional message to the second server;
and stopping sending the transaction type message to the second server when the first server receives a response message which is from the second server and indicates that the data writing is successful.
9. The apparatus as claimed in claim 7, wherein said message sending unit is specifically configured to:
sending a transaction-type message carrying the credential data to a message delivery component; the message delivery component is used for sending the transactional message to the second server until the message delivery component receives a response piece message which represents that the data writing is successful and comes from the second server;
the apparatus is further configured to:
when receiving a receipt message which is from the message delivery component and indicates that the message is failed to be received, re-sending the transaction type message carrying the voucher data to the message delivery component;
and when receiving a receipt message which represents that the message is successfully received from the message delivery component, stopping sending the transaction type message carrying the voucher data to the message delivery component.
10. The apparatus of claim 7, wherein the data writing unit is specifically configured to:
writing the credential data in the initial state into the first database, and changing the state of the credential data in the first database when the state of the credential data is changed into the successful state;
or, writing the credential data of the success status into the first database;
the message sending unit is specifically configured to:
sending a message carrying credential data in an initial state to a second server, and sending a state change message to the second server when the state of the credential data is changed into a successful state; the second server is used for changing the state of the credential data in the second database into a successful state after monitoring the state change message;
or sending a message carrying the credential data of the successful state to the second server.
11. A data writing apparatus, comprising:
the instruction receiving unit is used for receiving a confirmation instruction which is sent by the terminal and used for writing the certificate data into the database; the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
the checking unit is used for checking whether the service system is in a failure transfer state;
the first writing unit is used for writing the certificate data into a first database when the service system is not in a failure transfer state; the first database is queried when the business system is not in a failover state;
the second writing unit is used for writing the certificate data into a second database when the service system is not in a failure transfer state; the second database is queried when the business system is in a failover state.
12. A transaction processing apparatus, comprising:
the request receiving unit is used for receiving a transaction request which is sent by a terminal and corresponds to an account logged in the terminal;
the checking unit is used for checking whether the service system is in a failure transfer state;
the query unit is used for querying whether the second database stores the certificate data corresponding to the account or not when the service system is in the failover state; the second database is inquired when the service system is in a failure transfer state, and the second database is written into the certificate data when the service system is not in the failure transfer state, wherein the certificate data is a certificate for carrying out a preset internet transaction on an account logged in the terminal;
a service data writing unit, configured to write service data corresponding to the transaction request into a failover database when the credential data is queried in the second database; the failover database is used when the business system is in a failover state.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610189000.XA CN107239370B (en) | 2016-03-29 | 2016-03-29 | Data writing method, transaction processing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610189000.XA CN107239370B (en) | 2016-03-29 | 2016-03-29 | Data writing method, transaction processing method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107239370A CN107239370A (en) | 2017-10-10 |
| CN107239370B true CN107239370B (en) | 2020-09-08 |
Family
ID=59983998
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610189000.XA Active CN107239370B (en) | 2016-03-29 | 2016-03-29 | Data writing method, transaction processing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107239370B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109684353B (en) * | 2017-10-18 | 2022-11-22 | 腾讯科技（深圳）有限公司 | Numerical value transfer request processing method, device, server and storage medium |
| CN111144926B (en) * | 2019-11-27 | 2023-07-18 | 泰康保险集团股份有限公司 | Service request processing method, device, system, electronic equipment and readable medium |
| CN112612792B (en) * | 2020-12-24 | 2023-05-30 | 中国联合网络通信集团有限公司 | Database management method and system |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103944856A (en) * | 2013-01-17 | 2014-07-23 | 华为终端有限公司 | Authority transfer method and device |
| CN104281506A (en) * | 2014-07-10 | 2015-01-14 | 中国科学院计算技术研究所 | Data maintenance method and system for file system |
| CN105138427A (en) * | 2015-08-21 | 2015-12-09 | 湖南亿谷科技发展股份有限公司 | Data processing method and system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7536506B2 (en) * | 2004-06-21 | 2009-05-19 | Dot Hill Systems Corporation | RAID controller using capacitor energy source to flush volatile cache data to non-volatile memory during main power outage |
-
2016
- 2016-03-29 CN CN201610189000.XA patent/CN107239370B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103944856A (en) * | 2013-01-17 | 2014-07-23 | 华为终端有限公司 | Authority transfer method and device |
| CN104281506A (en) * | 2014-07-10 | 2015-01-14 | 中国科学院计算技术研究所 | Data maintenance method and system for file system |
| CN105138427A (en) * | 2015-08-21 | 2015-12-09 | 湖南亿谷科技发展股份有限公司 | Data processing method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107239370A (en) | 2017-10-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106899648B (en) | Data processing method and equipment | |
| CN109246197B (en) | Data processing method and device based on intelligent contract | |
| CN107231335B (en) | Service processing method and device | |
| CN108596582B (en) | Polymerization payment platform solution based on dubbo | |
| CN107239370B (en) | Data writing method, transaction processing method and device | |
| CN113837732A (en) | Internet resource transfer method, account transfer method and device | |
| WO2023045617A1 (en) | Transaction data processing method and apparatus, device and medium | |
| CN111382164A (en) | Service processing method based on block chain network | |
| CN110992035A (en) | Block chain link point management method, device and system | |
| CN112714158A (en) | Transaction processing method, relay network, cross-link gateway, system, medium, and device | |
| CN108647105B (en) | Idempotent control method, device and system in system switching process | |
| CN111311254A (en) | Service processing method, device and system based on block chain | |
| CN111158949A (en) | Configuration method, switching method and device of disaster recovery architecture, equipment and storage medium | |
| CN112437155B (en) | Service data processing method and device and server device | |
| CN111245897A (en) | Data processing method, device, system, storage medium and processor | |
| CN106034148B (en) | Rapid information interaction method, local server, remote server and system | |
| WO2023045532A1 (en) | Blockchain-based transaction processing | |
| CN115018499A (en) | Block chain-based digital certificate issuing method, device and system | |
| CN105790975A (en) | Service processing operation execution method and device | |
| CN115098469A (en) | Database migration method and device, electronic equipment and readable storage medium | |
| US10771242B2 (en) | Blockchain-based data processing | |
| US20210042295A1 (en) | Blockchain-based data management method and related system | |
| CN113282671A (en) | Claims settlement method and device based on block chain and electronic equipment | |
| CN114629806B (en) | Data processing method, device, electronic equipment, storage medium and program product | |
| CN113485930B (en) | Business process verification method, device, computer system and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20200921 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman, British Islands Patentee after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman, British Islands Patentee before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20200921 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman, British Islands Patentee after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Patentee before: Alibaba Group Holding Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220411 Address after: Room 602, No. 618, Wai Road, Huangpu District, Shanghai 200010 Patentee after: Ant fortune (Shanghai) Financial Information Service Co.,Ltd. Address before: Ky1-9008 business centre, 27 Hospital Road, Georgetown, grand caiman, UK Patentee before: Innovative advanced technology Co.,Ltd. |
|
| TR01 | Transfer of patent right |