Data consistency guarantee method and device based on Android system

Abstract

The application provides a data consistency guarantee method and device based on an Android system, and belongs to the technical field of Internet. The method comprises the following steps: obtaining application-level transaction data to be processed and a pre-established log mapping table. According to the correspondence between the application-level transaction and the page data in the flash translation layer, the page data corresponding to the application-level transaction data to be processed in the flash translation layer is determined. If the transaction state identifier is determined to be the same as the preset uncommitted transaction state identifier, the flash translation layer page is searched according to the application-level transaction data to be processed, so as to obtain the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition. According to the pre-established log mapping table, the data rollback operation is performed on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition, so as to obtain the consistent application-level transaction data and the target log mapping table. The application has the advantage of reducing the performance overhead generated for guaranteeing data consistency.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of Internet, and in particular, to a data consistency guarantee method and device based on an Android system. BACKGROUND

[0002] An Android system is an open source software system based on a Linux system and widely used in smart phones and other devices. Terminals based on the Android system are widely used in telephone communication, online banking, sending and receiving messages, online transfer and online financial services. Therefore, more and more users pay attention to whether the data update consistency can be guaranteed when an abnormal situation occurs. Data consistency refers to that when a user performs an operation (including canceling a step of operation), all data involved will change from one consistent state to another consistent state. How to maintain data consistency becomes an important challenge for system builders.

[0003] At present, in the prior art, when an abnormal situation occurs in the process of operation, in order to guarantee the data update consistency, a database with a log mechanism, a log file system and an atomic write at a storage device level are used. The above measures track uncommitted data modification and record the modification in a data structure called "log" to restore the data to a consistent state when an abnormal situation occurs.

[0004] However, the inventors find that the above measures taken to guarantee data consistency will cause log redundancy, thereby increasing the performance overhead of the system. SUMMARY

[0005] The present application provides a data consistency guarantee method and device based on an Android system, which can reduce the performance overhead generated to guarantee data consistency when the system crashes.

[0006] In a first aspect, the present application provides a data consistency guarantee method based on an Android system, comprising:

[0007] Obtaining application-level transaction data to be processed and a pre-established log mapping table, wherein the pre-established log mapping table includes a corresponding relationship between an application-level transaction and page data in a flash translation layer, and the pre-established log mapping table is data stored in a spin torque memory in the flash translation layer.

[0008] determine, according to a correspondence between the application-level transaction and page data in the flash translation layer, page data corresponding to the to-be-processed application-level transaction data in the flash translation layer, wherein the page data corresponding to the to-be-processed application-level transaction data includes a transaction unique identifier, a transaction state identifier, and a flash translation layer page;

[0009] If it is determined that the transaction state identifier is the same as a preset uncommitted transaction state identifier, perform a lookup operation on the flash translation layer page according to the to-be-processed application-level transaction data, to obtain a flash translation layer page corresponding to a transaction unique identifier that meets a preset condition;

[0010] perform a data rollback operation on the flash translation layer page corresponding to the transaction unique identifier that meets the preset condition according to the pre-established log mapping table, to obtain consistent application-level transaction data and a target log mapping table.

[0011] In a possible implementation, the determining, according to a correspondence between the application-level transaction and page data in the flash translation layer, of page data corresponding to the to-be-processed application-level transaction data in the flash translation layer includes:

[0012] determine, according to the to-be-processed application-level transaction data, a transaction unique identifier of the to-be-processed application-level transaction;

[0013] perform an identifier matching process on the transaction unique identifiers in the pre-established log mapping table according to the transaction unique identifier of the to-be-processed application-level transaction, to obtain a to-be-processed transaction unique identifier in the pre-established log mapping table that is the same as the transaction unique identifier of the to-be-processed application-level transaction;

[0014] determine, according to the to-be-processed transaction unique identifier, a transaction state identifier and a flash translation layer page corresponding to each to-be-processed transaction unique identifier;

[0015] store the transaction unique identifier, the transaction state identifier, and the flash translation layer page in the pre-established log mapping table as page data.

[0016] In a possible implementation, the to-be-processed application-level transaction data includes page logical block number data and logical page offset data.

[0017] Correspondingly, the performing a lookup operation on the flash translation layer page according to the to-be-processed application-level transaction data, to obtain a flash translation layer page corresponding to a transaction unique identifier that meets a preset condition, includes:

[0018] determine, according to the logical block number data, physical block number data in the pre-established log mapping table;

[0019] determining, according to the logical page offset data, physical page offset data in the pre-established log mapping table;

[0020] determining, according to the physical block number data and the physical page offset data, a physical address of the flash translation layer page;

