分布式数据库, 高级形态 分布式事务数据库

两条路:

1. 关系型数据库 --> 分区后的割裂的关系型数据库 ( 同步有很多方案 ,基于整个库)--> 大统一数据库(mongodb,腾讯的开源,paxos 高可靠

2. key-value 数据库 --> 含 mysql 多查询的 数据库 (phoenix)

怎样打造一个分布式事务数据库——rocksDB, raft, mvcc，本质上是为了解决跨数据中心的复制

内有 1. Google Spanner / F1 2. TiDB and TiKV

1.单机数据库

2.从最初的 mysql 的 client 分库分表. 到工具类. 比如阿里的Cobar、TDDL，后来社区基于Cobar改进的MyCAT，360开源的Atlas等，都属于这一类中间件产品。在中间件这个方案上有一个知名的开源项目是Youtube的Vitess，这是一个集大成的中间件产品，内置了热数据缓存、水平动态分片、读写分离等，但这也造成了整个项目非常复杂。

   从不能数据迁移到能够自动迁移,自动扩容.  到主从切换. 类似 codis.

3. 到能够配置二级索引.(暂时无)

后面 nosql 兴起 , lsvm 树.

到 nosql 的二级索引 .  hbase的 phoenix 基于 hbase 的二级索引

Phoenix二级索引 http://blog.csdn.net/d6619309/article/details/50358592

http://blog.csdn.net/yangzhiyouvl/article/details/52280847

华为二级索引实现 http://itindex.net/detail/52091-%E5%8D%8E%E4%B8%BA-hbase-%E7%B4%A2%E5%BC%95

原 Hbase 学习（九） 华为二级索引（原理）

 

4. 能够自动水平扩容( 不是数据迁移 , 自动分裂, 类似 mysql 的归档. 需要业务端对 rowKey 的设计 )

HBase Region分裂实现

5. 能够事务处理

   先说下分布式事务架构:

         分为 数据库事务接受者 和  数据存储服务器

   

       数据库事务接受者 A 和数据库事务接受者B 接受到两个事务.

       各自操作在数据存储服务器1上的数据 people.

       A开启一个事务 t1, B 开启一个事务 t2.

      

   谷歌

Google的Spanner(看这 和这)和Percolator(看这和这)都是搞了一个全局时钟来解决，区别在于Percolator的全局时钟就是基于固定的一台服务器产生，所有的事务获取commit时间戳都问这个全局时钟服务器要，自然保证了单调递增。问题，显而易见，单点，性能，扩展性。Spanner利用原子钟和GPS接收器，实现了一个较为精确的时钟，这个时钟叫做TrueTime，每次调用TrueTime API返回的是一个时间区间，而不是一个具体的值，这个TrueTime保证的是真实时间(absolute time/real time)一定在这个区间内，这个区间范围通常大约14ms，甚至更小。

Lamport timestamps [2]

True Time

前面我们说了，NTP是有误差的，而且NTP还可能出现时间回退的情况，所以我们不能直接依赖NTP来确定一个事件发生的时间。在Google Spanner里面，通过引入True Time来解决了分布式时间问题。

Spanner通过使用GPS + Atomic Clock来对集群的机器进行校时，精度误差范围能控制在ms级别，通过提供一套TrueTime API给外面使用。

TrueTime API很简单，只有三个函数:

Method	Return
TT.now()	TTinterval: [earliest, latest]
TT.after(t)	true if t has definitely passed
TT.before(t)	true if t has definitely not arrived

首先now得到当前的一个时间区间，spanner不能得到精确的一个时间点，只能得到一段区间，但这个区间误差范围很小，也就是ms级别，我们用ε来表示，也就是[t - ε, t + ε]这个范围，

假设事件a发生绝对时间为tt.a，那么我们只能知道tt.a.earliest <= tt.a <= tt.a.latest, 所以对于另一个事件b，只要tt.b.earliest > tt.a.latest，我们就能确定b一定是在a之后发生的，也就是说，我们需要等待大概2ε的事件才能去提交b，这个就是spanner里面说的commit wait time。

可以看到，虽然spanner引入了TrueTime可以得到全球范围的时序一致性，但相关事务在提交的时候会有一个wait时间，只是这个时间很短，而且spanner后续都准备将其优化到 ε < 1ms，也就是对于关联事务，仅仅在上一个事务commit之后等待2ms之后就能执行，性能还是很强悍的。

但spanner有一个最大的问题，TrueTime是基于硬件的，而现在对于很多企业来说，是没有办法搞定这套部署的。所以如果Google能将TrueTime的硬件设计开源，那我觉得更加造福社区了。

作者：siddontang
链接：http://www.jianshu.com/p/8500882ab38c
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

7. 能够多活

    写标识: 跟着用户走,商户走,操作者走.  如果这是一个用户流量,对应的表和 id 是用户自己.那么就走本单元数据库.

附录:

 [1]细说分布式数据库的过去、现在与未来  https://yq.aliyun.com/articles/80456

[2] 分布式系统理论基础 - 时间、时钟和事件顺序