Original: Monkey World (wechat official ID: Cxytiandi), welcome to share, please reserve the source.

What is read-write separation? The role of reading and writing separation will not be discussed, if there is no understanding of the students can search for information to understand. Or check out my previous post on read-write separation.

At the beginning of the scene must be based on the master library to do the operation of adding, deleting, changing and checking, and so on after the pressure slowly up will consider adding the database from the node, through the way of read and write separation to improve the performance of the query.

First of all, read/write separation default queries go through the slave node.

From our usage habits or business scenarios, the query scenario is greater than add, delete and change. Therefore, we will manually control the Sql to be executed in the master library in the business scenarios where data operations need to be carried out in the master library. The logic of this control can be written by ourselves or realized by using the built-in functions of the framework. I won’t go into details.

For example, we define an annotation @master to indicate that the method goes to the Master library, and then the Aspect can switch the data source. This is actually a very common implementation, and if you start with slave nodes, it’s fine to do this, but if you start with slave nodes, it’s problematic to do this.

Once you do that, you’ll have no problem with add, delete, or change, and you’ll probably have problems with search. The problem is not that there are bugs, but that there are some experience issues that can cause bugs. You all know that master-slave architecture is a problem with data latency, and as long as there is latency, there can be problems.

In some service scenarios, you add a piece of data and immediately jump to the details. In this case, if the data is delayed, you cannot find the newly added data when you query the slave node when you go to the details.

The solution is to sort out all the business scenarios, then run the tests back through, annotate all the queries that need to go through the Master library with @master annotations, and you won’t have a problem.

There seems to be no problem, in fact, we ignore a point is the cost of time. It takes time to sort out business scenarios and regression tests in their entirety, and time is the biggest cost.

Therefore, when we do read and write separation in the later stage, we basically will not adopt the above way to achieve it, because the more business functions, the higher the cost.

The real way to do it is the other way around, the thing that we have to think about whenever we implement any new feature is how do we minimize the impact? How do I not affect the previous logic?

The method is that all the old logic is not moved, the default still go to the master library, but our program has done read and write separation function, the default query will go to the slave library, so the first step is to send all the Sql query to the master library, which can be realized through Aspect.

This step can be directly online, because all operations still go to the main library, with no difference before, does not affect any old logic.

Now it’s time to think about which queries can be pulled from the library, but this can be done slowly and combed through slowly. This makes it easier. Each iteration we can comb through several queries that are forced to Slave from the library by adding @slave annotations. This scenario we combed through and verified is fine. So slowly, until all the old logic is combed out.

Good ideas can ensure stability and ease of use, and if you get something, just give it a thumbs up!

About the author: Yin Jihuan, a simple technology lover, the author of Spring Cloud Micro-service – Full stack Technology and Case Analysis, Spring Cloud Micro-service Introduction combat and Progress, the founder of the public account Monkey World.