# Distributed Transaction 


![left](./student-guide/diagram/03-distributed-01-01.png)
------------------------------------------------------------
After learning about RocksDB, which is closely related to TiKV's database persistence, let's take a look at another TiKV feature implement, which is distributed transaction.

If we want to operate on multiple rows of data at the same time, and the data falls on different regions (maybe even on different TiKV), we need distributed transaction to ensure consistent operations.

The problem to be solved by distributed transaction is, for example, we need to < 1，Tom > change to < 1，Jack >, < 2，Andy > to < 2, Candy > (< 员工编号，员工姓名 > key - value) at the same time, < 1，Tom > and < 2，Andy > Stored in a different region or even a TiKV, then when the operation < 1，Tom > is completed, it may appear, change to < 1，Jack > success, < 2，Andy > < 2, Candy > failure, or vice versa. This breaks the atomicity of transaction. Let's take a look at how TiDB solves this problem.

TiDB refers to Google's Percolator and optimizes 2PC (2-phase commit) to provide distributed transaction support. Let's take a look at the concrete implement below:
  - The entire database needs to have a globally unique and monotonically increasing timestamp to identify the start time of the transaction start timestamp (startTs/start_ts) and commit time commit timestamp (committs/commit_st), which The timestamp is provided by PD.
  - Percolator uses the three column families in the RocksDB instance, the column family (CF), to store data, transaction, and lock information. They are: Lock, Default, and Write. For example, if we write < 3, Frank >, we will record the lock (CF) with key = 3 in the Lock column (CF), and put the values “3" and “Frank” in Default. If committed successfully, it will be recorded in the Write column family (CF), and delete it Unlock information.

Next, we'll take a look at the specific process of Percolator.