[0021] determining, according to the physical address of the flash translation layer page, a flash translation layer page corresponding to the to-be-processed transaction data;

[0022] if it is determined that the transaction unique identifier of the transaction data satisfies a preset condition, obtaining, from the flash translation layer page corresponding to the to-be-processed transaction data, a flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition.

[0023] In a possible implementation, the pre-established log mapping table includes value range data defined by two primitive operations;

[0024] Correspondingly, the data rollback operation on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the pre-established log mapping table to obtain consistent application-level transaction data and a target log mapping table includes:

[0025] performing a sorting operation on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the value range data to determine data recovery order information;

[0026] performing recovery processing on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the data recovery order information to obtain consistent application-level transaction data;

[0027] performing update processing on the pre-established log mapping table according to the data recovery order information to obtain a target log mapping table.

[0028] In a possible implementation, the update processing on the pre-established log mapping table includes:

[0029] performing the update processing on the pre-established log mapping table in a spin torque memory of the flash translation layer.

[0030] In a possible implementation, after determining, according to the correspondence between the application-level transaction and the page data in the flash translation layer, the page data in the flash translation layer corresponding to the to-be-processed application-level transaction data, the method further includes:

[0031] if it is determined that the transaction state identifier is different from a preset uncommitted transaction state identifier, obtaining a cancel operation command;

[0032] According to the cancel operation command, the to-be-processed application-level transaction data is stored as consistent application-level transaction data.

[0033] In a second aspect, the present application provides a data consistency guarantee device based on an Android system, comprising:

[0034] a data acquisition module, configured to acquire to-be-processed application-level transaction data and a pre-established log mapping table, wherein the pre-established log mapping table comprises a corresponding relationship between an application-level transaction and page data in a flash translation layer, and the pre-established log mapping table is data stored in a spin torque transfer memory in the flash translation layer;

[0035] a first data searching module, configured to determine, according to the corresponding relationship between the application-level transaction and the page data in the flash translation layer, page data in the flash translation layer corresponding to the to-be-processed application-level transaction data, wherein the page data corresponding to the to-be-processed application-level transaction data comprises a transaction unique identifier, a transaction state identifier and a flash translation layer page;

[0036] a second data searching module, configured to, if it is determined that the transaction state identifier is identical to a preset uncommitted transaction state identifier, perform a searching operation on the flash translation layer page according to the to-be-processed application-level transaction data, so as to obtain a flash translation layer page corresponding to a transaction unique identifier satisfying a preset condition;

[0037] a data consistency updating module, configured to perform a data rollback operation on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the pre-established log mapping table, so as to obtain consistent application-level transaction data and a target log mapping table.

[0038] In a third aspect, the present application provides a data consistency guarantee system based on an Android system, comprising at least one processor and a memory.

[0039] The memory stores computer execution instructions.

[0040] The at least one processor executes the computer execution instructions stored in the memory, so that the at least one processor executes the method described in the first aspect.

[0041] In a fourth aspect, the present application provides a computer readable storage medium, wherein the computer readable storage medium stores a computer execution instruction, and when a processor executes the computer execution instruction, the method described in the first aspect is realized.

[0042] In a fifth aspect, the present application provides a computer program product, comprising a computer program, which, when executed by a processor, realizes the method described in the first aspect.

[0043] The application provides a data consistency guarantee method and device based on an Android system. A pre-established log mapping table is obtained during an application-level transaction data generation process and stored in a spin torque memory of a flash translation layer. The non-volatility and byte addressing characteristics of the spin torque memory are used to overcome the problem of write amplification and reduce performance overhead. Then, according to the correspondence between the application-level transaction in the pre-established log mapping table and the page data in the flash translation layer, the page data corresponding to the to-be-processed application-level transaction data in the flash translation layer is determined. If the transaction state identifier in the page data indicates that the transaction is not committed, a flash translation layer page in the page data is searched according to the to-be-processed application-level transaction data, to obtain a flash translation layer page corresponding to a transaction unique identifier that meets a preset condition. Finally, the flash translation layer page is subjected to a data rollback operation according to the pre-established log mapping table, to obtain consistent application-level transaction data and a target log mapping table. The application performs a data rollback operation on the page in the flash translation layer at the bottom of the file system, to guarantee data consistency. Compared with the log in the upper layer, the pre-established log mapping table in the flash translation layer introduces less metadata, further reducing the performance overhead generated by the data rollback operation. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0045] Figure 1 An application scenario diagram of a data consistency guarantee method based on an Android system provided by the embodiments of the present application;

[0046] Figure 2 A hardware structure diagram of a data I / O stack of an Android system provided by the embodiments of the present application;

[0047] Figure 3 A flow diagram of a data consistency guarantee method based on an Android system provided by the embodiments of the present application;

