On the data consistency of distributed system (IV.)

In the previous three articles, the problem of data consistency in distributed systems was introduced, which mainly introduced the CAP theorem and its own understanding of the cap theorem.

The cap theorem was introduced in 2000 by Eric Brewer.

Brewer that when designing and deploying a system in a distributed environment, there are 3 core requirements that exist in a particular relationship. The distributed system here is said to be physically distributed systems, such as our common web system.

The 3 core requirements are: Consistency,availability and partition tolerance, which gives the theory another name-CAP.

Consistency: Consistency, which is similar to the consistency of the database acid, but the consistency and correctness of data on all data nodes here, while the acid of the database is concerned with some constraints on the data within a transaction.

Availability: Availability, the focus of data on a node is available, it can be considered that the system is available for a certain point, except for communication failures.

Partition tolerance: Partition tolerance, whether the data can be partitioned. This is due to performance and scalability.

Why not fully guarantee this three point, the personal feel mainly because once the partition, it is necessary to communicate between the nodes, involving communication, there is no way to ensure that the specified text in a limited time, if required to complete between the two operations, because the communication is involved, There must be a time when only one part of the business operation is completed, and the data is inconsistent during the time the communication is completed. If consistency is required, the data must be protected during the time the communication is complete, making any operation that accesses the data unavailable.

If you want to ensure consistency and availability, then data cannot be partitioned. A simple understanding is that all data must be stored in a database and cannot be split into databases. This is unacceptable for large data volumes, and for high-concurrency Internet applications.

We can take a simple example to illustrate: Suppose a shopping system, seller A and seller B made a deal 100 yuan, the transaction was successful, the buyer gave the money to the seller.

There are two tables of data: Trade table Account table, involving three data trade (+), account A, account B

Assuming that the trade table and the account table are in a single database, you can guarantee consistency without compromising availability by simply using the database's transactions. But as the trading volume becomes larger, we can consider separating the trading base and the account library according to the business Sub-Library, which involves the trade library and the account Library for communication, that is, there are partitions, so we cannot guarantee both availability and consistency.

We assume the initial state

Trade (Buyer,seller,tradeno,status) = Trade (a,b,20121001,i)

Account (Accountno,balance) = account (a,300)

Account (Accountno,balance) = account (b,10)

In an ideal situation, we expect the state to be

Trade (Buyer,seller,tradeno,status) = Trade (a,b,20121001,s)

Account (Accountno,balance) = account (a,200)

Account (Accountno,balance) = account (b,110)

But taking into account some of the anomalies

Assuming that after the trade (20121001,s) update is completed and account A is charged, account a makes another 300-dollar transaction and consumes the money, then there is a status

Trade (Buyer,seller,tradeno,status) = Trade (a,b,20121001,s)

Account (Accountno,balance) = account (a,0)

Account (Accountno,balance) = account (b,10)

The state of inconsistent data is generated.

As this relates to the financial problem, the demand for funds is relatively high, we must ensure consistency, then how to do, only in the trade (a,b,20121001) transaction, for any of the follow-up trade (A,X,X), must wait until a is complete, To be able to process, meaning that the account (A) data is not available at trade (a,b,20121001).

Any architect who designs a distributed system must make a choice between the three. The first is whether to select the partition, because in a data partition, according to the acid characteristics of the database can be guaranteed consistency, there is no availability and consistency issues, the only thing to consider is performance issues. For usability and consistency, most applications must ensure availability, after all, Internet applications, sacrificing usability, which is equivalent to indirectly impacting the user experience, and the only consideration is consistency.

Sacrificing consistency

The most common case of sacrificing consistency is the problem of data synchronization between cache and database, we treat the cache as a data partition node, and the database as another node, the data between the two nodes can not guarantee consistency at any time. In web2.0 such a business, happy to give an example, access to a user's information, you can access the cached data, but if the user modifies some of his own information, the first to modify the database, and then update the notification cache, this period will result in inconsistent data, the user may be accessing an outdated cache, rather than the latest The data. However, because these business requirements for consistency are relatively high, will not have too much impact.

Abnormal error detection and compensation

Another way of sacrificing consistency is through an error compensation mechanism, which can take the example of shopping above, assuming we adjust the order of business logic by withholding the buyer's money, then updating the trading status, and calling the seller

We assume the initial state

Account (Accountno,balance) = account (a,300)

Account (Accountno,balance) = account (b,10)

Trade (Buyer,seller,tradeno,status) = Trade (a,b,20121001,i)

Then it's possible.

Account (Accountno,balance) = account (a,200)

Trade (Buyer,seller,tradeno,status) = Trade (a,b,20121001,s)

Account (Accountno,balance) = account (b,10)

Then there is a buckle success, trading status is also successful, but the money did not call B, this time can be through an abnormal recovery mechanism, the money to B, the final situation to ensure consistency, in a certain time the data may be inconsistent, but will not affect too much.

Two phase commit agreement

Of course, there is another way that I have in the other article "X/open dtp-Distributed Transaction Model" inside, but again between the first phase and the second stage, the data can not be consistent, may also occur the same situation caused the exception. Also, the DTP distributed transaction model is too restrictive, such as the need for relevant container support to implement its functionality, and the XA specification must be implemented by the resource manager. The limit is much higher.

Some architects abroad have two options to address cap limitations, but they are more appropriate for a particular business than a common solution.

Explore partition-and intra-partition operations-Ex-post compensation

is the anomaly detection and recovery mechanism described above, this mechanism is still limited,

First for the partition detection operation, different business involves the partitioning operation may not be the same

Intra-partition operation restrictions: Inconsistent constraints for different business counterparts

Compensation after the event: due to different business constraints, the compensation method is not the same.

So it can only be thought of as a general solution.

There is the base idea that ebay uses ((basically available, soft state, eventually consistent), this is more interesting, there is time to write it.

Blog Park Address: http://www.cnblogs.com/aigongsi/
Independent Blog:god is coder