Database reading and writing separation and problems

Introduction for data storage layer high concurrency problem, the first thought may be read and write separation, in the site access volume and read and write not average, the storage is divided into Master,slave two units, all the write is routed to master, all the reads are routed to the slave, Then master and slave synchronize. If a salve is not enough, you can add more than one, such as a master,3 Taiwan slave. For what is the read-write separation, and read-write separation of what benefits, here no longer described, interested can refer to here. There are several solutions when designing a read-write separation: 1.     The read-write separation is placed on the DAO layer, and in the DAO layer, all Insert/update/delete access the master library, and all select accesses the Salve library, which is transparent to the business layer. 2. Put the read and write separation on the ORM layer, such as mybatis can intercept SQL statements via MyBatis Plus, all insert/update/delete access the master library, and all select access to the Salve library.     This is transparent for the DAO layer. 3. Place the agent layer, such as mysql-proxy, so that it is transparent to the entire application. For the vast majority of scenarios, read-write separation is applicable, but there is a problem with read-write separation is the master slave synchronization, this synchronization will have a certain delay, so there are a few scenes to be aware of: scenario one consider the following user registration scenario.

 boolean  addusersuccess = Userdao.adduser ( Registuser);  if   (addusersuccess) {Cachedthreadpool.execute (()      {emailservice.sendactivateemail (userId); });}

 public  static  void  Sendactivateemail (int   UserId) {User User  =     Userdao.getuser (userId);    String userName  = User.getusername ();    String useremail  = User.getuseremail ();    String subject  = "..." ;    String body  = "..." ;  //  call Mail Service send message   }

As above, when the new user registration, after the registration is completed, will send an activation email, the new user is insert, send the message to get the user is select, if there is a delay in master slave, it is possible to obtain the user at this time. Situation two for distributed service system, there will be some independent sub-services, such as user services, order services, these services through HTTP or RPC access, the following is the user Service under the two interface. Userservice.xx.com/user/userinfo POST request, user new or update user USERSERVICE.XX.COM/USER/USERINFO/1 GET request for user information This is two interface services, one for Update user data, a user to obtain data, if the mobile app has an action is to modify the user name, after calling the update user interface to modify the user name, immediately after the call to obtain user information interface, two request interval is short, and if the synchronization delay, it is possible to read dirty data. How to avoid 1 for the first case above. We can add one more parameter to the DAO method, such as:

 Public User getUser (intboolean ismaster)

By Business LayerDecide which library to operate on. 2. Place the read-write flag in the thread context, depending on the specific type of business. For example, to register a user's operation, you can start processing, the thread context into a flag bit master, in all DAO methods, judge the flag bit, if it is master, read from master. Such a read-write separation is made by specific Business ScenariosDecision-making. For the second case of the above 1. The simple way is to add a parameter to the request parameter, the service side depends on the parameters to decide which library to operate, thus increasing the front-end of some work. 2. More complex, can be processed on the server, when the user information is modified, you can add an ID record in Redis or Memcache, 5 seconds expires, each request, the first to Memcache to determine, the corresponding ID exists, if there is read Master, otherwise slave. Just this invisible increases the overhead of the server. Summary of the fact that the data delay is not so serious, the basic is the second level, for the second scenario above, may be two requests back and forth, the data has been synchronized well. No dirty reads, but in some special scenarios, such as Network jitter, new fields, the data synchronization delay may become larger, when the master slave data will be inconsistent, and if there are two scenarios on the business, namely insert/update/ Select immediately after delete, it is possible to read or dirty read. Therefore, the specific separation of the reading and writing in which layer, or according to the type of business and the actual situation to decide.

Database reading and writing separation and problems