之前我们学习了RocksDB，但这还只是一个最基础的存储引擎。如果想把它在生产环境中用起来，还需要解决很多问题：
- 如何从单机扩展到分布式？
- 如何实现事务，并对事务进行并发控制？
- 用户接口能不能高级一点？不要只有get/set？
这次我们就来解决这三个问题。
如何从单机扩展到分布式
分布式的一大意义就是把单机放不下的数据分散到多个节点上。我们不妨按照key将不同范围的key分成多个region：比如[a-c]是region1，[d-f]是region2。然后用这种方法存储：
这样实现了一个基本的load balancing。一个Region里所有的数据分散存储在多个replica上，每个tikv实例只会存一部分的region。
当然分布式之后我们是要支持节点的动态增减的，具体细节暂时忽略
如何实现事务，并对事务进行并发控制？
事务是数据库系统中一个很重要的概念。比如我们的数据库要拿给银行去用，然后银行要把账户A的100块钱转给账户B，就需要执行如下操作：
if (A.balance>=100){
A.balance-=100;
B.balance+=100;
return(DB_OK);
}
else{
return(DB_ERROR);
}
当然在数据库系统中事务是用SQL实现的。
在事务的执行过程中，整段事务需要保证要么全都不执行，要么全都执行完，不允许出现执行到一半退出了的情况（即应该是个原子操作）。除此之外，像这样的约束条件还有很多，整理起来就是事务的ACID特性。
为了保证事务的执行能满足ACID特性，我们可以把事务的执行抽象成两种操作：commit（执行完整个事务）和rollback（比如事务跑到一半数据库崩溃了，重启后就要撤销之前执行到一半的工作，恢复到事务没执行的状态）。commit的实现很显然，直接执行就完事了...。为了实现rollback可以给数据库加上日志恢复技术，这样就可以恢复到过去的时间点了。
如果事务是串行执行的，那么到这里差不多就可以了。但假设我们的数据库要拿去进行双十一秒杀，