Background:
For very important data, data redundancy needs to be performed during system deployment. That is, multiple copies of these data should be saved. Usually, we store each data backup on multiple nodes for storage using a distributed system.
One of my previous projects was a website system called CatSneeze for finding and selling online movies, which used this architecture:
Among them, a load balancer in google cloud is roled by a Apache server, and I use a round-robin fashion for polling. Requests sent from the front end are forwarded to two machines loaded on AWS EC2 in turn. By this method, the burden of access is reduced and the sustainable number of service users is increased.
MySQLs on two AWSs is deployed in a Master-Slave mode, in which the Master can perform all write operations and partial read operations while the Slave performs partial read operations. Data redundancy is performed on instances2 and instance3. Among them, data replication from master to slave can keep the two databases synchronized at any time.
Weakness
Occasionally, the node is not available due to network reasons or the internal causes of instance 2 or 3.
When the user accesses instance2, a piece of data is written. However, if instance2 crashes and leaves the network currently, this will lead to two troubles:
1) The load balancer cannot find instance2. If it thinks it deads, it will forward the user’s next visit to instance3.
2) The data cannot find instance2, so the data that user just written cannot be copied to instance3, causing the instance3‘data oringinal.
CAP Theory
If we choose this: because instance3 can also serve. Small fraction of data’s asynchronization in instance3 does not affect the overall situation. When instance2 is pulled back to the network, data replication can be restarted again.
At this time, we chose Availability (A) to ensure that the system can provide services. Data inconsistency can be tolerated.
If we choose: Data synchronization is extremely important. If the data is inconsistent it will have serious consequences. So when instance2 deads, those data related functions in instance3 must also stop. You must wait for instance2 to return to the network before the slave machine can be restarted and data synchronization can resume.
At this time, we put Consistency (C) in the first place.
Therefore, in the case where the network nodes cannot communicate with each other and the functions related to data replication, we either choose availability (A) or choose consistency (C), and we cannot select both at the same time.
In fact, there is another feature hidden behind these two choices. In the case where network nodes cannot communicate with each other, nodes are isolated and network partitions are created, but the entire system can still work. This feature we call it: Partition tolerance (P).
Summary
This is also a practical interpretation of the famous CAP theory: In a distributed computer system, the three guarantees of consistency (C), availability (A), and partition fault tolerance (P) cannot be satisfied at the same time, up to two.
More info:
CAP定理与Base理论