[0048] Figure 4 A structure diagram of a data consistency guarantee device based on an Android system provided by the embodiments of the present application;

[0049] Figure 5 A hardware structure diagram of a data consistency guarantee system based on an Android system provided by the embodiments of the present application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] In the Android system, data consistency refers to the characteristic that all data involved in a user operation (including undoing an operation) will transition from one consistent state to another. For example, in the event of an exception such as a power outage, system crash, or network interruption, users expect to perform some user-level operations (application-level transactions) atomically. When the system restarts, the operations performed by the software before the system crash should be in a fully completed state or all ongoing operations should be undone. At this time, the corresponding application data should be in a consistent state before the application operations were performed or in a consistent state after the operations were performed. In existing technologies, most applications in the Android system use SQLite (Structured Query Language) databases to store persistent data. SQLite databases often employ a data consistency guarantee technique called a log mechanism. This technique tracks modifications to uncommitted data and records these modifications in a log, thereby restoring interrupted data to a consistent state. The inventors discovered that in existing technologies, EXT4 (Fourth extended filesystem), a commonly used file system in the Android system, uses write-ahead logging to ensure the consistency of data in both SQLite databases and file systems, respectively. EXT4 logs the metadata of each SQLite database transaction log file. However, SQLite cannot guarantee that the file system can ensure crash consistency, and similarly, EXT4 cannot determine whether SQLite uses a logging mechanism. Therefore, both SQLite and EXT4 use logging mechanisms to ensure data consistency for identical data (including user data and metadata), leading to significant log redundancy and increased system performance overhead.

[0052] To solve the above technical problems, the embodiment of the present application provides the following technical concept for solving the problem: in the process of implementing the application-level transaction, the log mechanism can be used to ensure data consistency in any one of the application layer, the file system layer or the FTL (Flash Translation Layer), but the inventor finds that the higher the level is, the closer to the application side, the greater the performance overhead required is. Therefore, to implement the application-level transaction, first, a cross-layer log mapping table is constructed to record the correspondence between the application-level transaction and the FTL multi-page atomic write operation. Then all the FTL update operations corresponding to the application-level transaction are performed to update data through the FTL multi-page atomic write operation, so as to ensure the data consistency at the application level.

[0053] Figure 1 An application scenario of the data consistency guarantee method based on the Android system provided by the embodiment of the present application is shown in FIG. 1. Figure 1 As shown in FIG. 1, the application scenario includes a terminal 101 and a server 102.

[0054] The terminal 101 is configured to restart the system, input data and display data. The server 102 is configured to perform the data consistency guarantee operation to obtain data with consistency when an exception occurs.

[0055] Figure 2 A hardware structure diagram of the data I / O stack of the Android system provided by the embodiment of the present application is shown in FIG. 2. Figure 2 As shown in FIG. 2, the I / O stack includes an application layer 301, an operating system layer 202 and a flash translation layer 303. The application layer 301 is configured to run the application to generate application-level transaction data, and the application layer 201 can include a SQLite database, a browser and an address book. The operating system layer 202 is configured to logically group the metadata information and the data block related to data change into a unit called a transaction, and the operating system layer 202 can be an EXT4 file system, a display and a flash memory. The flash translation layer 303 can include a NAND flash memory embedded in an electronic product, a random memory, a static random memory and a dynamic random memory, and is configured to store data. For example, the embedded electronic product can be a mobile phone or an MP3 player.

[0056] Figure 3 A flowchart of the data consistency guarantee method based on the Android system provided by the embodiment of the present application is shown in FIG. 3. The execution subject of the embodiment can be Figure 1The server 102 in the illustrated embodiment can also be other computer-related devices, and the embodiment is not particularly limited.

[0057] As Figure 3 illustrated, an Android system-based data consistency guarantee method includes:

[0058] S301: Obtain to-be-processed application-level transaction data and a pre-established log mapping table, wherein the pre-established log mapping table includes a correspondence between the application-level transaction and page data in the flash translation layer, and the pre-established log mapping table is data stored in a spin torque memory of the flash translation layer.

[0059] In the embodiment, the to-be-processed application-level transaction data is data generated in an application-level transaction execution process, wherein a transaction refers to a series of operations performed by a single logical unit, and the execution can be complete or not at all.

[0060] In the embodiment, the pre-established log mapping table is cross-layer metadata that is pre-stored in data in the spin torque memory of the flash translation layer 203 as Figure 2 illustrated. The spin torque memory has non-volatility and byte addressing characteristics, and can be used to update data remotely.

