Distributed consistency concept
Distributed consistency is a very important issue that has been widely explored and demonstrated. Let’s briefly understand the concept of consistency from the following three business factory scenarios
1. Buy train tickets
If our end user is a traveler who often takes trains, he usually goes to the ticket office of the station to buy a ticket, then takes the ticket to the ticket gate, and then gets on the train to start a wonderful journey.
Imagine that if the destination he chooses is Hangzhou, and there is only the last ticket left for a high-speed rail trip to Hangzhou, it is possible that at the same time, another passenger at a different ticket window also bought the same ticket. If the ticketing system does not guarantee consistency, at this time, two people have purchased tickets, and when the ticket is checked at the ticket gate, one of the passengers will be informed that his ticket is invalid. Of course, modern China Railway ticketing systems have rarely experienced such problems. But in this example, we can see that the end user’s requirements for the system are very simple
Please sell me the ticket. If there is no more ticket, please tell me when the ticket is sold that the ticket is invalid.
This puts forward strict consistency requirements for the ticket purchase system. The system data (in this example refers to the number of remaining tickets for the train to Hangzhou), regardless of whether the purchase is made at any window, it must be purchased at all times. Is accurate. Moreover, it is a distributed system, where multiple nodes are deployed, which poses a challenge to consistency at this time. Data consistency
2. Bank transfer
If our end user is a student, usually when he is part-time or summer work, he will choose to send money to his home. When he comes to the bank counter and completes the transfer operation, the bank's counter staff will kindly remind him: The transfer will arrive within N working days. This has also become the most basic requirement for almost all users of modern banking systems, as long as the account can be received within this time.
3. Online shopping
If our end user is an online shopping expert, when he sees a favorite item with a stock of 5, he will quickly confirm the purchase, write down the delivery address, and then place an order—however, at the moment of placing the order , The system may tell you that the inventory is insufficient to purchase. At this time, most consumers will complain that their actions are too slow, making their favorite products robbed by others.
But in fact, the inventory displayed on the product page is usually not the actual inventory of the product. The system will only check the actual inventory of the product when the order is actually purchased. But now e-commerce is divided into some other scenarios, that is, inventory is deleted when placing an order. Some e-commerce platforms only delete inventory after successful payment.
Problem interpretation:
For the above three examples, I believe you must have noticed that our end users have different data consistency requirements when using different computer products:
1. Some systems not only need to respond quickly to users, but also ensure that the data of the system is true and reliable for any client, just like a train station ticketing system.
2. In some systems, although some data that can be said to be "wrong" are shown to users, in the process of using the entire system, the system data must be checked for accuracy and error in a certain process, so as to prevent users from unnecessary The loss is just like the online shopping system.
The proposal of distributed consistency
An important problem to be solved in a distributed system is data replication. Data replication can also be understood as data synchronization. In our daily development, I believe that many students have encountered such a problem: suppose that the client C1 updates a value K in the system from v1 to V2, but the client C2 cannot read the latest value of K immediately. It will be read after some time. This example is a common delay problem of replication and synchronization between databases, because there is a delay in database replication and synchronization.
Half of the demand for data replication in distributed systems comes from two reasons:
1 Increase the availability of the system to prevent unavailability of the system caused by a single point of failure.
2. Improve the overall performance of the system. Through load balancing technology, data copies distributed in different places can provide services to users
The huge benefits that data replication brings to distributed systems in terms of availability and performance are of course indescribable, and then the consistency challenge brought by data replication is also something every developer has to face.
The so-called distributed consistency problem refers to the data inconsistency that may occur between different data nodes after the data replication mechanism is introduced in the distributed environment and cannot be solved by the computer application itself. Simply put, data consistency means that when the data of one copy is updated, it must be ensured that other copies can also be updated, otherwise the data between different copies will be inconsistent.
The so-called distributed consistency problem refers to the situation of data inconsistency that may occur between different data nodes after the data replication mechanism is introduced in a distributed environment and cannot be solved by the computer application itself. Simply put, data consistency means that when the data of one copy is updated, it must be ensured that other copies can also be updated, otherwise the data between different copies will be inconsistent.
So how to solve such a problem?
One way of thinking is: Since the problem is caused by the delayed action, I can block the write action until the copy is completed, and then the write action is completed. In this case, it seems to be able to solve this problem, and some system architectures are indeed solved through this kind of thinking, but this also brings a new problem: write performance. This should be selected according to the specific application scenario. If your application scenario has a lot of write requests, then after using this idea, subsequent write requests will be blocked on the write operation of the previous request, resulting in the system The overall performance will drop sharply.
In general, we cannot find a distributed consistency solution that can satisfy all system attributes of a distributed system. Therefore, how to ensure data consistency without affecting the performance of the system is a key consideration and trade-off for every distributed system. Therefore, the consistency level is generated.
The current distribution is definitely inseparable from this aspect of content, so to a certain extent, you must have ideas, and when encountering such problems, you must comprehensively consider how to deal with them according to your own business scenarios. This is a vital part. The premise is a good understanding of what is distributed is of course the most important point.
Then the consistency level was introduced
1. Strong consistency
Among them, the consistency level is the most intuitive for users. It requires what the system writes and what is read. The user experience is the best, but the implementation will often greatly affect the performance of the system. Why do you say that? Because, in this case, it will cause other threads to block, requiring all data to be successfully synchronized before allowing other users' threads to access. To this extent, strong consistency is achieved, but system performance is lost. At this time, the system is also in an active period. At this time, resources are wasted. In fact, my personal understanding is that there are problems if you do this. What is the problem? If the data is replicated and synchronized, due to communication failures or What to do with network partitions, in this case, may lead to system downtime problems, so I think it is really difficult to achieve consistency. To ensure consistency, but also to ensure availability, in fact, it is impossible to have both. At least at this stage, I understand it this way, and there may be misunderstandings. I hope you can see this. If I understand it incorrectly, let's communicate and discuss together.
2. Weak consistency
This consistency level constrains the system, after a successful write, does not promise that the written value can be read immediately, nor does it promise how long the data will be consistent, but it will try to ensure that after a certain time node, the data can be Reach a consistent state
3. Eventual consistency
Eventual consistency is a special case of weak consistency. The system will ensure that the data is consistent within a certain period of time. The reason why the final consistency is proposed separately here is because it is a consistency model highly recommended in weak consistency, and it is also a model that the industry recommends in the data consistency of large-scale distributed systems.