Pain points of the later database master-slave architecture, really painful

Original: Yuantiandi (WeChat public account ID: cxytiandi), welcome to share, please keep the source for reprinting.

What is read-write separation? I won’t talk about the role of separation of reading and writing. If there are students who don’t understand, they can search for information on their own. Or check my previous article .

The initial scenes are definitely based on the main database to add, delete, modify, and check operations. After the pressure slowly rises, the slave node of the database will be considered, and the performance of the query will be improved through the separation of read and write.

First of all, the default query of read-write separation is from the node.

In terms of our usage habits or business scenarios, the query scenarios are greater than additions, deletions, and modifications. Therefore, we will manually control this Sql to be executed in the main library in a business scenario where we need to go to the main library for data operations. The logic of this control can be written by ourselves or can be realized by using the framework's own functions, so I won't go into details. Up.

For example, we define an annotation @Master to mark this method as the main library operation, and then use Aspect to switch the data source. This is actually a very common way of implementation. If you have a slave node at the beginning, it is okay to standardize this. If a slave node is added later and read and write separation is started, there is a problem in doing so. .

Once this is done, there is no problem with the operation of adding, deleting and modifying, and there may be problems with the operation of checking. This problem does not mean that there are bugs, but that there are some experience problems that may cause bugs. Everyone knows that the master-slave architecture actually has the problem of data delay. As long as there is a delay, there may be problems.

In some business scenarios, if you add a new piece of data, you will immediately jump to the details. At this time, if the data is delayed, and you can query the slave node when the details are reached, the newly added data will not be found. This will happen. The problem.

The solution is to sort out all the business scenarios, and then let the test return as a whole, and add @Master annotations to all the query methods that need to go to the main library operation, and there will be no problem.

It seems that there is no problem, but in fact, one thing everyone has overlooked is the problem of time cost. It takes time to organize business scenarios and overall regression testing, and time is the biggest cost.

Therefore, when we do the separation of reading and writing in the later stage, we basically do not use the above method to achieve it, because the more business functions, the higher the cost.

The real approach is to go the other way, no matter how to implement any new features, we have to consider the point is how to minimize the impact? How to not affect the previous logic?

The method is that all the old logic remains unchanged, the default is to go to the main library, but our program has already done the function of reading and writing separation, the default query is to go to the slave library, so the first step is to all query Sql Send to the main library, which can be achieved through Aspect.

After completing the above step, you can go online directly, because all operations are still in the main library, which is the same as before and will not affect any old logic.

Now we have to consider which queries can go from the database, but this action can be done slowly and can be sorted out slowly. This will be easier. In each iteration, we can sort out several queries that go from the library, and directly add an @Slave annotation to force it to go from the library. We have sorted out this scene and verified that it is no problem. Just sort it out slowly, until all the old logic is sorted out.

A good idea can ensure stability and ease of use. If you get something, please give it a thumbs up!

About the author : Yin Jihuan, simple technology enthusiast, author of "Spring Cloud Microservices-Full Stack Technology and Case Analysis", "Spring Cloud ", the public number 160a8d62e3f00b Ape World 160a8d62e3f00d initiator