[0061] The cross-layer mentioned in the above embodiment refers to the fact that the pre-established log mapping table includes metadata of data in the flash translation layer and metadata in the application transaction layer. The correspondence refers to a relationship between two data, for example, the relationship can be that the two data are located in the same column, in the same row, or are common variable parameters in a calculation formula.

[0062] S302: Determine, according to the correspondence between the application-level transaction and the page data in the flash translation layer, page data in the flash translation layer corresponding to the to-be-processed application-level transaction data, wherein the page data corresponding to the to-be-processed application-level transaction data includes a transaction unique identifier, a transaction state identifier, and a flash translation layer page.

[0063] In the embodiment, the transaction unique identifier can be a unique identification code composed of numbers, letters, or symbols. For example, if the unique identifier of an application-level transaction is 0, then the related data with the unique identifier 0 in the pre-established log mapping table is data generated in the application-level transaction process.

[0064] In the embodiment, the transaction status identifier is a code indicating the status of the application-level transaction. For example, the transaction status identifier of a certain application-level transaction is 0, indicating that the application-level transaction to which the page belongs has not been committed. Once the system is restarted, the application-level transaction data needs to be restored to ensure data consistency. When the transaction status identifier of a certain application-level transaction is 1, indicating that the application-level transaction to which the page belongs has been committed, the application-level transaction data does not need to be restored, and data consistency can be ensured.

[0065] In the embodiment, the flash translation layer page is a log page recorded during execution of the to-be-processed application-level transaction and related to the to-be-processed application-level transaction.

[0066] Specifically, based on the above embodiment, in an optional embodiment of the present application, step S202 comprises:

[0067] S302a: determining the transaction unique identifier of the to-be-processed application-level transaction according to the to-be-processed application-level transaction data.

[0068] S302b: performing identifier matching processing on the transaction unique identifiers in the pre-established log mapping table according to the transaction unique identifier of the to-be-processed application-level transaction, to obtain a to-be-processed transaction unique identifier in the pre-established log mapping table that is the same as the transaction unique identifier of the to-be-processed application-level transaction.

[0069] S302c: determining the transaction status identifier and the flash translation layer page corresponding to each to-be-processed transaction unique identifier according to the to-be-processed transaction unique identifier.

[0070] S302d: storing the transaction unique identifier, the transaction status identifier, and the flash translation layer page in the pre-established log mapping table as page data.

[0071] In the embodiment, the to-be-processed application-level transaction generates a unique identifier representing the transaction at the initial moment when the transaction is executed, and the unique identifier is stored as one of the to-be-processed application-level transaction data. In the embodiment, the pre-established log mapping table has the same transaction unique identifier as the to-be-processed application-level transaction data, so that only table matching search needs to be performed on the pre-established log mapping table.

[0072] In the embodiment, the pre-established log mapping table is a metadata table, and the transaction status identifier and the flash translation layer page corresponding to each to-be-processed transaction unique identifier can be determined through table retrieval according to the corresponding relationship in the table.

[0073] S303: if it is determined that the transaction status identifier is the same as the preset uncommitted transaction status identifier, performing a lookup operation on the flash translation layer page according to the to-be-processed application-level transaction data, to obtain the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition.

[0074] In this embodiment, the preset uncommitted transaction state identifier can be a code artificially defined, such as 0 in step S302. In this embodiment, the searching operation can be a searching program or an algorithm, and the identifier to be searched can be input to obtain the identifier with high matching degree or the same identifier as the input identifier, and the flash translation layer page corresponding to the identifier.

[0075] Specifically, in an optional embodiment of the present application, the application transaction data to be processed in the above embodiment includes the logical block number and the logical page offset data, and correspondingly, the searching operation on the flash translation layer page according to the application transaction data to be processed in step S303 to obtain the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition includes:

[0076] S303a: determining the physical block number data in the pre-established log mapping table according to the logical block number data.

[0077] S303b: determining the physical page offset data in the pre-established log mapping table according to the logical page offset data.

[0078] S303c: determining the physical address of the flash translation layer page according to the physical block number data and the physical page offset data.

[0079] S303d: determining the flash translation layer page corresponding to the transaction data to be processed according to the physical address of the flash translation layer page.

[0080] S303e: if it is determined that the transaction unique identifier of the transaction data satisfies the preset condition, obtaining the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition from the flash translation layer page corresponding to the transaction data to be processed.

[0081] In this embodiment, the logical block is the number of the logical block of a file in a disk, the physical block is the number of the physical block of the file in the disk, the sectors of the disk constitute the physical block, the physical block corresponds to the logical block, and the logical block corresponds to the file. The logical address is divided into the logical block number and the block address, the physical address is divided into the physical block number and the block address, and the physical address is converted from the logical address by the operating system. The page offset data can include the address offset, which is the byte distance of the memory unit address in the segment relative to the memory unit at the beginning of the segment.

