Architect Express 8.3-rules that architects must understand

As an architect, some rules have to be mastered, which is the axiom of the software, if you learn physics do not know Newton's law, then do not learn. There are similar things in the software industry, I call it the software law. For example:

Acid,cap,base

ACID

In a traditional database system, transactions have acid 4 properties

(1) atomicity (atomicity): A transaction is an atomic manipulation unit whose modifications to the data are either all executed or not executed.

(2) Consistency (consistent): data must be in a consistent state at the beginning and completion of a transaction. This means that all relevant data rules must be applied to the modification of the transaction to preserve the integrity of the data; At the end of the transaction, all internal data structures, such as B-tree indexes or doubly linked lists, must also be correct.

(3) Isolation (Isolation): The database system provides a certain isolation mechanism to ensure that transactions are performed in a "stand-alone" environment that is not affected by external concurrency operations. This means that the intermediate state in the transaction process is not visible to the outside, and vice versa.

(4) Persistence (durable): After a transaction is complete, it changes the data to be permanent, even if a system failure occurs.

It can be said that the database system is accompanied by the needs of the financial industry and rapid development. For the financial industry, usability and performance are not the most important, and consistency is the most important, the user can tolerate system failure and stop the service, but can not tolerate the money on the account for no reason to reduce, and strong consistency of the transaction is the fundamental guarantee of all this.

CAP

At the 2000 PODC (Principles of distributed Computing) Conference, Brewer presented the famous cap theory. CAP refers to: consistency, availability, and partition tolerance.

(1) Consistency (consistency): Consistency is the atomic nature of the data, which is guaranteed by transactions in the classic database, and when the transaction is complete, whether it is successful or rolled back, the data will be in a consistent state. In a distributed environment, consistency means that data from multiple nodes is consistent.

(2) Availability (availability): Availability means that the service can always be guaranteed to be available, and when a user makes a request, the service can return the result within a limited time.

(3) Partition tolerance (partition fault tolerance): Partition refers to the partition of the network. In general, the key data and services are located in different IDC.

The CAP theory tells us that a distributed system cannot meet the three requirements of consistency, availability, and partition fault tolerance at the same time, with a maximum of two points in three features. Three can not be taken into account, this so-called fish and bear Paw can not have both! In the case of distributed Data system, partition fault tolerance is the basic requirement, otherwise it is not called distributed system. Therefore, architects should not waste their energies on the design of a perfect distributed system that can satisfy all three, but trade-offs should be made. This also means that the design process of distributed systems, that is, based on the business characteristics of C (consistency) and a (availability) to find a balance between the process, requires architects to really understand the system requirements, grasp the business characteristics.

later: The author of the CAP theory finally gave me a long-standing answer: The CAP theory is not strictly three-two, and in most cases a and C can be combined, because in most cases, p does not exist.
P occurs only when the communication delay between nodes is greater than the acceptable range (the nodes begin to be approximately isolated, the state begins to be inconsistent), that is, if P appears, we choose to continue to provide the service then the state is definitely inconsistent, it is tantamount to giving up C; we choose not to provide services, then we give up a. Popular point, p is not the goal, nor means, it is accompanied by the "Multi-node, network, data, sharing," the requirements of the inevitable, the reason is due to the network of unreliable and node communication delay (the cause of the delay may be due to hardware, network, or too much pressure to respond in a timely manner).

Figuring out the CAP's p also made clear the essence of the CAP theory, and the Magic Spell on the top of the head was permanently removed.

The CAP theory does not require us to be pessimistic about abandoning either party A or C, but instead it can be an optimistic guide to maximizing C and a; acid and base are at two extremes of the CAP theory, acid emphasizes strong consistency, and base emphasizes high availability, both of which focus on a and C, The fact that P is also variable is diluted; by detecting the presence of P, we find the limitation and constraint after p, the compensation and recovery after p, by adopting a wide variety of strategies, we can avoid the severe loss of c and a caused by P, and realize the maximization of a and C to improve the correctness and usability of the whole system. Acid and base are not incompatible, we can use both acid and base in the same system.

BASE

Based on the practice of e-commerce in the Internet, it evolves from the cap theory, and the core idea is that even if strong consistency (strong consistency) is not achieved, the final consistency can be achieved according to the application characteristics (eventual Consistency) effect. Base is a shorthand for the three phrases of basically Available, Soft state, eventually consistent, and is an extension of C & A in the cap. The meaning of base:

(1) Basically Available: basic available;

(2) Soft-state: Soft state/flexible transaction, that is, the state can have a period of time of the different steps;

(3) Eventual consistency: final consistency;

Base is anti-acid, which is completely different from the acid model, sacrificing strong consistency, obtaining basic availability and flexible reliability, and requiring eventual consistency.

I will continue to enrich this software law later.
Arrowcat
Source: http://www.cnblogs.com/hustcat/
This article is copyright to the author and the blog Park, Welcome to reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.

This article is for Gleasy original article, reprint please specify quote from Gleasy team Blog

Architect Express 8.3-rules that the architect must understand (go)