On cap theorem


In a single machine, the database is easy to meet the acid characteristics of transactions, but in the distributed database, acid distribution is difficult to meet. So distributed theories like cap and base are born.
Cap Theory: C: consistency, a: availability and P: partition tolerance can only satisfy at most two of them.
On cap theorem

  • Consistency: in a distributed environment, it refers to whether the data can be consistent in multiple copies!
  • Availability: the services provided by the system must always be available, and the user’s request can get the result of the server within the specified time.
  • Partition fault tolerance: in a distributed environment, when a node or network is partitioned, it does not affect the services that provide consistency and availability.

Let’s take a look at two examples of MySQL database synchronization:
On cap theorem
C ensures the data consistency of the two MySQL databases. When the master data is updated, the slave data must also be updated.
A ensures that both the master database and the slave database are available.
P ensures that the master database and the slave database are available to the outside world when there are network partitions.
Because it is a distributed system, our nodes are in different networks, and there will be network partition, so p is what we must meet. If you don’t want to be satisfied, it’s back to stand-alone.
The current scenario is like this: the network partition appears in the master and slave, resulting in data synchronization failure. In this way, the data on both sides are different, and the consistency C is destroyed. If we want to guarantee C, we can only stop at the master and not allow data to be written. At this time, availability A is destroyed.