CN115145942B - Distributed database system and method and device for realizing monotonous reading of distributed database system - Google Patents
Distributed database system and method and device for realizing monotonous reading of distributed database system Download PDFInfo
- Publication number
- CN115145942B CN115145942B CN202211081162.3A CN202211081162A CN115145942B CN 115145942 B CN115145942 B CN 115145942B CN 202211081162 A CN202211081162 A CN 202211081162A CN 115145942 B CN115145942 B CN 115145942B
- Authority
- CN
- China
- Prior art keywords
- version number
- node
- version
- duration
- target
- 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
- 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/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2329—Optimistic concurrency control using versioning
-
- 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/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/273—Asynchronous replication or reconciliation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The present specification provides a distributed database system and a method and a device for implementing monotonic reading thereof, wherein the system comprises a version service node and a common node, the version service node and the common node respectively maintain copies corresponding to the same data, wherein: the version service node is used for generating a monotonically increasing version number and the complete valid duration of the version number for the data according to a preset period; the common node is configured to: sending a version number acquisition request to the version service node in any period to acquire a target version number generated in any period and the residual effective duration of the target version number; and determining the failure time of the target version number on the common node according to the remaining effective duration of the target version number, and responding to a read request initiated by an access party for the data based on the data corresponding to the target version number before the determined failure time.
Description
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a distributed database system and a method and an apparatus for implementing monotonic reading thereof.
Background
Data replication is an important mechanism in a distributed database system for writing the same data in duplicate to multiple nodes in the distributed database system. Data replication may improve system availability and prevent a single node from hanging up and causing service termination. Among multiple copies of the same data, there is inevitably a data consistency problem, that is, after the data of one copy is updated, other copies must be kept synchronized, otherwise, a service problem may occur.
In the related art, the data inconsistency problem is avoided by proposing a consistency model for a distributed database system. The monotone reading is a consistency model defined for a client angle, and the monotone reading consistency model restricts that data read by the client each time cannot be older than data read before, namely the data read by the client is newer and newer. The new and old data can be judged by the version number, so that the monotonous reading rule in the related technology is as follows: the method comprises the steps that a fixed node in the distributed database system generates a monotonically increasing version number, and each node in the distributed database system inquires the fixed node in real time and obtains the latest version number when receiving a read request of a client, so that the client is ensured not to read data older than before.
However, the above scheme is likely to become a performance bottleneck of the system due to various reasons such as expansion of the system scale and increase of the number of read requests, and thus limits further expansion of the distributed database system, and on the other hand, since other nodes need to access the fixed node in real time to obtain the version number, the received read requests cannot be directly responded, and even a response delay of a second level may be generated under the condition of cross-regional deployment, which seriously affects user experience.
Disclosure of Invention
In order to overcome the problems in the related art, the present specification provides a method and an apparatus for implementing monotonic reading based on a distributed database system.
According to a first aspect of embodiments of the present specification, there is provided a distributed database system, including a version service node and a common node, where the version service node and the common node maintain copies corresponding to the same data, respectively, where:
the version service node is used for generating a version number which is monotonically increased and a complete valid duration of the version number for the data according to a preset period, wherein the complete valid duration is not greater than the period duration of the preset period;
the common node is configured to:
sending a version number acquisition request to the version service node in any period to acquire a target version number generated in any period and the residual effective duration of the target version number, wherein the residual effective duration is the difference between the complete effective duration of the target version number and the effective duration of the target version number on the version service node; and the number of the first and second groups,
determining the failure time of the target version number on the common node according to the remaining effective duration of the target version number, and responding to a read request initiated by an access party for the data based on the data corresponding to the target version number before the determined failure time; and the failure time of the target version number on the common node is not later than the failure time on the version service node.
According to a second aspect of the embodiments of the present specification, there is provided a method for implementing monotonic reading based on a distributed database system, where the distributed database system includes a version service node and a common node, and the version service node and the common node maintain copies corresponding to the same data respectively and are applied to the version service node, where the method includes:
generating a version number which is monotonically increased and a complete effective duration of the version number for the data according to a preset period, wherein the complete effective duration is not more than the period duration of the preset period;
responding to a version number acquisition request sent by the ordinary node in any period, sending a target version number generated in any period and the residual valid duration of the target version number to the ordinary node, so that the ordinary node determines the failure time of the target version number on the ordinary node according to the residual valid duration of the target version number, and responding to a read request initiated by an access party for the data based on the data corresponding to the target version number before the determined failure time; the failure time of the target version number on the common node is not later than the failure time on the version service node, and the remaining valid duration is the difference between the complete valid duration of the target version number and the valid duration of the target version number on the version service node.
According to a third aspect of the embodiments of the present specification, a method for implementing monotonic reading based on a distributed database system is provided, where the distributed database system includes a version service node and a common node, the version service node and the common node maintain copies corresponding to the same data, and the version service node maintains a version number that monotonically increases and a complete validity duration of the version number that are generated for the data according to a preset period, and the complete validity duration is not greater than a period duration of the preset period, and is applied to the common node, where the method includes:
sending a version number acquisition request to the version service node in any period to acquire a target version number generated in any period and the residual effective duration of the target version number, wherein the residual effective duration is the difference between the complete effective duration of the target version number and the effective duration of the target version number on the version service node;
determining the failure time of the target version number on the common node according to the remaining effective duration of the target version number, and responding to a read request initiated by an access party for the data based on the data corresponding to the target version number before the determined failure time; and the failure time of the target version number on the common node is not later than the failure time on the version service node.
According to a fourth aspect of the embodiments of the present specification, there is provided an apparatus for implementing monotonic reading based on a distributed database system, where the distributed database system includes a version service node and a common node, and the version service node and the common node respectively maintain copies corresponding to the same data, and are applied to the version service node, the apparatus includes:
the generating unit is used for generating a version number which monotonically increases and a complete effective duration of the version number for the data according to a preset period, wherein the complete effective duration is not greater than the period duration of the preset period;
a sending unit, configured to send, in response to a version number acquisition request sent by the common node in any period, a target version number generated in any period and a remaining valid duration of the target version number to the common node, so that the common node determines, according to the remaining valid duration of the target version number, a failure time of the target version number on the common node, and responds, before the determined failure time, to a read request initiated by an access party for the data based on data corresponding to the target version number; the failure time of the target version number on the common node is not later than the failure time on the version service node, and the remaining valid duration is the difference between the complete valid duration of the target version number and the valid duration of the target version number on the version service node.
According to a fifth aspect of the embodiments of the present specification, there is provided a device for implementing monotonic reading based on a distributed database system, where the distributed database system includes a version service node and a common node, the version service node and the common node respectively maintain copies corresponding to the same data, the version service node maintains a version number that monotonically increases and a complete validity duration of the version number, which are generated for the data according to a preset period, and the complete validity duration is not greater than a period duration of the preset period, and is applied to the common node, where the device includes:
a request sending unit, configured to send a version number obtaining request to the version service node in any cycle to obtain a target version number generated in the any cycle and a remaining valid duration of the target version number, where the remaining valid duration is a difference between a complete valid duration of the target version number and an effective duration of the target version number on the version service node;
a determining unit, configured to determine, according to a remaining valid duration of the target version number, a failure time of the target version number on the common node, and respond to, before the determined failure time, a read request initiated by an access party for the data based on the data corresponding to the target version number; and the failure time of the target version number on the common node is not later than the failure time on the version service node.
According to a sixth aspect of embodiments herein, there is provided an electronic apparatus comprising:
a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the steps of the method of the second or third aspect.
According to a seventh aspect of embodiments herein, there is provided a computer-readable storage medium having stored thereon executable instructions; wherein the instructions, when executed by the processor, implement the steps of the method of the second or third aspect.
Through the technical scheme provided by the specification, the following beneficial effects can be realized:
after receiving the read request, the ordinary node described in this specification does not need to send a corresponding version number acquisition request to the version service node in real time, but preferentially responds to the read request by using a version number that is acquired from the version service node in advance and maintained locally, thereby sharing and relieving the pressure of the version service node, and satisfying the further expansion of the distributed database system. Meanwhile, under the condition that the version number maintained by the common node is still valid, the common node can directly respond to the read request based on the locally maintained version number, so that the interaction step with the version service node is omitted, the response time of the read request can be effectively shortened, and the user experience is improved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the specification.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present specification and together with the description, serve to explain the principles of the specification.
FIG. 1 is an architectural diagram of a distributed database system provided by an exemplary embodiment of the present description;
FIG. 2 is a flow chart of a method for implementing monotonic read based on a distributed database system provided by an exemplary embodiment of the present specification;
FIG. 3 is a schematic diagram illustrating an interaction between a version service node and a normal node according to an exemplary embodiment of the present specification;
FIG. 4 is a schematic diagram of determining a failure time provided by an exemplary embodiment of the present description;
FIG. 5 is a schematic illustration of another determination of a time to failure provided by an exemplary embodiment of the present description;
FIG. 6 is a flowchart of a method for implementing a monotonic read based distributed database system provided by an exemplary embodiment of the present specification;
FIG. 7 is a schematic block diagram of an electronic device provided in an exemplary embodiment of the present description;
FIG. 8 is a block diagram of an apparatus for implementing monotonic read based on a distributed database system provided by an exemplary embodiment of the present specification;
fig. 9 is a block diagram of an apparatus for implementing monotonic read based on a distributed database system according to an exemplary embodiment of the present specification.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
In the related technology, a monotone reading consistency model can be adopted to avoid the problem of data inconsistency, the monotone reading consistency model restricts that data read by a client each time cannot be older than data read before, namely the data read by the client is newer and newer, the new and the old of the data can be specifically judged through a version number, for example, the initial version number of data A is 1, and then the corresponding version number can be 2 after the data A is updated once, so that the new and the old of the data can be distinguished through the numerical value of the version number. After the version number is specifically introduced, the constraint condition of the corresponding monotonic read consistency model can be understood as follows: after the client reads the data with the version number of 1, the client can only read the data with the version number greater than or equal to 1. In order to implement the constraint condition of the monotonic reading consistency model, a monotonically increasing version number can be generated by a fixed node in a distributed database system, each node in the system can inquire the fixed node in real time and acquire the latest version number when receiving a reading request sent by an access party, and because the version number generated by the fixed node is monotonically increasing, the version number acquired by any node is also monotonically increasing, data read by a client each time is not older than data read before, and the constraint condition of the monotonic reading consistency model is satisfied.
However, in the above solution, each node needs to send a version number obtaining request to the fixed node in real time as long as it receives a read request, for example, if a certain node receives 100 read requests sent by an accessing party in 10 seconds, the node sends 100 version number obtaining requests to the fixed node in real time. However, the fixed node is a single node, the load capacity of the fixed node is limited, and with the expansion of the system scale and the increase of the number of read requests, the limited load capacity of the fixed node also becomes a performance bottleneck of the system, so that the further expansion of the distributed database system is limited, and even the fixed node is down; meanwhile, each node needs to access the fixed node in real time to obtain the version number, so that the received read request cannot be directly responded, and even second-level response delay can be generated under the condition of cross-region deployment, thereby seriously affecting the user experience.
Therefore, to solve the above problem, the present specification proposes an improved implementation of monotonic reading of a distributed database, which is described in detail below with reference to the embodiments.
Fig. 1 is a schematic architecture diagram of a distributed database system according to an exemplary embodiment of the present disclosure. As shown in fig. 1, the system architecture may include a version service node 10 and a plurality of common nodes (e.g., a common node 11, a common node 12, and a common node 13).
The version service node 10 may be deployed in a physical server including an independent host, or the version service node 10 may be deployed in a virtual server (e.g., a cloud server) carried by a host cluster, which is not limited in this specification. When the version service node 10 is deployed in a virtual server carried by a host cluster, the version service node 10 may be formed by multiple physical servers of independent hosts, so that even if a physical server of one of the independent hosts fails, the remaining normal physical servers may still be used to provide services to the outside, thereby ensuring high availability of the version service node 10. Because the version service node 10 needs to continuously generate the monotonically increasing version number, the version service node 10 may be a node that is determined based on a preset master selection scheme and is highly available in the system, so as to ensure that the version service node can meet the requirement of continuously generating the monotonically increasing version number. It should be noted that the present specification does not limit the form of the specific master scenario, and for example, a certain node with the largest memory capacity in the system may be used as the version service node, a certain node with the highest priority in the system may be used as the version service node, and a certain node with the largest node ID in the system may be used as the version service node. Of course, assuming that the version service node 10 is borne by the host cluster, the corresponding master selection scheme may also be adjusted appropriately, for example, three nodes with top-ranked memory capacities in the system are selected as the version service node. The deployment environment of the common node 11 may be the same as that of the version service node, and is not described herein again. The version service node 10 is configured to generate a monotonically increasing version number and a full validity duration of the version number for the data according to a preset period, where the full validity duration is not greater than a period duration of the preset period. Different from the situation that a fixed node generates a monotonically increasing version number in the prior art, the description sets a complete valid duration for the periodically generated monotonically increasing version number, and based on the setting of the valid duration, on one hand, constraint conditions of a monotonic read consistency model are met, and on the other hand, it is possible for a common node to directly respond to a read request.
The common node 11 is configured to send a version number obtaining request to the version service node 10 in any cycle to obtain a target version number generated in the any cycle and a remaining valid duration of the target version number, where the remaining valid duration is a difference between a complete valid duration of the target version number and an effective duration of the target version number on the version service node; determining the failure time of the target version number on the common node 11 according to the remaining effective duration of the target version number, and responding to a read request initiated by an access party for the data based on the data corresponding to the target version number before the determined failure time; and the failure time of the target version number on the common node is not later than the failure time on the version service node. After receiving the read request, as long as the target version number maintained locally by the ordinary node 11 is not invalid, the ordinary node 11 may directly respond to the read request based on the invalidity version number, and it is no longer necessary to send a version number acquisition request to the version service node in real time, so that the pressure of the version service node is shared and reduced, and further expansion of the distributed database system can be satisfied. Meanwhile, under the condition that the version number maintained by the common node is still valid, the common node can directly respond to the read request based on the locally maintained version number, so that the interaction step with the version service node is omitted, the response time of the read request can be effectively reduced, and the user experience is improved. The common node 12, the common node 13 and the common node 11 belong to the same type of node, so reference may be made to the above description for the common node 12 and the common node 13, and the description is not repeated herein.
Based on the system architecture corresponding to the distributed database system, the common node periodically acquires the version number from the version service node and maintains the version number locally, so that the common node can directly respond to the read request after receiving the read request without acquiring the version number from the version service node in real time, the pressure of the version service node is reduced, the response time of the read request is effectively reduced, and the user experience is improved.
Fig. 2 is a flowchart of a monotone reading implementation method based on a distributed database system according to an exemplary embodiment of the present specification, where the distributed database system may include a version service node and a common node, and the version service node and the common node respectively maintain copies corresponding to the same data, and the implementation method is applied to the version service node, and specifically includes the following steps:
step 202, generating a monotonically increasing version number and a complete validity duration of the version number for the data according to a preset period, wherein the complete validity duration is not greater than the period duration of the preset period.
The version service node can generate a monotonically increasing version number for the data according to a preset period, wherein the data can refer to a certain data table in the database, that is, each data table in the database can correspond to a version number; or the data may also refer to a certain row of data in the data table, that is, each row of data of the data table corresponds to a version number; the data may also refer to a copy maintained by the node, i.e. the entire copy of the node corresponds to a version number. Therefore, the specific form of the data corresponding to the version number may be divided according to actual requirements, and this specification does not limit this.
As mentioned above, the version number is used to distinguish between old and new data, and generally, old data may correspond to a version number with a smaller value, and data updated based on the old data may correspond to a version number with a larger value, so that the old and new degrees of data can be visually distinguished. For example, if the version number of data a is N, after data a is updated once, the version number of updated data a may be N +1, where N may be an integer greater than zero. From this, the constraints of the monotonic read consistency model can be understood: that is, after the client reads the data a with the version number N, the version number corresponding to the data a read by the client is only greater than or equal to N, so as to avoid the phenomenon of 'time-light backtracking' of the client. So, from the role of version number, it is only used to distinguish between old and new data, and the concrete representation of which version number monotonically increases may be various, for example: the version number may be monotonically increasing number-based, i.e. in the form of 1, 2, 3, 4; the version number may also be monotonically increasing based on greek letters, i.e. in the form of α, β, γ, δ; the version number may also be monotonically increasing based on the number of bits, i.e., in the form of 1, 1-1-1-1, and the specification does not limit the specific representation form in which the version number monotonically increases.
The period duration of the preset period may be determined based on actual demand, and for example, the period duration may be 100ms or 1s. The full validity duration of the version number should not be greater than the cycle duration of the preset cycle, for example, when the cycle duration is 100ms, the full validity duration corresponding to the version number may be 80ms. Otherwise, if the complete validity duration of the version number is greater than the cycle duration of the preset cycle, a situation in which multiple valid version numbers exist in the same time period may occur. Certainly, in order to avoid the occurrence of the blank window time, that is, assuming that the complete valid duration of the version number is 80ms and the cycle duration is 100ms, there is a blank window time of 20ms, at this time, the complete valid duration of the version number may be the same as the cycle duration, that is, assuming that the cycle duration is 100ms, the corresponding complete valid duration of the version number is 100ms, thereby ensuring that the version service node has a corresponding unique valid version number at any time.
In an embodiment, the version service node may generate the version number of the current cycle by: under the condition that data change occurs in the previous period, the version service node takes the version number corresponding to the latest data change as the version number generated in the current period; or, in the case that no data change occurs in the previous cycle, the version service node takes the version number generated in the previous cycle as the version number generated in the current cycle. For example, if data change occurs in the previous cycle, data a has changed 3 times, and the version number of the beginning of data a is 0, the corresponding version numbers after change may be 1, 2, and 3 in time order, respectively, and the version service node may use the version number 3 corresponding to the latest data change as the version number generated in the current cycle. On the other hand, if no data change occurs in the previous cycle, the version service node may directly use the version number 0 as the version number generated in the current cycle.
After receiving a version number acquisition request sent by a common node, a version service node may send a target version number generated in any period and the remaining valid duration of the target version number to the common node, as shown in fig. 3, at time T0, the version service node generates a corresponding version number in a current period, assuming that the version number is 3, and the complete valid duration of the version number is 100ms, which is equal to the period duration of a preset period (i.e., the version number is generated once every 100 ms). The ordinary node sends a version number obtaining request to the version service node at the time of T1, the version service node receives the version number obtaining request sent by the ordinary node at the time of T2, at this time, the version service node can calculate the remaining effective duration, the remaining effective duration can be the difference between the complete effective duration and the effective duration of the version number on the version service node, namely the difference between T5 and T2 can be regarded as the remaining effective duration. Therefore, after receiving the version number obtaining request, the version service node may send a corresponding version number (i.e., version number 3) and a remaining validity duration (T5-T2) corresponding to the version number 3 to the ordinary node, and after receiving the version number at the time of T3, the ordinary node may determine, based on the remaining validity duration (T5-T2), a failure time of the version number on the ordinary node, where the failure time is T4, and before the determined failure time, the ordinary node may respond to the read request initiated by the access party for the data based on the version number 3, in other words, as long as the access party initiates the read request for the data to the ordinary node within the time periods of T3 and T4, the ordinary node may respond to the read request based on the maintained version number (version number 3) directly, so that it is no longer necessary to send the version number obtaining request to the version service node in real time for each read request. Moreover, because the time T4 is not later than the time T5, the monotonous characteristic of the version number can be ensured no matter the access direction is to the version service node or the access direction is to the common node to obtain the version number. For example, if the failure time T5 of the version service node is earlier than the failure time T4 of the common node, the visitor acquires the version number of 4 through the version service node (because the version number of 3 is expired), and then acquires the version number of 3 through the common node (because T4 is later than T5), then a phenomenon occurs that the version number currently acquired by the visitor is smaller than the version number acquired before, that is, "time light backtracking" as described above. Therefore, the time T4 is required to be not later than the time T5, that is, the time T4 is earlier than or equal to the time T5, so as to satisfy the constraint condition of the client monotonic reading consistency model.
In an embodiment, in order to ensure that the time T4 shown in fig. 3 is not later than the time T5, that is, the time of failure of the target version number on the ordinary node is not later than the time of failure on the version service node, the ordinary node may specifically determine the time of failure of the target version number on the ordinary node by: and on the basis of the sending time of the version number acquisition request, increasing the residual effective duration of the target version number, and determining the obtained time as the failure time of the target version number on the common node. As shown in fig. 4, based on the version number obtaining request being sent, the corresponding remaining valid duration is added, that is, the remaining valid duration is added based on T1, and the remaining valid duration is determined by the version service node according to the time difference between T5 and T2, and based on the above determining manner, the access party can satisfy the monotonicity of the version number no matter obtains the version number from the version service node or obtains the version number from the common node; further, since the time of failure is determined based on the relative time of the normal node itself, not the absolute time, monotonicity of the version number can be satisfied even if the times of the normal nodes are not uniform.
The common node may associate all version numbers and corresponding failure times of each version number on the common node obtained by the cache locally, so that after receiving a read request initiated by an accessing party for the data, the common node may query the version number of the local cache and the corresponding failure time on the common node; if any version number of the local cache does not arrive at the corresponding failure time on the common node, responding to the received read request based on any version number; and if all the version numbers of the local cache arrive at the corresponding failure time on the common node, temporarily requesting a new version number from the version service node for responding to the received read request. For example, if the accessing party initiates a data read request to the common node within a time period from T3 to T4 shown in fig. 3, the common node may directly respond to the received read request according to the cached version number 3 (because the version number 3 has not yet failed), and of course, if the data corresponding to the version number 3 is not synchronized to the common node at this time, the data corresponding to the version number may be fed back to the accessing party after the data synchronization is completed. If the data corresponding to the version number 3 is synchronized to the common node at this time, the common node may directly feed back the data corresponding to the version number to the access party. Because the common node can obtain all version numbers in the local associated cache and the corresponding failure time of each version number on the common node, all the common nodes can directly feed back to the access party based on the version numbers of the local cache, the version number obtaining request does not need to be sent to the version service node in real time aiming at each read request, the pressure of the version service node is shared, and the load of the version service node is reduced. Meanwhile, the response time of the read request is reduced, and the user experience is improved. If all the version numbers of the local cache arrive at the corresponding failure time on the common node, a new version number is temporarily requested from the version service node to respond to the received read request, for example, it is assumed that the read request initiated by the access party is received after the time T4 shown in fig. 3, and after the time T4, the version number locally maintained by the common node is expired, so that the common node can temporarily request the new version number from the version service node, thereby ensuring the monotonic characteristic of the version number and satisfying the constraint condition of the client consistency model. Of course, in order to optimize the cache space of the common node, if any version number has failed on the common node, the common node may delete the associated cache relationship in the cache space, that is, delete the failed version number and the failure time corresponding to the version number.
As described in the embodiment shown in fig. 1, the version service node may be formed by a plurality of nodes, so as to avoid the hidden danger of service stop that only a single node is selected as the version service node, and improve the reliability of the version service node. However, even if several nodes are selected, the possibility that several nodes simultaneously have abnormality still exists, and at this time, any node satisfying the high availability condition in the common nodes can take over the version service node with the abnormality, so that the phenomenon of service stop is avoided. That is, when the version service node is changed from the first node to the second node in the distributed database system, after all the version numbers generated by the first node have failed, the second node replaces the first node to generate a monotonically increasing version number and the complete validity duration of the version number for the data according to the preset period, so that the distributed database system can still generate the monotonically increasing version number, and normal service of the system is ensured.
However, after the second node replaces the first node, it may happen that the normal node maintains a plurality of version numbers in the valid state at the same time, for example, the normal node maintains a version number 3 generated by the first node and still in the valid state, and when the version number 3 does not fail, the second node replaces the first node and immediately generates a version number 4, and then the normal node may maintain the version number 3 and the version number 4 in the valid state at the same time, which may cause a phenomenon of version number disorder. Therefore, in order to avoid the above-mentioned phenomenon of version number disorder, the second node may take over to generate a version number that is monotonically increased after all version numbers generated by the first node have failed. And the second node can determine that all version numbers generated by the first node have failed in the following two ways: the second node may determine that all version numbers generated by the first node have failed after waiting for a period duration of at least one preset period; or, under the condition that the latest version number generated by the first node in the current period is not expired, adding the remaining effective duration corresponding to the latest version number on the basis of the receiving time of the second node for the latest version number, and determining the obtained time as the failure time of all the version numbers generated by the first node. For example, assuming that the first node generates the version number every 100ms, the second node may wait for at least one preset period of 100ms to determine that all version numbers generated by the first node have failed. Or, as shown in fig. 5, after an exception occurs in the first node, the second node replaces the first node with the first node, and at this time, the second node may add the remaining validity duration corresponding to the latest version number, that is, T4', to the reception time T3' of the latest version number, so as to determine that all version numbers generated by the first node have failed.
Fig. 6 is a flowchart of a method for implementing monotonic reading of a distributed database system provided in an exemplary embodiment of the present specification, where the distributed database system includes a version service node and a common node, the version service node and the common node respectively maintain copies corresponding to the same data, the version service node maintains a version number that monotonically increases and a complete validity duration of the version number, which are generated for the data according to a preset period, and the complete validity duration is not greater than a period duration of the preset period, and is applied to the common node, where the method specifically includes the following steps:
step 602, sending a version number obtaining request to the version service node in any period to obtain a target version number generated in any period and a remaining valid duration of the target version number, where the remaining valid duration is a difference between a complete valid duration of the target version number and an effective duration of the target version number on the version service node.
In an embodiment, the common node may associate all version numbers acquired by the cache locally and the corresponding failure time of each version number on the common node, so that after receiving a read request initiated by an accessing party for the data, the common node may query the version numbers of the local cache and the corresponding failure time on the common node; if any version number of the local cache does not reach the corresponding failure time on the common node, responding to the received read request based on any version number; if all the version numbers of the local cache have arrived at the corresponding failure time on the common node, the common node may temporarily request a new version number from the version service node for responding to the received read request. All the common nodes can directly respond to the read request based on the version number of the local cache of the common nodes, the version number acquisition request does not need to be sent to the version service node in real time aiming at each read request, the pressure of the version service node is shared, and the common nodes can directly respond to the read request, so that the step of interaction with the version service node is omitted, the response time of the read request is shortened, and the user experience is improved.
The common node may determine the failure time by increasing the remaining effective duration of the target version number based on the sending time of the version number obtaining request, and determining the obtained time as the failure time of the target version number on the common node, thereby ensuring the constraint condition of the client monotonously reading the consistency model.
In an embodiment, when the version service node is changed from a first node to a second node in the distributed database system, after all version numbers generated by the first node have failed, the second node replaces the first node to generate a monotonically increasing version number and a complete validity duration of the version number for the data according to the preset period. The second node may determine that all version numbers generated by the first node have failed by any one of the following methods: after waiting for the period duration of at least one preset period, the second node determines that all version numbers generated by the first node are invalid; or, under the condition that the latest version number generated by the first node in the current period is not expired, the remaining effective duration corresponding to the latest version number is increased on the basis of the receiving time of the second node for the latest version number, and the obtained time is determined as the failure time of all the version numbers generated by the first node, so that the disorder of the version numbers caused by the fact that a plurality of version numbers still in an effective state exist in a common node at the same time can be avoided.
The present specification also provides embodiments of an apparatus, an electronic device, and a storage medium, corresponding to embodiments of the foregoing method.
Fig. 7 is a schematic block diagram of an electronic device according to an exemplary embodiment. Referring to fig. 7, at the hardware level, the apparatus includes a processor 701, a network interface 702, a memory 703, a non-volatile memory 704, and an internal bus 705, but may also include hardware required for other services. One or more embodiments of the present description may be implemented on a software basis, such as by processor 701 reading a corresponding computer program from non-volatile storage 704 into memory 703 and then running. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
FIG. 8 is a block diagram of an apparatus for implementing monotonic read based on a distributed database system in accordance with an exemplary embodiment. Referring to fig. 8, the distributed database system includes a version service node and a common node, where the version service node and the common node respectively maintain copies corresponding to the same data, and are applied to the version service node, and the apparatus includes:
a generating unit 802, configured to generate a monotonically increasing version number and a complete validity duration of the version number for the data according to a preset period, where the complete validity duration is not greater than a period duration of the preset period.
A sending unit 804, configured to send, in response to a version number obtaining request sent by the ordinary node in any cycle, a target version number generated in any cycle and a remaining valid duration of the target version number to the ordinary node, so that the ordinary node determines, according to the remaining valid duration of the target version number, a failure time of the target version number on the ordinary node, and responds, before the determined failure time, to a read request initiated by an access party for the data based on data corresponding to the target version number; the failure time of the target version number on the common node is not later than the failure time on the version service node, and the remaining valid duration is the difference between the complete valid duration of the target version number and the valid duration of the target version number on the version service node.
Optionally, the generating unit 802 is specifically configured to:
under the condition that data change occurs in the previous period, the version service node takes the version number corresponding to the latest data change as the version number generated in the current period; or the like, or, alternatively,
and under the condition that the data change does not occur in the previous period, the version service node takes the version number generated in the previous period as the version number generated in the current period.
FIG. 9 is a block diagram of an apparatus for implementing monotonic read based on a distributed database system according to an exemplary embodiment. Referring to fig. 9, the version service node and the common node respectively maintain copies corresponding to the same data, and the version service node maintains a monotonically increasing version number generated for the data according to a preset period and a full validity duration of the version number, where the full validity duration is not greater than the period duration of the preset period, and is applied to the common node, where the apparatus includes:
a request sending unit 902, configured to send a version number obtaining request to the version service node in any cycle to obtain a target version number generated in the any cycle and a remaining valid duration of the target version number, where the remaining valid duration is a difference between a complete valid duration of the target version number and an effective duration of the target version number on the version service node;
a determining unit 904, configured to determine, according to the remaining valid duration of the target version number, a failure time of the target version number on the common node, and respond, before the determined failure time, to a read request initiated by an access party for the data based on the data corresponding to the target version number; and the failure time of the target version number on the common node is not later than the failure time on the version service node.
Optionally, the apparatus further includes:
a cache querying unit 906, configured to query, after receiving a read request initiated by an accessing party for the data, a version number of a local cache and a corresponding failure time of the local cache on the common node; if any version number of the local cache does not arrive at the corresponding failure time on the common node, responding to the received read request based on any version number; and if all the version numbers of the local cache arrive at the corresponding failure time on the common node, temporarily requesting a new version number from the version service node for responding to the received read request.
Optionally, the determining unit 904 is specifically configured to:
and on the basis of the sending time of the version number acquisition request, increasing the residual effective duration of the target version number, and determining the obtained time as the failure time of the target version number on the common node.
Optionally, in a case where the version service node is changed from a first node to a second node in the distributed database system, the apparatus further includes:
a replacing unit 908, configured to replace, by the second node, the first node with the first node according to the preset period to generate a monotonically increasing version number and a complete validity duration of the version number for the data after all version numbers generated by the first node have failed.
Optionally, the successor unit 908 is specifically configured to:
after waiting for the period duration of at least one preset period, the second node determines that all version numbers generated by the first node are invalid; or, when the latest version number generated by the first node in the current period is not expired, adding the remaining effective duration corresponding to the latest version number on the basis of the receiving time of the second node for the latest version number, and determining the obtained time as the failure time of all the version numbers generated by the first node.
Based on the monotonous reading implementation device based on the distributed database system, the common node can directly respond to the reading request after receiving the reading request through the version number periodically obtained from the version service node and locally maintained by the common node, the version number does not need to be obtained from the version service node in real time, the pressure of the version service node is relieved, the response time of the reading request is effectively reduced, and the user experience is improved.
For the device embodiment, since it basically corresponds to the method embodiment, reference may be made to the partial description of the method embodiment for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the modules described as separate components may or may not be physically separate, and the components displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement without inventive effort.
In a typical configuration, a computer 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 Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. 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 phrases "comprising one of 8230; \8230;" 8230; "does not exclude the presence of additional like elements in a process, method, article, or apparatus that comprises that element.
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the specification, as detailed in the appended claims.
The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present description. The word "if" as used herein may be interpreted as "at" \8230; "or" when 8230; \8230; "or" in response to a determination ", depending on the context.
The above description is only a preferred embodiment of the present disclosure, and should not be taken as limiting the present disclosure, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.
Claims (17)
1. A distributed database system comprises a version service node and a common node, wherein the version service node and the common node respectively maintain a copy corresponding to the same data, and the version service node and the common node respectively maintain a copy corresponding to the same data, wherein:
the version service node is used for generating a version number which is monotonically increased and a complete valid duration of the version number for the data according to a preset period, wherein the complete valid duration is not greater than the period duration of the preset period;
the common node is configured to:
sending a version number acquisition request to the version service node in any period to acquire a target version number generated in any period and the residual effective duration of the target version number, wherein the residual effective duration is the difference between the complete effective duration of the target version number and the effective duration of the target version number on the version service node; and (c) a second step of,
determining the failure time of the target version number on the common node according to the residual effective duration of the target version number, and responding to a read request initiated by an access party for the data based on the data corresponding to the target version number before the determined failure time; and the failure time of the target version number on the common node is not later than the failure time on the version service node.
2. The system according to claim 1, wherein the common node obtains all version numbers and corresponding failure time of each version number on the common node from a local associated cache; the generic node is further configured to:
after receiving a read request initiated by an access party for the data, inquiring the version number of a local cache and the corresponding failure time of the local cache on the common node;
if any version number of the local cache does not arrive at the corresponding failure time on the common node, responding to the received read request based on any version number;
and if all the version numbers of the local cache arrive at the corresponding failure time on the common node, temporarily requesting a new version number from the version service node for responding to the received read request.
3. The system of claim 1, wherein the determining, by the ordinary node, the failure time of the target version number on the ordinary node according to the remaining validity duration of the target version number comprises:
and on the basis of the sending time of the version number acquisition request, increasing the residual effective duration of the target version number, and determining the obtained time as the failure time of the target version number on the common node.
4. The system of claim 1, the version service node to generate a version number for a current cycle by:
under the condition that data change occurs in the previous period, the version service node takes the version number corresponding to the latest data change as the version number generated in the current period; or the like, or, alternatively,
and under the condition that no data change occurs in the previous period, the version service node takes the version number generated in the previous period as the version number generated in the current period.
5. The system of claim 1, wherein, in the event the version service node is changed from a first node to a second node in the distributed database system, the second node is configured to:
and after all the version numbers generated by the first node are invalid, replacing the first node to generate monotonically increasing version numbers and complete valid durations of the version numbers for the data according to the preset period.
6. The system of claim 5, the second node determining that all version numbers generated by the first node have failed by either:
after waiting for the period duration of at least one preset period, the second node determines that all version numbers generated by the first node are invalid; or the like, or, alternatively,
and under the condition that the latest version number generated by the first node in the current period is not expired, increasing the residual effective duration corresponding to the latest version number on the basis of the receiving time of the second node aiming at the latest version number, and determining the obtained time as the failure time of all the version numbers generated by the first node.
7. A method for realizing monotone reading based on a distributed database system comprises a version service node and a common node, wherein the version service node and the common node respectively maintain copies corresponding to the same data and are applied to the version service node, and the method comprises the following steps:
generating a version number which is monotonically increased and a complete effective duration of the version number for the data according to a preset period, wherein the complete effective duration is not more than the period duration of the preset period;
responding to a version number acquisition request sent by the ordinary node in any period, sending a target version number generated in any period and the residual valid duration of the target version number to the ordinary node, so that the ordinary node determines the failure time of the target version number on the ordinary node according to the residual valid duration of the target version number, and responding to a read request initiated by an access party for the data based on the data corresponding to the target version number before the determined failure time; the time of failure of the target version number on the common node is not later than the time of failure on the version service node, and the remaining effective duration is the difference between the complete effective duration of the target version number and the effective duration of the target version number on the version service node.
8. The method of claim 7, the version service node generating a version number for a current cycle by:
under the condition that data change occurs in the previous period, the version service node takes the version number corresponding to the latest data change as the version number generated in the current period; or the like, or, alternatively,
and under the condition that no data change occurs in the previous period, the version service node takes the version number generated in the previous period as the version number generated in the current period.
9. A method for realizing monotone reading based on a distributed database system comprises a version service node and a common node, wherein the version service node and the common node respectively maintain copies corresponding to the same data, the version service node maintains a version number which is generated for the data according to a preset period and is increased monotonously and a complete effective duration of the version number, the complete effective duration is not more than the period duration of the preset period, and the method is applied to the common node and comprises the following steps:
sending a version number acquisition request to the version service node in any period to acquire a target version number generated in any period and the residual effective duration of the target version number, wherein the residual effective duration is the difference between the complete effective duration of the target version number and the effective duration of the target version number on the version service node;
determining the failure time of the target version number on the common node according to the remaining effective duration of the target version number, and responding to a read request initiated by an access party for the data based on the data corresponding to the target version number before the determined failure time; and the failure time of the target version number on the common node is not later than the failure time on the version service node.
10. The method according to claim 9, wherein the common node obtains all version numbers and corresponding failure time of each version number on the common node from the local associated cache, and the method further comprises:
after receiving a read request initiated by an access party for the data, inquiring the version number of a local cache and the corresponding failure time of the local cache on the common node;
if any version number of the local cache does not arrive at the corresponding failure time on the common node, responding to the received read request based on any version number;
and if all the version numbers of the local cache arrive at the corresponding failure time on the common node, temporarily requesting a new version number from the version service node for responding to the received read request.
11. The method of claim 9, wherein determining the time of failure of the target version number on the common node according to the remaining validity duration of the target version number comprises:
and on the basis of the sending time of the version number acquisition request, increasing the residual effective duration of the target version number, and determining the obtained time as the failure time of the target version number on the common node.
12. The method of claim 9, in the event that the version service node is changed from a first node to a second node in the distributed database system, the method further comprising:
and after all the version numbers generated by the first node are invalid, replacing the first node by the second node to generate a version number which is monotonically increased and the complete valid duration of the version number for the data according to the preset period.
13. The method of claim 12, the second node determining that all version numbers generated by the first node have failed by either:
after waiting for the period duration of at least one preset period, the second node determines that all version numbers generated by the first node are invalid; or the like, or, alternatively,
and under the condition that the latest version number generated by the first node in the current period is not expired, increasing the residual effective duration corresponding to the latest version number on the basis of the receiving time of the second node aiming at the latest version number, and determining the obtained time as the failure time of all the version numbers generated by the first node.
14. An apparatus for implementing monotonic reading based on a distributed database system, wherein the distributed database system comprises a version service node and a common node, and the version service node and the common node respectively maintain copies corresponding to the same data and are applied to the version service node, the apparatus comprises:
the generating unit is used for generating a version number which is monotonically increased and the complete valid duration of the version number for the data according to a preset period, wherein the complete valid duration is not greater than the period duration of the preset period;
a sending unit, configured to send, in response to a version number acquisition request sent by the ordinary node in any cycle, a target version number generated in any cycle and a remaining valid duration of the target version number to the ordinary node, so that the ordinary node determines, according to the remaining valid duration of the target version number, a failure time of the target version number on the ordinary node, and responds, before the determined failure time, to a read request initiated by an access party for the data based on data corresponding to the target version number; the failure time of the target version number on the common node is not later than the failure time on the version service node, and the remaining valid duration is the difference between the complete valid duration of the target version number and the valid duration of the target version number on the version service node.
15. A monotone reading realization device based on a distributed database system, wherein the distributed database system comprises a version service node and a common node, the version service node and the common node respectively maintain copies corresponding to the same data, the version service node maintains a monotone increasing version number generated for the data according to a preset period and a complete effective duration of the version number, the complete effective duration is not more than the period duration of the preset period, and the device is applied to the common node and comprises:
a request sending unit, configured to send a version number obtaining request to the version service node in any cycle to obtain a target version number generated in the any cycle and a remaining valid duration of the target version number, where the remaining valid duration is a difference between a complete valid duration of the target version number and an effective duration of the target version number on the version service node;
a determining unit, configured to determine, according to a remaining valid duration of the target version number, a failure time of the target version number on the common node, and respond to, before the determined failure time, a read request initiated by an access party for the data based on the data corresponding to the target version number; and the failure time of the target version number on the common node is not later than the failure time on the version service node.
16. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 7 to 8 or 9 to 13.
17. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the method according to any one of claims 7 to 8 or 9 to 13 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211081162.3A CN115145942B (en) | 2022-09-05 | 2022-09-05 | Distributed database system and method and device for realizing monotonous reading of distributed database system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211081162.3A CN115145942B (en) | 2022-09-05 | 2022-09-05 | Distributed database system and method and device for realizing monotonous reading of distributed database system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115145942A CN115145942A (en) | 2022-10-04 |
| CN115145942B true CN115145942B (en) | 2023-01-17 |
Family
ID=83416390
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211081162.3A Active CN115145942B (en) | 2022-09-05 | 2022-09-05 | Distributed database system and method and device for realizing monotonous reading of distributed database system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115145942B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107733957A (en) * | 2016-08-12 | 2018-02-23 | 北京融聚世界网络科技有限公司 | Distributed Services configure system and version number's distribution method |
| CN109977171A (en) * | 2019-02-02 | 2019-07-05 | 中国人民大学 | A kind of distributed system and method guaranteeing transaction consistency and linear consistency |
| CN112559496A (en) * | 2020-12-24 | 2021-03-26 | 百果园技术(新加坡)有限公司 | Distributed database transaction atomicity realization method and device |
| CN112925763A (en) * | 2021-03-22 | 2021-06-08 | 河北工业大学 | Method for rapid persistence based on CAD |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8572031B2 (en) * | 2010-12-23 | 2013-10-29 | Mongodb, Inc. | Method and apparatus for maintaining replica sets |
| US9805108B2 (en) * | 2010-12-23 | 2017-10-31 | Mongodb, Inc. | Large distributed database clustering systems and methods |
| US20220100498A1 (en) * | 2021-12-08 | 2022-03-31 | Intel Corporation | Implementation of object versioning and consistency at scale |
-
2022
- 2022-09-05 CN CN202211081162.3A patent/CN115145942B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107733957A (en) * | 2016-08-12 | 2018-02-23 | 北京融聚世界网络科技有限公司 | Distributed Services configure system and version number's distribution method |
| CN109977171A (en) * | 2019-02-02 | 2019-07-05 | 中国人民大学 | A kind of distributed system and method guaranteeing transaction consistency and linear consistency |
| CN112559496A (en) * | 2020-12-24 | 2021-03-26 | 百果园技术(新加坡)有限公司 | Distributed database transaction atomicity realization method and device |
| CN112925763A (en) * | 2021-03-22 | 2021-06-08 | 河北工业大学 | Method for rapid persistence based on CAD |
Non-Patent Citations (1)
| Title |
|---|
| 分布式数据库中一致性与可用性的关系;朱涛等;《软件学报》;20171204(第01期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115145942A (en) | 2022-10-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105808736B (en) | A kind of list data-updating method, apparatus and system | |
| JP6492123B2 (en) | Distributed caching and cache analysis | |
| US10275347B2 (en) | System, method and computer program product for managing caches | |
| CN110597739A (en) | Configuration management method, system and equipment | |
| CN111274310A (en) | Distributed data caching method and system | |
| CN111061810B (en) | Distributed transaction management method and system based on distributed logic timestamp | |
| CN107193827B (en) | Idempotent control method and device for sub-base and sub-table | |
| CN115599747B (en) | Metadata synchronization method, system and equipment of distributed storage system | |
| EP4216061A1 (en) | Transaction processing method, system, apparatus, device, storage medium, and program product | |
| US20120297010A1 (en) | Distributed Caching and Cache Analysis | |
| CN112948178A (en) | Data processing method, device, system, equipment and medium | |
| CN111880956A (en) | Data synchronization method and device | |
| CN113094430B (en) | Data processing method, device, equipment and storage medium | |
| CN109739684B (en) | Vector clock-based copy repair method and device for distributed key value database | |
| CN113010549A (en) | Data processing method based on remote multi-active system, related equipment and storage medium | |
| CN107181773B (en) | Data storage and data management method and device of distributed storage system | |
| CN115114374B (en) | Transaction execution method and device, computing equipment and storage medium | |
| CN115145942B (en) | Distributed database system and method and device for realizing monotonous reading of distributed database system | |
| CN113360577A (en) | MPP database data processing method, device, equipment and storage medium | |
| CN112261090A (en) | Web data processing method and device, computer equipment and readable storage medium | |
| CN115640353A (en) | Data reading method, computer storage medium and electronic device | |
| CN111506254A (en) | Distributed storage system and management method and device thereof | |
| CN112860746B (en) | Cache reduction-based method, equipment and system | |
| US7058773B1 (en) | System and method for managing data in a distributed system | |
| CN113791740A (en) | Method for recording object storage bucket statistics and counting |
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 |