Solve the delay problem of database read and write separation-redis

Database read-write separation master-slave data synchronization delay problem

The database adopts a master-slave architecture, data read and write are separated, and data queries are taken from the database. Data writing is to directly manipulate the main library, and then synchronize to the slave library.

Due to the delay in database synchronization, the master and slave data will be inconsistent during this period of data synchronization, and the slave database cannot query the latest data.

If your previous database system architecture was a single-database or active-standby structure, when you first switch to a data read-write separation architecture, this pit will most likely be stepped on.

In order to facilitate understanding, let's first understand the database system architecture, and finally look at how to solve the data inconsistency caused by the master-slave synchronization delay.

---

Database system architecture development

Active and standby architecture

In the early stage of business development, the amount of data access is small. At this time, we can directly adopt the single-database architecture.

However, we generally do not use the above architecture because there is a single point of problem. If the database fails, business will be unavailable during this period. We have no solution except waiting for the restart.

So we will add a standby database, real-timeSynchronize the data of the main library.

Once the main library fails, manually kick the mainframe offline and change the standby machine to the mainframe to continue providing services.
This architecture is simple to deploy and maintain, and business development does not require any transformation.

However, the shortcomings are also obvious. The standby database will only be activated when there is a problem with the main database. There is a certain waste of resources.

Master-slave architecture

With the development of business, the amount of requests and data continue to grow, and the business becomes more complex, and soon the data will reach the bottleneck.

Since most businesses read more and write less, the performance of database reads is most likely to become a system bottleneck.

At this time, we can improve the performance of reading. At this time, the solution we can adopt is to increase the secondary instance,Master-slave synchronization, data read and write separation.

It can be seen that there is no difference between this architecture and the master-slave. The main difference is that under the master-slave architecture, the slave library is the same as the master library and needs to be worked at all times. The master library provides write services and the slave library only provides read services.

If the pressure of subsequent reading is still too great, we can also increase the number of slave libraries to expand the reading ability horizontally.

Although the master-slave architecture helps us solve the read bottleneck, but becauseData synchronization is required between master and slave, and there is a certain delay naturally. During this delay window, only one old data can be read from the library.This is also the real cause of the problem in the above case.

If the business does not have high requirements for data consistency, it can be omitted. If the business has requirements for data consistency, then we will discuss how to optimize it.

---

Master-slave delay solution

Scheme 1: Data synchronous writing scheme

The master-slave data synchronization scheme generally adopts the asynchronous method to synchronize to the standby database by default. We can modify it to a synchronization scheme, the master-slave synchronization is completed, the write on the master library can be returned.

Process

1. The business system initiates a write operation and the data is written to the main library
2. The write request needs to wait for the master-slave synchronization to complete before returning
3. Data read from the library, the latest data can be read after master-slave synchronization is completed

This solution only needs to modify the synchronization configuration between the databases, and the business layer does not need to be modified, which is relatively simple. However, because the master library writes need to wait for the master-slave to complete, the latency of the write request will increase and the throughput will decrease. This may not be acceptable for current online businesses.

Option 2: Selectively compulsory reading of the main library

For scenarios that require strong consistency, we can operate the main library for all read requests, so that both reads and writes are in the main library, and there is no inconsistency.

The business layer of this kind of scheme needs to be reformed and read the master forcibly, which is relatively less difficult to reform. However, this solution wastes another database and increases the pressure on the main database.

Scenario 3: Middleware selects routing

This solution requires the use of a middleware, and all database operations are first sent to the middleware, and then distributed to the corresponding database by the middleware.

The process is as follows :

1. Write request, the middleware will be sent to the main library, and record the key of the write request at this time (operation table plus primary key, etc.)
2. Read request, if the key exists at this time, it will be routed to the main library
3. After a certain period of time (experience value), the middleware thinks that the master-slave synchronization is complete, delete this key, and subsequent reads will read from the library

This scheme can keep the data read and write consistent. However, the system architecture adds a middleware, the overall complexity becomes higher, business development becomes complicated, and the learning cost is relatively high.

Redis cache routing method (recommended)

This scheme is similar to the middleware scheme process, but the cost of transformation is relatively low, and no middleware is required.

The process is as follows :

1. The write request is sent to the master library, and the key of the recording operation is cached at the same time, and the invalidation time of the cache is set to at least the delay time of the master and slave;
2. The read request first determines whether the cache exists.
   If it exists, it means that a write operation has just occurred, and the read request operation is the main library.
   If it does not exist, it means that no write operation has occurred recently, and the read request operation is from the library.

This solution has a lower cost than the middleware solution, but at this time, a cache component is introduced, and another cache operation is added between all reads and writes.

---

to sum up

The introduction of a master-slave architecture and separation of data reading and writing are aimed at solving the problem of rapid business development, increasing the amount of requests and increasing the amount of concurrency, which causes the bottleneck of database reading.

However, when a new architecture is introduced to solve the problem, another problem will inevitably arise. After the database reads and writes are separated, the master-slave delay will lead to data inconsistency. ,

In order to solve the problem of master-slave delay and data inconsistency, we can use the following solutions:

1. Database synchronous writing scheme
2. Selective forced read master
3. Middleware routing method
4. Cache routing method

The above solutions have their own advantages and disadvantages, we need to choose the corresponding solution according to our business situation.