Master-slave synchronization:
We all know that the Master-Slave Replication of MySQL and other common databases in the industry, the master-slave synchronization is divided into three stages:
Master accepts write request
Master copies logs to Slave
The master waits until all slaves return.
It can be seen that the master-slave synchronization model has a fatal problem: as long as one node fails, the Master will block, resulting in the unavailability of the entire cluster, ensuring consistency, and greatly reducing the availability.
Majority:
Each write is greater than N/2 nodes, and each read is guaranteed to read from N/2 nodes. The majority model seems to perfectly solve the multi-node consistency problem. Isn’t that the performance is poor, but not necessarily in the case of concurrency, as shown below:
In a concurrent environment, because the operation log writing order of each node cannot be guaranteed to be consistent, the final consistency cannot be guaranteed. As shown in the figure, all three nodes
Inc5 and set0 are two operations, but because the sequence is different, the final state is two 0 and one is 5. Therefore, we need to introduce a mechanism to number each operation log, which is generated from small to large, so that each node will not make a mistake. (Have you thought of subcontracting and reorganization in the network?) So, now the key question comes again, how to coordinate this number? It seems that this is a chicken-and-egg problem.
