MySQL 5.7 testing environment
Premised on the notion
- Database concurrency of three scenarios
- Optimistic and pessimistic locking clarification
Pessimistic locking
- What is pessimistic lock?
- Pessimistic locking achieve
- Pessimistic locking advantages and disadvantages
Optimistic locking
- What is the optimistic locking?
- Optimistic locking implementation
- The advantages and disadvantages of optimistic locking
MVCC Multi Version Concurrency Control
-
What is MVCC?
to sum up
- Optimistic and pessimistic locking choices
- OCC,PCC,MVCC
Reference material
Premised on the notion
Database concurrency of three scenarios
Database concurrency scenarios, there are three, namely:
读-读: There are no problems, we do not need concurrency control读-写: Isolation problems, you may experience dirty reads, phantom reads, non-repeatable read写-写: Lost update problem may exist, such as the loss of first class update, the second lost updates
Optimistic and pessimistic locking clarification
- Either pessimistic or optimistic locking lock, their nature is not a specific database lock concept, but we define it, is used to describe the idea of locking two categories. So with classified design, we will be able to carry out specific categories of database locks through this category;
- However, optimistic locking in a database called more inclined to optimistic concurrency control (OCC), pessimistic locking called pessimistic concurrency control (PCC), there is a control different from the optimistic pessimistic locking called MVCC, multi-version concurrency control
- They should not row locks optimistic and pessimistic locking in the database, table lock, exclusive lock, shared lock confused, they are not a dimension of things; the former is thought a lock, which can be carried out in optimistic approach depending on whether or pessimistic locking ideological classification
- Optimistic and pessimistic locking concept not only exist in the database field, it can be said there is thread-safe, concurrent existence of almost every scene optimistic and pessimistic locking application scenarios, such as in Java has a concrete implementation optimistic and pessimistic locking thoughts; but optimistic and pessimistic locking concrete realization of different areas have different problems to be solved may be different
So if people ask what you are optimistic and pessimistic locking, you do not say it is a specific lock, it's just A lock design, he can have a lot of specific category
Pessimistic locking
What is pessimistic lock?
In a relational database management system, pessimistic concurrency control (also known as "pessimistic locking", Pessimistic Concurrency Control, the abbreviation "PCC") is a method of concurrency control; pessimistic locking means is to adopt a pessimistic negative attitude, default when data is accessed outside world, would have a conflict, so the whole process of data processing are used in the state locked to ensure the same time, only one thread can access the data to achieve data exclusivity; typically, the database is pessimistic lock to achieve using locking mechanism of the database itself provides.
Pessimistic concurrency control database can be solved read - write collision and write - write conflicts, refers to a locked way to solve the
Pessimistic locking achieve
Typically, the database is to use pessimistic locking lock the database itself provided to achieve the
- To access data outside a bar, then it is necessary first of all to lock the database application data (some kind of lock)
- If successful, then it can manipulate the data during its operation, other clients can no longer operate the data of the
- If you get a failure, then the same time on behalf of other clients have access to the lock, it must wait for another client releases the lock
Of course, the database provides a lot of locks, lock each database provided is not always the same, so the specific situation depends on what lock, such as row locks, table locks, etc.
Advantages and disadvantages
Pessimistic concurrency control is actually a "lock and then take the first visit," the conservative strategy, to provide a guarantee for the security of data processing. But in terms of efficiency, processing database locking mechanism will result in additional expenses, as well as increase the chance of a deadlock; in addition, the read-only transaction does not occur because of a conflict, it is not necessary to use a lock to do so can only increase the load on the system; there will be reduced parallelism, if a transaction locks a row of data, other transactions must wait until they have finished processing the transaction can handle that number of lines
Advantages:
suitable for use in a write once read many fewer concurrent environment, although they can not maintain a very high performance, but optimistic locking not provide better performance under the premise, can achieve data security
drawbacks:
the lock will increase overhead , can guarantee the security of data, but low data processing throughput, not suitable for use in reading less occasion to write
Optimistic locking
What is the optimistic locking?
In a relational database management system, the optimistic concurrency control (also known as "optimistic locking", Optimistic Concurrency Control, the abbreviation "OCC") is a method of concurrency control; Optimistic locking (Optimistic Locking) is relatively pessimistic locking, the optimistic locking is to assume that even in a concurrent environment, operating outside of the data generally will not cause conflict, so do not go lock (not so optimistic locking a lock), but rather to submit updated data in time, will formal conflict or not the data to detect a conflict if found, then let the return conflicting information, allowing users to decide what to do next, such as retrying until it succeeds; optimistic lock on the database, not the use of the database itself lock to achieve, perhaps using some logic to achieve the realization of the idea to do optimistic locking
Optimistic concurrency control of database to be solved is written in the database concurrency scenarios - write conflict, refers to a lock-free way to solve the
CAS ideas
In fact, concrete realization of the database optimistic locking is almost just like the idea of the algorithm in Java CAS optimistic locking is used in the same, so we can learn from the design database optimistic locking CAS algorithm:
CAS instruction called the Compare and Swap, it is a system instruction set, the entire CAS operation is an atomic operation is indivisible. From the detailed description, we can see so CAS operations:
CAS instructions require three operands, namely memory location V, the expected value of the old A, and the new value B. When the CAS instruction execution, when the present value of the built-in position V is equal to the old read our expected value A, the processor B will be the new value to update the value of the built-in position V. Otherwise, it does not perform the update, but whether or not the updated value V, will return the old value of V.
We put the code level up popular understanding i = 2; i ++, that is:
- Thread is first read from a memory location in the V value, and stored as the expected value of the old A. (v = 2, a = 2)
- Since then i ++ To operate, the system will compare the present value of V memory location is compared with the old V both the expected value A =? A.
- If they are equal, B = i ++ = 3, the new value of the memory location V B will be updated, so the value of the memory location V becomes a value B, 3
- If not equal, then the other threads modified value V memory location, such as the value of the thread before the thread 2 1 i to modify the value of i is updated. Therefore Thread 1 updates the variable i failed. But the thread does not hang, but returns a failure state, the calling thread to wait to decide whether to retry or other operations. (Usually retried until it succeeds)
Optimistic locks for the database layer is also similar to the code level to achieve
Database optimistic locking implementation
Generally optimistic locking realize there are two, but their inherent design of the CAS are:
- Method 1: Use data version (
version) to achieve
- This is the most common kind of optimistic locking implementation. What is a data version of it? Is to add a field in the table as a version identifier of the record, such as call version, each write operation will allow the recording of version + 1.
- So when we read the data (including version), make updates, time to submit, version will get to talk to the database made in version comparison is consistent, if the agreement on behalf of this time, no other threads this data is also modified to give updates, while version + 1; if not, it means at this time, and the record is modified by other threads, and considered to be obsolete data returned conflicting information, allowing users to decide on the next action such as retry (re-read the latest data, another update)
- update table set num = num + 1 , version = version + 1 where version = #{version} and id = #{id}
Second way: using the timestamp ( timestamp) to achieve
- Table to add a field, the name does not matter, such as call update_time, field types using the timestamp (timestamp)
- Principles and a consistent way, but also check whether the timestamp of the current data in the database and update their own front to take the same timestamp when updating submitted if agreement represents the moment there are no conflicts, you can submit updated and the updated time stamp the current time, or is this period of time there are other threads also update submitted, returned conflicting information, the user waits for the next action.
- update table set num = num + 1 ,update_time = unix_timestamp(now()) where id = #{id} and update_time = #{updateTime}
But we must note that, while thinking to achieve optimistic locking, we have to make sure more atomic CAS operation, ie version of the database to obtain the data, compare the data to get the database to get the version with the previous version, and perform data update these operations must be executed consistent with atomic complex operation; so if it is a SQL database, then we will guarantee more SQL operations in the same transaction
Advantages and disadvantages
Pros:
In a small concurrency scenarios of reading and writing, to avoid database locking overhead and improve response performance Dao layer
in fact in many cases, we orm tool has achieved with optimistic locking, these methods do not necessarily need us human to make things
Cons:
the case in write once read many less concurrency scenarios, namely intense competition in writing operation, CAS will lead to multiple retries, the collision frequency is too high, resulting in higher overhead than pessimistic locking
MVCC Multi Version Concurrency Control
What is MVCC?
What is MVCC?
MVCC
MVCC, full nameMulti-Version Concurrency Control, namely multi-version concurrency control. MVCC is a method of concurrency control, usually in database management systems, concurrent access to the database, implement transactional memory in a programming language.
MVCC in MySQL InnoDB implementation is mainly to improve the performance of concurrent database, a better way to deal with conflict reading and writing, so even if there is a conflict to read and write, can do without locking, non-blocking concurrent read
What is the current snapshot read and read?
What is the current snapshot read and read in the MySQL InnoDB?
- Current Reading
Like select lock in share mode (shared lock), select for update; update, insert, delete (exclusive lock) is a kind of current read these operations, why is it called the current read? That is, it reads the latest version of the record, but also to ensure that other concurrent transactions can not modify the current record is read, the reading record will be locked
- Snapshot Reading
Like an unlocked select the snapshot operation is read, that is an unlocked non-blocking reads; snapshot isolation level on the premise that reading is not a serial level, the snapshot will be read at the level of degradation to the current serial read; reading was the result of a snapshot the situation is complicated by improved performance considerations, based on a snapshot reading is based on multi-version concurrency control, that MVCC, can be considered a variant of MVCC row lock, but it is, in many cases, to avoid locking operation, reducing overhead; since it is based on multiple versions, namely reading the snapshot may not necessarily read the latest version of the data, but there may be a history of previous versions
To put it plainly read snapshot MVCC is thinking in MySQL specific functions to achieve non-blocking reads, the entire multi-purpose MVCC concurrency control is not locked to read and write conflicts, improve concurrent read and write performance, and this means that reading is a snapshot of reading, instead of the current reading, current reading is actually a lock operation is to achieve pessimistic locking
to sum up
Optimistic and pessimistic locking choices
Choice of optimistic and pessimistic locking is mainly reflected in written - written
in pessimistic locking and optimistic locking choices, we can consider the following three factors:
- Response time : If the Dao layer requires a very high response speed, especially in reading and writing little scenes, then we can use optimistic locking scheme to reduce the overhead of database locks, provide concurrency
- The frequency of collisions : If the conflict is very high frequency, then we can use pessimistic locking, to ensure the success rate; after all, if the frequency of collisions large, optimistic locking will require multiple retries to be successful, may significantly increase the cost of
- Retry the price: If the retry large expense, for example, the code retry process is very time consuming, so this time I do not recommend the use of optimistic locking, and not as pessimistic lock directly on to the refreshing
So we know:
In reading, more writing less, CAS competition is not so intense, we can use optimistic locking strategy to reduce database locking overhead, improve database concurrency response
in a write once read many small scenes, because it will produce a large number of CAS competition, and heavy the next test cost is relatively high, we do not propose to adopt a strategy optimistic locking, pessimistic locking or direct use of database locking bar
Relations OCC, PCC, MVCC three
- Pessimistic concurrency control (PCC) is a method used to solve the read - write collision and write - write conflicts of locking concurrency control, for each operation are locked, at the same time, only to get the lock of the transaction in order to have the right to the data operation, did not get a lock transaction can only wait for the other transaction to release the lock; it can be solved dirty reads, phantom reads, non-repeatable reads, lost updates first class, second class lost update problem
- Optimistic concurrency control (OCC) is a method used to solve the write - write conflict lock-free concurrency control that contention between transactions not so much, so first make changes before committing the transaction, the transaction began after the check, there is no new submit changes, if not submission, if you give up and try again. Optimistic concurrency control similar spin lock. Optimistic concurrency control is suitable for low data contention, less write-conflict environment; can not be resolved dirty reads, phantom reads, non-repeatable read, but lost update problem can be solved
- Multi-version concurrency control (MVCC) is a method used to solve the read - write conflict lock-free concurrency control, which is a one-way distribution growth for the transaction timestamp, save a copy of each modified version that is associated with the transaction timestamp, read read-only snapshot database before the transaction began. So that when the read operation would not blocking write operation, the write operation is not blocking readers; not only can improve concurrency, can also solve dirty reads, phantom reads, non-repeatable read transactions and other issues. Lost update problem except
Overall, MVCC database is dissatisfied with the emergence of pessimistic locking to solve read - write conflict problem, the solution proposed because performance is not high, it is in the database, we can form two combinations:
MVCC + 悲观锁
MVCC resolve conflicts write, write pessimistic locking resolve conflictMVCC + 乐观锁
MVCC resolve conflicts write, write optimistic locking resolve conflict
This combination would be the greatest degree of concurrency to improve database performance, and resolve conflicts to read and write, and write about the problems caused by conflict
