MYSQL high concurrent affairs issues

High concurrent transactions emerging issues

• 1. The first loss of
  two transaction AB make changes to the same data are S, S A modification is successful, B modification failure rollback occurs rollback S A results in a modification of the original data is to be covered. Led to two changes to the S have failed.
  READ COMMITTED isolation mechanism and above can be solved
• 2. A dirty read
  when processing the same or AB transaction data S, S This data is modified in the transaction, but not yet submitted the data A, B reads the transaction data S A modifies the transaction, then the transaction rollback A, resulting in piece of data S B is read transaction does not exist. Because the S content before
  REPEATABLE READ isolation mechanism can be solved
• 3. Repeat not read
  or process the same data transaction AB S, A reads transaction data S, then the modified transaction data B S, and then the data is read Transaction A S, where transaction A reads two S the data is the data before and after modification transactions B, is clearly different
  REPEATABLE READ isolation mechanism can be solved
• 4. The second type of special case of non-repeatable read lost
  or a transaction with the data processing AB S, the transaction A modified into S S1, S Transaction B then again modified into S2, a modified Transaction B but not in S1 and S2 Based on the results in a modification of the transaction a does not work, that is a failure.
• The phantom read
  transaction processing AB Sn batch of data, such as A to read a classification of Sn is 10 data, then the transaction B to a new classification of data, such data is then read transaction A discovery to 11 one, this is the phantom reads. Twice the number of reads all changes, unlike non-repeatable read

Examples problem

What is a transaction

A transaction is a combination of the statement or more database operations, comprising ACID, 4 characteristic.
Atomic: either all succeed, or complete withdrawal
Isolation: affairs are independent, non-interfering
consistency: the database correctly after changing the state of the database consistency constraint has not been destroyed
Persistence: Submit outcome of the transaction, We will persist in the database

Transaction concurrency problem that would arise

• 1) The first category is missing Update: In the absence of transaction isolation, the two transactions are updated simultaneously a row of data, but the second transaction was aborted exit, resulting in two modifications to the data are ineffective.
  For example:
  Joe Smith's salary is 5000 A transaction in 5000 to obtain wage, wage acquisition transaction B 5000, 100 import and submit the database, wages becomes 5100,
  followed by
  abnormal A transaction occurs, rolled back, restored Joe Smith the wages of 5000, thus leading to an update transaction B is lost.

• 2) Dirty read: dirty read refers to when a transaction is accessing data, and the data has been modified, and this modification has not been submitted to the database, then, another transaction also access the data, and then use this data .
  For example:
  　　Joe Smith wage of 5000, transaction A change in his salary 8000, but the transaction has not yet submitted A.
  　　At the same time,
  　　the transaction B is being read Bob's salary, read John's salary is 8000.
  　　Subsequently, the
  　　transaction A exception occurs, and roll back the transaction. John's wages rolled back to 5000.
  　　Finally,
  　　transaction B has to pay for the data of seating 8000 is the dirty data, transaction B made a dirty read.

• 3) Non-repeatable read: means within a transaction, a plurality of times to read the same data. When this transaction is not over, another transaction also access the same data. So, between the two read data in the first transaction, due to the modification of the second transaction, then the first two transactions read data may be different. This occurs in a transaction the two read data are not the same, so called non-repeatable read.
  For example:
  　　in a transaction A, read John's salary 5000, the operation is not completed, the transaction has not committed.
  　　At the same time,
  　　transaction B to Joe Smith's salary was changed to 8000, and submitted the transaction.
  　　Subsequently,
  　　in a transaction A, read Bob's wages again, this time into a 8000 salary. The results before and after a transaction not to read the two activated, resulting in non-repeatable read.

• 4) The second category lost update: non-repeatable read exceptions. There are two concurrent transactions data simultaneously read the same row, and then modify it to submit one, while the other has also been modified to submit. This will cause the first write operation fails.
  For example:
  in a transaction A, read deposits seating 5000, the operation is not completed, the transaction has not committed.
  　　At the same time,
  　　the transaction B, stored 1000, changed the seating of the deposit 6000, and submitted the transaction.
  　　Subsequently,
  　　the transaction A, the memory 500, the seating of the deposit to 5500, and submitted the transaction, updating such transaction A B covers the update transaction.

