Acid, base, and cap

The cloud computing platform is a very huge distributed system that needs to process massive requests. Therefore, any small probability event must occur on this platform.

DBMS emphasizes acid: atomicity, consistency, isolation, and durability ). The consistency emphasizes that the database is in the consistent state when the transaction defined by the programmer is completed. For example, for transfer, the transaction must be completed as much as a is and B is much more. For many Internet applications, consistency and isolation requirements can be reduced, while availability requirements are more obvious. This produces two weak consistency theories: Base and cap.

Base: basically availble -- Basic available; soft-state --; eventual consistency -- Final consistency

Cap: consistency; Availability availability; tolerance of network partition adequacy (it can be understood that the system can still work normally under some node faults or connection failures between nodes ). Brewer puts forward the empirical theory that the three goals can be achieved at most two, and the other needs to be compensated in other ways.

If no partition exists in the network, the client and the storage system are in the same environment, and the consistency and availability can be ensured through the distributed transaction mechanism. However, in a large network system, partitions are inevitable. Therefore, the general choice is only to balance and compromise between consistency and availability. For example, eBay's Experience Ensures availability as much as possible, but it uses careful adjustments to the database operation sequence, asynchronous recovery events, and reconciliation or settlement batches) to help the system achieve final consistency.

The actual Internet systems are often the combination of acid and base systems, such as user identity data and transaction data usually adopt acid standards.

Guy pardon believes that the CAP theory assumes that the CAP is satisfied at the same moment in time. If you give up this assumption, you can get a solution that all three are satisfied. But in my opinion, its solution is only a compromise between availability and consistency. If read/write consistency is abandoned, only the snapshot in the cache is read, instead of the latest value. Data Update consistency is ensured by executing the write queue only when the system has no partition, and the result is obtained asynchronously, this is equivalent to a reduction in write availability requirements.

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/wdwbw/archive/2009/05/13/4179749.aspx

Distributed domain cap theory,
Consistency (consistency), consistent data updates, and all data changes are synchronized
Availability (availability), good response performance
Partition tolerance (partition fault tolerance) Reliability
Theorem: Any distributed system can only satisfy two points at the same time, and cannot take both of them into consideration.
Advice: architects should choose not to waste their energy on designing a perfect distributed system that meets the three requirements.
The acid model of relational databases has high consistency and reliability loss of availability:
Atomicity atomicity: all operations in a transaction must be completed or not completed.
Consistency consistency. The database should be consistent at the beginning or end of the transaction.
Isolation isolation layer. transactions will assume that they are only operating on the database and are unaware of each other.
Durability. Once the transaction is completed, it cannot be returned.
Cross-database transactions: 2 PC (two-phase commit), 2 PC is the anti-scalability pattern (Pat Helland) is the anti-scalability pattern, JTA transactions in javaee can support 2 pcs. Because 2 pcs are in reverse mode, try not to use 2 pcs. Use base to avoid this.
Base model anti-acid model, completely different acid models, sacrifice high consistency to obtain availability or reliability:
Basically available is basically available. Failed to support partition (e.g. sharding database)
Soft State can be asynchronous or not synchronized for a period of time.
Eventually consistent is eventually consistent, and the final data is consistent, instead of always high consistency.
The main implementations of the base idea are:
1. Divide databases by function
2. sharding fragments
Base mainly emphasizes basic availability. If you need high availability, that is, pure high performance, you must sacrifice consistency or fault tolerance, the base solution has the potential to explore performance.
Now the nosql movement enriches the base idea and can customize special solutions according to specific situations, such as ignoring consistency and achieving high availability. nosql should have the following two schools:
1. Key-value storage, such as amaze dynamo, allows you to flexibly choose database products with different tendencies based on the three principles of CAP.
2. domain model + distributed cache + storage (qi4j and nosql movement). You can customize a flexible distributed solution based on the three principles of CAP, which is difficult.
The two have the same thing: they are all optional solutions other than relational database SQL. With the distribution of Logic Data, any model can be persisted by itself, separating data processing and data storage, and separating reading and writing, the storage can be asynchronous or synchronous, depending on the degree of consistency requirements.
Differences: Key-value storage products such as nosql are the product box that meets the relational database header. They can be used in non-Java, PHP, Ruby, and other fields, domain Model + distributed cache + storage is a complex architecture solution, not a product. However, this method is more flexible and must be mastered by architects.