[0082] For example, the logical block number, the physical block number, the logical address, the physical page offset data and the logical page offset data are also generated in the pre-established log mapping table during the execution of the application transaction. The specific data can be referred to Table 1 as follows:

[0083]

[0084] Table 1

[0085] As shown in Table 1, assuming that the physical block number is 1, the application-level transaction data in the flash translation layer corresponding to the physical block number is "a, b, c, and d". Assuming that the logical block number is 1000, the application-level transaction data corresponding to the logical block number is 1000, and the corresponding logical page offset addresses are 0, 1, 2, and 3, and the physical page offset addresses are 0, 3, k, and k+1, where k is a natural number greater than 3.

[0086] S304: performing a data rollback operation on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the pre-established log mapping table, to obtain consistent application-level transaction data and a target log mapping table.

[0087] In the embodiment, the preset condition can be a human-set identification code, which is of the same type as the transaction unique identifier. For example, the preset condition is 0. In the embodiment, the data rollback operation refers to the behavior of restoring a program or data to the last correct state due to a program or data processing error. For example, the preset condition is 1, and the application-level transaction is a transfer transaction. When an abnormal situation such as system crash or mobile phone power failure occurs in the middle of the transfer transaction, it is first determined whether the transaction state identifier of the transfer transaction is 0. If it is 0, it indicates that the transfer transaction has not been committed, and all transaction unique identifiers are 1. The pages in the flash translation layer corresponding to the transaction unique identifiers are found, and data rollback is performed on these pages until the data related to the transfer transaction is restored to the state at the beginning of the transfer transaction, to ensure data consistency.

[0088] Specifically, on the basis of the above embodiment, in an optional embodiment of the present application, the pre-established log mapping table further includes value range data delimited by two primitive operations. Correspondingly, step S304 includes:

[0089] S304a: performing a sorting operation on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the value range data, to determine data recovery order information.

[0090] S304b: performing a recovery process on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the data recovery order information, to obtain consistent application-level transaction data.

[0091] S304c: performing an update process on the pre-established log mapping table according to the data recovery order information, to obtain a target log mapping table.

[0092] In the embodiment, the value range is a numerical interval for atomic write operation of the application-level transaction data, the primitive operation refers to a program segment composed of a plurality of instructions, and is used to implement a specific function and cannot be interrupted in the execution process. For example, the corresponding atomic write operation of the application-level transaction data "a, b, c and d" is wrapped in by using two instructions TX-start and TX-end. Assuming that the corresponding data of a, b, c and d before the transaction is committed is a1, b1, c1 and d1, the consistent application-level transaction data obtained should be a1, b1, c1 and d1.

[0093] In the embodiment, the target log mapping table is a log mapping table generated after updating the pre-established log mapping table. The target log mapping table records the metadata obtained in the process of obtaining the consistent application-level transaction data after the rollback operation of the to-be-processed application-level transaction, for example, the metadata can be a physical block number, a logical block number, logical page offset data, physical page offset data, a transaction unique identifier and a transaction state identifier corresponding to the consistent application transaction data.

[0094] In summary, the data consistency guarantee method based on the Android system provided in the application obtains the pre-established log mapping table in the application-level transaction data generation process, and stores the pre-established log mapping table in the spin torque memory of the flash translation layer. The non-volatility and byte addressing characteristics of the spin torque memory are used to overcome the problem of write amplification and reduce performance overhead. Then, according to the correspondence between the application-level transaction in the pre-established log mapping table and the page data in the flash translation layer, the page data corresponding to the to-be-processed application-level transaction data in the flash translation layer is determined. If it is determined that the transaction state identifier in the page data indicates that the transaction is not committed, the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition is obtained by performing a lookup operation on the flash translation layer page in the page data according to the to-be-processed application-level transaction data. Finally, the data rollback operation is performed on the flash translation layer page according to the pre-established log mapping table, so as to obtain the consistent application-level transaction data and the target log mapping table. The application performs the data rollback operation on the page in the flash translation layer at the bottom layer of the file system to guarantee data consistency. Compared with the log in the upper layer, the pre-established log mapping table in the flash translation layer introduces less metadata, and the performance overhead generated by the data rollback operation is further reduced.

[0095] On the basis of the above-mentioned embodiment, in an optional embodiment of the application, the updating process of the pre-established log mapping table in step S304c comprises:

[0096] The updating process of the pre-established log mapping table is performed in the spin torque memory of the flash translation layer.

