1. Now, the business logic is to update a piece of data to 2, and then count the data with the status of 2. Due to the master-slave latency of MySQL, data is sometimes accurate and sometimes inaccurate. 2. Data Update and statistical data are logically the same and cannot be separated. For example, if I just saved the money and changed the status of the data table field to 2... 1. Now the business logic is to update a piece of data to 2 and then count the data whose status is 2. Due to the master-slave latency of MySQL, data is sometimes accurate and sometimes inaccurate.
2. update data and statistical data are logically the same and cannot be separated. For example, if I have just saved the money, the status of the data table field is changed to 2. Now, I need to sum up the total user money to ensure that the total user money is correct.
3. What are the solutions? Is there any good logic to separate them? Does sum ensure the sum is correct and the amount of money in the current state?
4. Thank you!
Reply content:
1. Now, the business logic is to update a piece of data to 2, and then count the data with the status of 2. Due to the master-slave latency of MySQL, data is sometimes accurate and sometimes inaccurate.
2. update data and statistical data are logically the same and cannot be separated. For example, if I have just saved the money, the status of the data table field is changed to 2. Now, I need to sum up the total user money to ensure that the total user money is correct.
3. What are the solutions? Is there any good logic to separate them? Does sum ensure the sum is correct and the amount of money in the current state?
4. Thank you!
Update the database first, and then update the cache.
When reading, read the cache first. The cache does not exist. Then read the database.
Read the master database directly.
We recommend that you first describe what you want to achieve;
Then how do you implement it;
Finally, what problems are encountered.
I have summarized the following methods:
As mentioned above, adding a buffer or using a multi-slave database can not fundamentally solve this problem. Because the Master/Slave latency issue cannot be eliminated.
As described above, read the master database directly.
This is mainly a matter of business logic,
Technically, optimistic locks can be used.
You can add transactions and rollback to the database.
Data redundancy means that the balance field is directly added to the user without updating the data every day and then counting the updated data. This field can be updated each time, and can be perfectly solved with optimistic locks and transactions.
With a large amount of user data, the performance of sum becomes more and more prominent.
Please kindly advise on any improper features
Master/Slave latency: Is there a timestamp for the data? Only data with a timestamp on the server that exceeds the Master/Slave latency can be consistent, not necessarily up-to-date, and of little significance. The master-slave latency is only used for disaster recovery. If the data staff deletes the data, the data can be recovered from the delay.