Replication Latency Case (3) - Monotonic Read

The second case of the previous asynchronous replication read exception, there is a strange situation where user data is rolled back.

This may be the case if the user reads multiple times from different [slave nodes].Figure-4 shows that user 2345 made the same query twice:

• First query the slave node with low latency
• Then the slave node with the larger delay

This is quite possible if the user refreshes the page and each request is routed to a random server.

The first query returns the most recently added comment by user 1234, but the second query returns nothing because the lagging slave has not pulled the write yet.In effect, the second query observes the system at an earlier point in time than the first query.

• If the first query doesn't return anything, it's not a big problem because user 2345 may not know that user 1234 recently added a comment
• But if user 2345 sees user 1234's comment first, and then sees it disappear, then user 2345 will feel overwhelmed

A monotonic read guarantees that this exception does not occur.This is a weaker guarantee than strong consistency, but stronger than eventual consistency.When reading data, it is possible to see an old value; monotonic reading only means that if a user reads multiple times in sequence, it will not see time backwards, that is, if newer data is previously read, subsequent readsFetch will not get older data.

A solution to implement monotonic reads: ensure that each user always reads from the same replica (different users can read different replicas).Such as selecting replicas based on user ID hashes instead of randomly selecting replicas.But if that replica fails, the user's query will need to be rerouted to another replica.