共计 1336 个字符，预计需要花费 4 分钟才能阅读完成。
写写并发管制:
只须要在写入（或更新）之前先获取行锁，如果获取不到，阐明曾经有其余线程拿了该锁，就须要一直重试期待或者自旋期待，直至其余线程开释该锁。拿到锁之后开始写入数据，写入实现之后开释行锁即可。这种行锁机制是实现写写并发管制最罕用的伎俩，前面能够看到 MySQL 也是应用行锁来实现写写并发的。批量写入多行的写写并发:
HBase 反对批量写入（或批量更新），即一个线程同时更新同一个 Region 中的多行记录。那如何保障以后事务中的批量写入与其余事务中的批量写入的并发管制呢？思路还是一样的，应用行锁。但这里须要留神的是必须应用两阶段锁协定，即：(1) 获取所有待写入（更新）行记录的行锁
(2) 开始执行写入（更新）操作
(3) 写入实现之后再对立开释所有行记录的行锁
不能更新一行锁定（开释）一行，多个事务之间容易造成死锁。两阶段锁协定就是为了防止死锁，MySQL 事务写写并发管制同样应用两阶段锁协定。Rowkey info:company info:role
greg cloudera engineer
Rowkey info:company info:role
greg restaurant waiter
两个并发写入申请同时进来，别离对一行数据进行写入。若没有并发管制，会呈现穿插状况。
Rowkey info:company info:role
greg restaurant engineer
读写并发管制：
事务 A 实现。
Rowkey info:company info:role
greg cloudera engineer
开始执行事务 B
Rowkey info:company
greg restaurant
此时来了读申请，info:role 还未更新实现。
info:role
waiter
读取到的数据为：
Rowkey info:company info:role
greg restaurant engineer
呈现数据不统一的状况。
多版本并发管制（MVCC 机制 -Mutil Version Concurrent Control）：
两个写事务别离调配了序列号 1 和序列号 2，读申请进来的时候事务 1 曾经实现，事务 2 还未实现，因而调配事务 1 对应的序列号 1 给读申请。此时序列号 1 对本次读可见，序列号 2 对本次读不可见。
+---+---+---+---+---+---+---+---+---+----+----+----+----+
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
+---+---+---+---+---+---+---+---+---+----+----+----+----+
所有事务都会生成一个 region 级别的自增序列。
1、如果事务 1 和事务 2 和事务 3 是操作的同一行，事务 1 实现，事务 2 未实现，事务 3 实现。此时读申请过去读取该行，只能读取到事务 1. 当事务 2 实现后能力读取到事务 3
2、如果事务 1~ 事务 12 操作的不同行，事务 1~ 事务 11 都未实现，事务 12 实现，此时读申请过去读取事务 12 的数据，仍旧会期待事务 1~ 事务 11 实现后能力读取事务 12 的内容，
所以此时读取到的是事务 12 对应行的之前的事务内容。因为目前还未做到对未实现的事务与以后读申请的内容比拟的性能，而且一个事务中可能蕴含多行。若要与以后申请比拟，
会比拟耗性能。