• 5) Magic Reading: refers to a phenomenon that occurs when the transaction is not performed independently, for example, a first transaction data in the table has been modified, this modification involves all the data rows in the table. At the same time, also the second transaction to modify the data in this table, this modification is to insert a new row to the table. Then, the user operates the first transaction will occur after the discovery of the table there is no modification of the data lines, as if the same happened hallucinations.
  For example:
  　　the current payroll of 5,000 employees 10 people, Transaction A reads all wage of 5000 the number of 10 people.
  　　At this time,
  　　transaction B is inserted into a record 5000 wages.
  　　This is, again read Transaction A salary of 5,000 employees, recorded as 11 people. This produces phantom reads.

• Reminder:
  non-repeatable reads the focus is modified, the same conditions, you had to read the data, read out value is not the same again found
  the magic of reading focuses on new or deleted, the same conditions, 1st and 2nd times the number of records read out are not the same

Transaction isolation mechanism to solve the problem of concurrency

• (1) READ_UNCOMMITTED
  　　This is the lowest transaction isolation level, it promises another transaction charge and you can see this data uncommitted transactions.
  　　The first update to solve the problem of missing, but there will be dirty reads, non-repeatable read, the second lost updates problem, phantom reads.
• (2) READ_COMMITTED
  　　guaranteed after a modified transaction data submitted by another transaction can be read, i.e., another transaction can not read data of the uncommitted transactions.
  　　The first problem to solve the problem of lost updates and dirty reads, but there will be non-repeatable read, the second lost updates, the phantom read problem
• (3) REPEATABLE_READ
  　　guarantee a transaction under the same condition before and after the two acquired data are consistent with (note that a transaction is to be understood that the data independently of each other between the transaction)

The first update to resolve missing, dirty reads, non-repeatable reads, lost updates the second class of problems, but it will be a phantom reads.

• (4) SERIALIZABLE
  　　transaction to be processed sequentially executed.
  　　Solve all the problems
  　　but do not actually use this isolation mechanism

Reminder:
Mysql default transaction isolation level repeatable_read-

innodb engine locking mechanism

• InnoDB main reason to introduce a lock, because InnoDB supports transactions, supports row and table locks used more, Myisam does not support transactions, only supports table locks
  - shared lock (S): allows a transaction to read a row, stop other matters to obtain the same data set exclusive lock. As the name suggests, is a shared lock multiple transactions for the same data can be shared with a lock, you can access the data, but can only be read but not modified.

• Exclusive lock (X): to allow him to acquire an exclusive lock transaction update data, preventing other transactions made to share the same data set read locks and exclusive write locks.
  As the name suggests, an exclusive lock is not such a transaction acquires a data line exclusive lock and Other co-exist, other transactions can no longer acquire other locks that row, including shared locks and exclusive locks, but acquire an exclusive lock transaction is to read and modify data on the line.

• Intention shared lock (IS): Transaction intend to add rows of data rows shared lock before the transaction to a data line shared locks must obtain the IS lock on the table.

• Intent exclusive locks (IX): Rights intends to add to the data line row exclusive lock, the transaction must be obtained before his lock IX lock on the table to add a row of data rows.

• Description:
  1) shared locks and exclusive locks are row lock, the lock is intent table lock,
  application, we will only use the shared locks and exclusive locks, lock intent mysql internal use and does not require user intervention.
  2) For the UPDATE, DELETE and INSERT statements, InnoDB will automatically give involves collection of data plus exclusive lock (X-); ordinary SELECT statement, InnoDB not add any locks, the transaction may be displayed to the recording current shared locks or exclusively by the following statement lock.
  Shared lock (S): SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE.
  Exclusive lock (X): SELECT * FROM table_name WHERE ... FOR UPDATE.
  3) InnoDB row lock is achieved through the lock on the index entry to the index, therefore InnoDB row lock to achieve this characteristic means: only retrieve data through index conditions, only InnoDB row-level locking, otherwise, would use InnoDB tables lock! .

• For shared locks we may well understand, is that multiple transactions can only read data can not change the data, for exclusive lock on everyone's understanding may be some differences, I had just made a mistake, that line of exclusive lock lock data, other transaction can not read and modify the data line, in fact, not the case. Exclusive lock refers to a transaction in a row after data plus exclusive lock, other transactions can not be in it plus other locks. mysql InnoDB engine default modify data statements, update, delete, insert automatically to the data related to the plus exclusive lock, select statement default will not add any type of lock, if the rate of exclusive lock can use the select ... for update statement, plus share lock You can use select ... lock in share mode statements. Therefore, the increase is too exclusive lock data rows other transaction types that can not modify the data, we can not pass for update and lock in share mode locking way to query data, but can directly select ... from ... to query the data, because the common queries without any lock mechanism.

