Transaction implementation of the database and ACID properties

This paper briefly describes the concept of transaction and the Acid property of the author, and briefly introduces the implementation of these four properties in the database.

A transaction, in essence, is a set of sequential logical operations initiated by a person to accomplish one thing, and all its changes should not be visible or affected to other people until the whole thing is done. And after the end of the transaction, all its changes must be "all", "immediately" visible to other people.
Atomicity: Refers to a set of operations, or all success, or fail, there is no intermediate state.
Consistency: That is, when a transaction commits or rolls back, the state of the data is the same for other people. Take the transfer as an example, assuming that the ABC three accounts each have 100 yuan, then no matter how to turn, the overall system total amount is always 300, money will not generate or disappear.
Isolation: The effect of concurrent transactions at the time of execution to look like serial execution, often referred to as serializable scheduling. Isolation and consistency are tightly linked.
Transactions in the database are read-only transactions and write transactions, and there is no data modification between read and read transactions, which can be directly parallel. Two write transactions at the same time modify a record can be guaranteed by row lock serial. The complex is the relationship between the read transaction and the write transaction.
There are four isolation levels between read transactions and write transactions, and the difference between different isolation levels is that the granularity (range) of locks is different, the larger the range, the lower the parallel efficiency, and the higher the efficiency of parallelism. Here commonly used locks, mainly can be summed up in the following two kinds: 1, read and write lock 2, exclusive lock
READ UNCOMMITTED: In fact, there is no lock, the middle state of the data is likely to be read by other people.
Read Committed: Implemented by a read-write lock, the read lock is freed after each query, so that other people may change the data that freed the read lock, and the current transaction can read the data that has been modified by others. So one of the data that a person reads in a transaction, maybe the next time the read becomes another data, that is, non-repeatable read.
Repeatable READ: is also a read-write lock implementation, but the read lock will block other people's writing. As a result, the data read in a transaction is locked, and others have no way to change them, enabling repeatable reads.
Although the lock realizes serializable scheduling, the locking efficiency is low. In order to improve the performance of multi-threaded concurrency, people have designed MVCC. The so-called MVCC refers to each person in the transaction will first apply for a transaction ID, the ID is self-increment, each transaction has its own unique ID, while the global maintenance of a maximum committed ID. This allows each write transaction to generate an ID, some to generate an ID when the transaction is turned on, and some to generate the ID when the transaction commits. When each read transaction is turned on, the ID of the transaction is read atomically, and if only data that is less than or equal to its transaction ID is read, the semantics of the implementation are repeatable reads. If you read data that is less than or equal to the global ID, it corresponds to read committed.
Finally, serialization is the order of all operations, usually a global lock lock.
Persistence: means that after a transaction is executed, it cannot be lost. In general, using the Wal method, the operation is recorded in advance to the log to ensure that the situation can be restored before the operation of the disk to brush.