Since the frame is positioned initially distributed storage needed to support strong consistency, so how to implement a distributed transaction to be a big challenge. After learning of the implementation CockroachDB and TiDB such as databases, reference TiDB implementation of the decision, but rather than using optimistic way instead of using pessimistic locking mode, experience the way the transaction queuing conflict rather than restart the transaction.
One, two stages (2PC) submission process:
Referring to FIG example to illustrate the process:
- Business services begin transaction in the transaction coordinator node as it creates a new transaction instance (using HLC began as a transaction timestamp);
- 1 Add command coordinator transaction command list (if the first command is the master record as a transaction), while sending a command to RaftLeader Table 1, returns HLC (containing the current node is successful after lock state machine processing command Table 1 );
- Step 2 the same, but the master record which records the transaction for detecting the state of the transaction;
- Business services dealt with the notification submitted affairs coordinator, coordinator of HLC select the largest of all transactions as a transaction participant node to submit a time stamp;
- Services coordinator sends commands to submit transactions where the master record table RaftLeader 1, the notification in the table 1RaftGroup persistent state of affairs coordinator of the master record immediately return to operational service if the transaction is successfully submitted;
- RaftLeader master record transaction where the asynchronous notification submitted to RaftLeader affairs of other participants.
Each RaftGroup's Leader has a timer to detect state of affairs:
- If the detected command is a pending transaction master record, it is alive and coordinator communication detection;
- If the detected command pending master record non-transactional, communication detection RaftLeader the transaction state of the transaction where the master record.
Second, lock and conflict detection process:
Briefly explain the process flow of each state machine Raft node:
- When RaftLog Apply transaction commands, first detects the current lock list whether a conflict exists, the lock information is returned if there is no conflict persisted successfully unlocked; if a conflict exists is locked into the queue and persistent lock information, waiting for the lock transaction superior submit and then return;
- Apply within a transaction when submitting the command, find the corresponding command from the current lock list, persistent KV data write command corresponding to the underlying RocksDB, if the current lock there waiting queue, the queue will again try to turn the lock;
- 接收到读命令时，如果与当前锁冲突，则根据事务开始时间戳判断是通知冲突事务向后更新递交时间戳，还是忽略该冲突。
如果Raft节点意外崩溃后重新启动时，会先从存储加载锁信息恢复当前锁列表。
三、性能测试：
根据作者的经验，锁并不是影响并发性能的原因，冲突才是，所以做了个简单的并发测试。
1. 并发更新同一条记录（冲突激烈）：
虚拟机(I74C8G) wrk -t2 -c120 测试约3900tps
对比参照(MacbookPro13 I74C16G)：
- PostgreSql: 64线程: 调用640000次共耗时: 179295毫秒 平均每秒调用: 3569
- Cockroach: 64线程: 调用6400次共耗时: 90784毫秒 平均每秒调用: 70
2. 事务插入两条记录（无冲突）：
64线程: 调用64000次共耗时: 4008毫秒 平均每秒调用: 15968
四、小结：
本篇介绍了框架集成的分布式存储引擎是如何实现分布式事务的，当然还有很多优化待做（如单分区事务递交优化等）。如果您有问题或Bug报告，请留言或在[GitHub]提交Issue，另外您的关注与点赞将是作者最大的动力。