[0097] In this embodiment, during the implementation of application-level transactions, to ensure data consistency after an exception occurs and the system restarts, it is possible to... Figure 2 The log mapping table can be implemented at the application layer, the operating system layer, or the flash translation layer. From the bottom flash translation layer to the application layer, each higher layer of the log record references more metadata than the lower layer, thus incurring greater performance overhead. Therefore, this application performs the update processing of the pre-built log mapping table in the spin torque memory of the flash translation layer.

[0098] In summary, the data consistency guarantee method based on the Android system provided in this application reduces the introduction of metadata and further reduces performance overhead by performing the update processing of a pre-established log mapping table in a spin-transfer torque memory in the lowest-level flash conversion layer.

[0099] Based on the above embodiments, in an optional embodiment of this application, after step S302, the method further includes:

[0100] Step A: If the transaction status identifier is different from the preset uncommitted transaction status identifier, then obtain the cancellation operation command.

[0101] Step B: Based on the cancellation operation command, save the pending application-level transaction data as consistent application-level transaction data.

[0102] In this embodiment, a state flag different from the preset uncommitted transaction status indicates that the pending application-level transaction has been committed, ensuring data consistency without the need for a rollback operation. In the event of an anomaly, the pending application-level transaction data can be used as consistent application-level data. For example, if a transfer transaction was completed before the system crashed, the data available after the system restarts will be the data from when the transfer was completed, without needing to revert to the initial state of the transfer.

[0103] In summary, the data consistency guarantee method based on the Android system provided in this embodiment reduces subsequent operations and thus reduces performance overhead by directly storing submitted application-level transactions as consistent application-level transaction data.

[0104] Figure 4 This is a schematic diagram of a data consistency guarantee device based on the Android system provided in an embodiment of this application. The device includes: a data acquisition module 41, a first data search module 42, a second data search module 43, and a data consistency update module 44.

[0105] The data acquisition module 41 is configured to acquire application-level transaction data to be processed and a pre-established log mapping table, wherein the pre-established log mapping table comprises a correspondence between the application-level transaction and page data in the flash translation layer, and the pre-established log mapping table is data stored in the spin torque memory in the flash translation layer.

[0106] The first data searching module 42 is configured to determine, according to the correspondence between the application-level transaction and the page data in the flash translation layer, page data corresponding to the application-level transaction data to be processed in the flash translation layer, wherein the page data corresponding to the application-level transaction data to be processed comprises a transaction unique identifier, a transaction state identifier and a flash translation layer page.

[0107] The second data searching module 43 is configured to, if it is determined that the transaction state identifier is the same as a preset uncommitted transaction state identifier, perform a searching operation on the flash translation layer page according to the application-level transaction data to be processed, to obtain a flash translation layer page corresponding to a transaction unique identifier satisfying a preset condition.

[0108] The data consistency updating module 44 is configured to perform a data rollback operation on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the pre-established log mapping table, to obtain consistent application-level transaction data and a target log mapping table.

[0109] The data consistency guarantee device based on the Android system provided in the embodiment can be used to execute the technical solutions of the method embodiments, and has similar implementation principles and technical effects, which will not be described here again.

[0110] In an optional embodiment of the present application, the first data searching module 44 is configured to: determine, according to the application-level transaction data to be processed, a transaction unique identifier of the application-level transaction to be processed; perform identifier matching processing on the transaction unique identifiers in the pre-established log mapping table according to the transaction unique identifier of the application-level transaction to be processed, to obtain a to-be-processed transaction unique identifier in the pre-established log mapping table which is the same as the transaction unique identifier of the application-level transaction to be processed; determine, according to the to-be-processed transaction unique identifier, each transaction state identifier and flash translation layer page corresponding to the to-be-processed transaction unique identifier; and store the transaction unique identifier, the transaction state identifier and the flash translation layer page in the pre-established log mapping table as page data.

[0111] In an optional embodiment of the present application, the to-be-processed application-level transaction data includes page logical block number data and logical page offset data, the second data searching module 43 is specifically configured to: determine the physical block number data in the pre-established log mapping table according to the logical block number data; determine the physical page offset data in the pre-established log mapping table according to the logical page offset data; determine the physical address of the flash translation layer page according to the physical block number data and the physical page offset data; determine the flash translation layer page corresponding to the to-be-processed transaction data according to the physical address of the flash translation layer page; and if it is determined that the transaction unique identifier of the transaction data satisfies the preset condition, obtain the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition from the flash translation layer page corresponding to the to-be-processed transaction data.

[0112] In an optional embodiment of the present application, the pre-established log mapping table includes value range data delimited by two primitive operations, and the data consistency updating module 44 is specifically configured to: perform a sorting operation on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the value range data, to determine data recovery order information; perform recovery processing on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the data recovery order information, to obtain consistent application-level transaction data; and perform updating processing on the pre-established log mapping table according to the data recovery order information, to obtain a target log mapping table.