• Summary
  can be used to automatically update the operating principle of exclusive lock transaction and the transaction commits before releasing locks to prevent concurrent execution update, but the efficiency will be slower.
  By default insert plus a gap lock: http://book.51cto.com/art/200803/68128.htm ---- sometimes lock tables, and indexes and related transaction isolation. Locking gap of the new data, the new operations can not be written back. wait. If so then the default under high concurrency can be solved but taking into account the repeated insertion efficiency under high concurrency would be inappropriate.

Solution to the problem of actual transactions MYSQL high concurrency

1. First of all, multi-user concurrent users modify the same record, certainly after the submission of the results of the former will overwrite the submission.
   The locking mechanism can be used directly to solve, optimistic or pessimistic locking lock.
   Optimistic locking:
   that is, the database design field, a version number, each modification so +1, so when you submit the version number than before the submission that this is not a concurrent submitted,
   but there is a drawback is that only applications control, if there is a cross-application to modify the same data no way optimistic locking, pessimistic locking can be considered at this time.
   Pessimistic lock:
   it is the data directly in the database-level lock, similar to oralce used in select xxxxx from xxxx where xx = xx for update, so that other threads will not be able to submit data.
   In addition to locking manner may also be used to receive the locking way,
   the idea is to design a state flag in the database, the data before the user changes the state flag state is identified as being edited, so that other users to edit the entry when the recording system will find other user is editing,
   when its editorial request is rejected, similar to what you are performing a file in the operating system, then you want to modify the file, the system will remind you that the file can not be edited or deleted.
2. Secondly, it is not recommended at the database level locking, recommended by the server's memory locks (Lock primary key).
   When a user wants to modify the data of an id, the id into memcache to be modified, if the other user id of this trigger modify data, read memcache have the id value that prevents users from modifying.
3. In practical application, is not so large mysql concurrent read and write to the face, will be by means of "force", such as caching, read and write by the main separated from the library, sub-table, and other methods used to reduce the write queue concurrent read and write.

Examples spike

Total Stock: 4 Product
claimant: a, 1 th commodity b, 2 th commodity c, 3 th commodity
procedures are as follows:

beginTranse(开启事务)
try{
    $result = $dbca->query('select amount from s_store where postID = 12345');
    if(result->amount > 0){
        //quantity为请求减掉的库存数量
        $dbca->query('update s_store set amount = amount - quantity where postID = 12345');
    }
}catch($e Exception){
    rollBack(回滚)
}
commit(提交事务)	

• The above code is what we usually stock control code written, and most people would write so little seems, in fact, there are enormous loopholes.
  Access to the database is actually access to a disk file, a database table is actually stored on disk in a file, or even a file contains more than one table.
  For example due to high concurrency, currently there are three user a, b, c three users into this transaction, this time will produce a shared lock, so select the number of stocks when three users were found in four but also pay attention, mysql innodb result is found in version control, and then other users do not update until commit (that is not produced until the new version), the current user found the result is still the old version;

• Then the update, if three users simultaneously update arrives here, this time the update will update statement concurrent serialized, that is to arrive here at the same time is a row of three user sequence, executed one by one, and generates an exclusive lock, in this update statement before the current commit, others awaiting execution, after commit, generate a new version; so after the execution, the stock is certainly negative.

• However, according to the above description, we modify the code will not appear overbought, the code is as follows:

beginTranse(开启事务)
try{
    //quantity为请求减掉的库存数量
    $dbca->query('update s_store set amount = amount - quantity where postID = 12345');
    $result = $dbca->query('select amount from s_store where postID = 12345');
    if(result->amount < 0){
       throw new Exception('库存不足');
    }
}catch($e Exception){
    rollBack(回滚)
}
commit(提交事务)

In addition, more concise way:

beginTranse(开启事务)
try{
    //quantity为请求减掉的库存数量
    $dbca->query('update s_store set amount = amount - quantity where amount>=quantity and postID = 12345');
}catch($e Exception){
    rollBack(回滚)
}
commit(提交事务)