Step by step, slowly.
Generally speaking, what is the hierarchical architecture of Internet with large concurrency and throughput?
Each database has a microservice on the upper layer. The service layer records the mapping relationship between “business library” and “database instance configuration” and routes SQL statements to the database through the database connection pool.
As shown in the figure above, the service layer configures the database instance IP for the user library user.
Voice-over: It is actually an Intranet domain name.
How does this layered architecture deal with databasesHigh availability?
Database high availability, a very common way, using double master synchronization + Keepalived + virtual IP.
As shown in the figure above, two synchronized master libraries use the same virtual IP.
When the primary database fails, the virtual IP is automatically moved to another primary database, and the whole process is transparent to the caller, thus ensuring high availability of the database.
Voiceover: On high availability, __How does the layered Architecture of the Internet ensure “high availability”?”Has been introduced, this article will not expand.
How to deal with this layered architectureAn explosion of data?
As the amount of data increases, the database needs to be horizontally shred and distributed to different database instances (even physical machines) to reduce the amount of data and improve performance.
As shown in the figure above, the user library is distributed on two instances, IP0 and IP1. The service layer searches for library route by taking module of user identification UID. Module 2 and module 0 visit user library on IP0, and module 2 and module 1 visit User library on IP1.
Voiceover: At this point, the read and write instances of the horizontally shelled cluster are doubled and the amount of data for a single instance is halved, resulting in more than a doubling of performance.
To sum up, the layered architecture of Internet microservices with large data volume and high availability is as follows:
Both horizontal segmentation, and ensure high availability.
What if the data volume continues to increase and the performance of the two libraries becomes unbearable?
At this point, it is necessary to continue the horizontal split, split into more libraries, reduce the amount of single library data, increase the number of main library instances (machines), improve performance.
The new problem arises: after dividing into N libraries, the data volume should be increased to 2* N libraries with the increase. How to expand the database, whether the data can be smoothly migrated, so as to continuously provide external services and ensure the availability of services?
Vo: Have you ever had a similar problem?
Is the easiest solution to think of?
Before discussing the second-level smooth expansion solution, briefly describe the procedure for disabling the service expansion solution:
(1) The site hangs a notice “in order to provide better service for the majority of users, this site/game will be upgraded between 00:00 and 2:00 tonight, and you will not be able to log in at that time, users know”;
Voiceover: Ever seen an announcement like this, actually migrating data.
(2) The microservice stops, and no traffic is written to the database;
(3) Build 2* N new libraries and make them highly available;
(4) Write a small script for data migration, select data from N databases, insert into 2* N databases;
(5) Modify the database routing configuration of microservice, and mode N becomes mode 2* N;
(6) The microservice is restarted, and the new library is connected to provide services externally;
In the whole process, the most time-consuming step is the fourth data migration.
How do I roll back if a problem occurs?
If the data migration fails or the post-migration test fails, change the configuration back to the old database and restore the service.
What are the advantages and disadvantages of the stop service scheme?
Pros: Simple.
Disadvantages:
(1) The service needs to be stopped and the scheme is not highly available;
(2) Technical students are under great pressure, and all work should be completed within the specified time. According to experience, the more pressure there is, the easier it is to make mistakes.
Voice-over: This is a killer.
(3) If the problem is not detected at the first time, the service is started and the problem is found after running for a period of time, it is difficult to roll back. If the file is returned, part of the data will be lost;
Is there a second implementation, a smoother, more handsome solution?
Take a look at the architecture before capacity expansion again. It is divided into two libraries, assuming that each library has 100 million data, how to smoothly expand capacity, increase the number of instances, and reduce the amount of data in a single library? Three easy steps.
Step 1: Modify the configuration.
There are two major modifications:
- The machine where the database instance resides has two virtual IP addresses:
(1) The original %2=0 library is virtual IP0, now add a virtual IP00;
(2) the original %2=1 library is virtual IP1, now add a virtual IP11;
- Modify the service configuration, change the database configuration of 2 libraries to the database configuration of 4 libraries, pay attention to the mapping relationship between the old library and the new library when modifying:
(1) library %2=0, will become %4=0 and %4=2;
(2) the part where %2=1 will become %4=1 and %4=3;
Voice-over: This ensures that the correct data is still routed.
Step 2: Configure reload to expand the instance capacity.
The service layer can be reloaded in several ways:
(a) Relatively original, restart the service, read the new configuration file;
(b) More advanced, the configuration center signals the service, rereads the configuration file, and reinitializes the database connection pool;
Either way, after reload, the database instances are scaled up, from two database instances to four, which can be done in seconds.
The whole process can be restarted gradually with no impact on the correctness or availability of the service:
(a) Even if %2 search and %4 search exist at the same time, it does not affect the correctness of the data, because the data is still synchronized with the two masters;
(b) Even if the search for %4=0 and %4=2 falls on the same database instance, it does not affect the correctness of the data, because the data is still synchronized between the two masters;
Once the instance has been extended, the amount of data per database has not decreased, so the third step still has some finishing touches.
Voice-over: In this step, the number of database instances is doubled.
Step 3: Close work, data contraction.
There are some finishing touches:
(a) Change the double virtual IP address to the single virtual IP address.
(b) Remove the old dual master synchronization so that the data of the paired libraries is no longer synchronized;
(c) Add new dual master synchronization to ensure high availability;
(d) Delete redundant data, for example, delete all data of %4=2 in IP0, and only provide service for data of %4=0;
Voice-over: In this step, the amount of single instance data in the database is halved.
conclusion
In the hierarchical architecture of Internet micro-service with large data volume, high throughput and high availability, the three steps to realize the smooth expansion of database in seconds are as follows:
(1) Modify the configuration (dual-virtual IP, micro-service database routing);
(2) Reload configuration, instance doubling completed;
(3) Delete redundant data and other final work, and the amount of data is halved;