[0113] In an optional embodiment of the present application, the data consistency updating module 44 is configured to perform the updating processing on the pre-established log mapping table in the spin torque random access memory of the flash translation layer.

[0114] In an optional embodiment of the present application, the first data searching module 42 is further configured to: if it is determined that the transaction state identifier is different from the preset uncommitted transaction state identifier, obtain a cancel operation command; and store the to-be-processed application-level transaction data as consistent application-level transaction data according to the cancel operation command.

[0115] Figure 5 A hardware structure schematic diagram of a data consistency guarantee system based on an Android system provided by an embodiment of the present application is shown in FIG. 1, which includes at least one processor 501 and a memory 502. Figure 5

[0116] The processor 501 is configured to store computer execution instructions.

[0117] The memory 502 is configured to execute the computer execution instructions stored in the memory, to implement each step involved in the method embodiments. For details, refer to the related description in the foregoing method embodiments.

[0118] ​Optionally, the memory 502 can be independent or integrated with the processor 501.

[0119] When the memory 502 is independently arranged, the system further includes a bus 503 for connecting the memory 502 and the processor 501.

[0120] The embodiment of the application further provides a computer readable storage medium, and the computer readable storage medium stores computer execution instructions. When the processor executes the computer execution instructions, the method provided in the above method embodiment is implemented.

[0121] The embodiment of the application further provides a computer program product, which includes a computer program. When the computer program is executed by the processor, the method provided in the above method embodiment is implemented.

[0122] In several embodiments provided in the application, it should be understood that the disclosed apparatus and method can be implemented by other manners. For example, the apparatus embodiment described above is only illustrative. For example, the division of the above modules is only a logical function division. In actual implementation, another division manner can be used. For example, multiple modules can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed modules can be indirect coupling or communication connection through some interfaces, apparatuses or modules, which can be electrical, mechanical or other forms.

[0123] The modules described above as separate components can or can not be physically separated, and the components displayed as modules can or can not be physical units, that is, can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected according to actual needs to implement the embodiment scheme.

[0124] In addition, the function modules in each embodiment of the application can be integrated in one processing unit, or each module can be physically present alone, or two or more modules can be integrated in one unit. The unit composed of the above modules can be realized in the form of hardware or in the form of hardware plus software function unit.

[0125] The integrated modules realized in the form of software function modules can be stored in a computer readable storage medium. The software function modules stored in the storage medium include a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute part of steps of the method of each embodiment of the application.

[0126] It should be appreciated that the above-mentioned processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in combination with the application can be directly embodied as hardware processor execution, or executed by a combination of hardware and software modules in the processor.

[0127] The memory can include a high-speed RAM memory, and can also include a non-volatile storage NVM, such as at least one disk memory, and can also be a U disk, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk, etc.

[0128] The bus can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, the bus in the drawings of the present application does not limit to only one bus or one type of bus.

[0129] The above-mentioned storage medium can be realized by any type of volatile or non-volatile storage device or their combination, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0130] An exemplary storage medium is coupled to the processor, so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the storage medium can also exist as separate components in an electronic device or a host device.

[0131] Those skilled in the art can understand that all or part of the steps of the above-mentioned method embodiments can be completed by program instruction related hardware. The foregoing program can be stored in a computer readable storage medium. The program executes to perform the steps of the above-mentioned method embodiments; and the foregoing storage medium includes various storage media that can store program codes, such as ROM, RAM, magnetic disk or optical disk.

[0132] The technical solutions of the present application are described above, but not limited to them; although the present application is described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some or all of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A data consistency guarantee method based on an Android system, characterized in that, The method comprises the following steps: acquiring to-be-processed application-level transaction data and a pre-established log mapping table, wherein the pre-established log mapping table comprises a correspondence between application-level transactions and page data in a flash translation layer, and the pre-established log mapping table is data stored in a spin torque memory of the flash translation layer; determining, according to the correspondence between the application-level transactions and the page data in the flash translation layer, page data corresponding to the to-be-processed application-level transaction data in the flash translation layer, wherein the page data corresponding to the to-be-processed application-level transaction data comprises a transaction unique identifier, a transaction state identifier and a flash translation layer page; if it is determined that the transaction state identifier is the same as a preset uncommitted transaction state identifier, performing a lookup operation on the flash translation layer page according to the to-be-processed application-level transaction data to obtain a flash translation layer page corresponding to a transaction unique identifier satisfying a preset condition; performing a data rollback operation on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the pre-established log mapping table to obtain consistent application-level transaction data and a target log mapping table.

2. The method of claim 1, wherein, The step of determining, according to the correspondence between the application-level transactions and the page data in the flash translation layer, page data corresponding to the to-be-processed application-level transaction data in the flash translation layer comprises the following steps: determining, according to the to-be-processed application-level transaction data, a transaction unique identifier of the to-be-processed application-level transaction; performing identifier matching processing on the transaction unique identifiers in the pre-established log mapping table according to the transaction unique identifier of the to-be-processed application-level transaction to obtain a to-be-processed transaction unique identifier in the pre-established log mapping table which is the same as the transaction unique identifier of the to-be-processed application-level transaction; determining, according to the to-be-processed transaction unique identifier, a transaction state identifier and a flash translation layer page corresponding to each to-be-processed transaction unique identifier; storing the transaction unique identifier, the transaction state identifier and the flash translation layer page in the pre-established log mapping table as page data.

3. The method of claim 1, wherein, The to-be-processed application-level transaction data comprises page logical block number data and logical page offset data. Accordingly, the step of performing a lookup operation on the flash translation layer page according to the to-be-processed application-level transaction data to obtain a flash translation layer page corresponding to a transaction unique identifier satisfying a preset condition comprises the following steps: determining, according to the logical block number data, physical block number data in the pre-established log mapping table; determining, according to the logical page offset data, physical page offset data in the pre-established log mapping table; determining, according to the physical block number data and the physical page offset data, a physical address of the flash translation layer page; determining, according to the physical address of the flash translation layer page, a flash translation layer page corresponding to to-be-processed transaction data; if it is determined that the transaction unique identifier of the transaction data satisfies a preset condition, obtaining, from the flash translation layer page corresponding to the to-be-processed transaction data, a flash translation layer page corresponding to a transaction unique identifier satisfying the preset condition.

4. The method of claim 1, wherein, The pre-established log mapping table comprises value range data delimited by two primitive operations. Correspondingly, the data rollback operation is performed on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the pre-established log mapping table, to obtain consistent application-level transaction data and a target log mapping table, including: According to the value range data, the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition is sorted to determine data recovery sequence information; According to the data recovery sequence information, the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition is recovered to obtain consistent application-level transaction data; According to the data recovery sequence information, the pre-established log mapping table is updated to obtain a target log mapping table.

5. The method of claim 4, wherein, The updating of the pre-established log mapping table includes: The pre-established log mapping table is updated in the spin torque memory of the flash translation layer.

6. The method according to any one of claims 1 to 5, characterized in that, After determining the page data in the flash translation layer corresponding to the to-be-processed application-level transaction data according to the correspondence between the application-level transaction and the page data in the flash translation layer, the method further includes: If it is determined that the transaction state identifier is different from a preset uncommitted transaction state identifier, an operation cancellation command is obtained; According to the operation cancellation command, the to-be-processed application-level transaction data is stored as consistent application-level transaction data.

7. An Android system-based data consistency guaranteeing apparatus, characterized by comprising: It includes: A data acquisition module is configured to acquire to-be-processed application-level transaction data and a pre-established log mapping table, wherein the pre-established log mapping table includes a correspondence between an application-level transaction and page data in a flash translation layer, and the pre-established log mapping table is data stored in a spin torque memory of the flash translation layer; A first data searching module is configured to determine page data in the flash translation layer corresponding to the to-be-processed application-level transaction data according to the correspondence between the application-level transaction and the page data in the flash translation layer, wherein the page data corresponding to the to-be-processed application-level transaction data includes a transaction unique identifier, a transaction state identifier, and a flash translation layer page; A second data searching module is configured to, if it is determined that the transaction state identifier is the same as a preset uncommitted transaction state identifier, search the flash translation layer page according to the to-be-processed application-level transaction data to obtain a flash translation layer page corresponding to a transaction unique identifier satisfying a preset condition; A data consistency updating module is configured to perform a data rollback operation on the flash translation layer page corresponding to the transaction unique identifier satisfying the preset condition according to the pre-established log mapping table, to obtain consistent application-level transaction data and a target log mapping table.

8. An Android system-based data consistency guarantee system, characterized in that, It includes: At least one processor and a memory; The memory stores computer execution instructions; The at least one processor executes the computer execution instructions stored in the memory, so that the at least one processor executes the method in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer execution instruction, and when the processor executes the computer execution instruction, the method in any one of claims 1 to 6 is realized.

10. A computer program product, characterised in that, A computer program comprising computer program elements which, when executed by a processor, carry out the method according to any one of claims 1 to 6. A computer program comprising computer program elements which, when executed by a processor, carry out the method according to any one of claims 1 to

Images