相比 CockroachDB 把 SQL 和 KV 集成在一个实例中，TiDB 本质上是一个更加纯正的 Spanner/F1 分层实现。提到 TiDB 架构的时候大家总是有点奇怪，为什么还有一个 TiKV，甚至还有一个 PD 模块。这里面稍微解释下，其中主要原因是 TiDB 既是产品名称，又是 GitHub上面的项目名称。从架构图上面大家可以看到，TiDB 数据库整个产品是分层的，上层无状态的计算层 TiDB 包括 SQL 解析、查询、优化执行、DDL 操作等方面；还有一层有状态的存储层 TiKV，提供分布式事务、多版本记录、一致性数据复制等功能。

这样的好处显而易见：首先，用户可以根据自身的业务，动态调整计算和存储节点，上层计算能力不够的添加 TiDB 节点，底层存储能力不够的添加 TiKV 节点，这样的架构处理业务会更加的灵活；第二点是分层有助于分模块测试，滚动升级以及并行开发，结合我们具体的实践来看，也确实获得了实实在在的好处。

TiDB 还有一个额外的模块叫 Placement Driver ，简称 PD ，j2直播，主要提供时间戳分配、数据库与数据路由的管理以及数据的自动负载均衡调度，是一个非常重要的模块。

进一步看下 TiKV 的架构图，我们从 MySQL Proxy 遇到的问题来入手分析。

首先，在数据存储方面，TiDB 的数据存储是按照Region来组织的，也就是在TiKV这层我们不需要关心实际上到底存储的是什么数据，这样对于数据的力度管理会更精细，以及数据的迁移都非常的友好。这种设计的好处是对于上层的 SQL 来说是完全透明的，用户可以完全无感知地使用 Join、Group By 和 Sort 等操作。所以从这个层面来看，对于用户的使用是非常简单和方便的。在很多业务场景下，如果之前使用的是 MySQL 数据库，基本上不需要修改一行业务代码，就可以直接使用 TiDB。

其次，在分布式事务方面，TiDB 采用的是 Percolator 的事务模型，可以认为是 2PC 分布式事务的一个优化实现，参考的也是来自于 Google 的 paper ，TiDB 在工程实现上做了大量的优化来提升效率。这个在后面的 PPT 里面有一些补充材料，大家感兴趣的可以作为参考。

刚才也提到了 DDL 的问题，这个算法同样来自于 Google ，是 F1 团队和威斯康星数据库实验室合作开发的，TiDB 同样实现了这个算法，并且添加了更多的 DDL 语法支持，以及分布式优化加速。所以，TiDB 可以保证在大规模的分布式集群场景下，针对海量数据的表的 DDL 操作也不会阻塞线上的数据库服务。从数据分布的层面来看， TiDB 基本上解决了 MySQL Proxy 遇到的所有问题。

再来看一下的数据的复制问题。在之前我们提到分布式系统里面最核心的问题主要是数据一致性问题，这个时候我们终于要讨论一下具有里程碑意义的一致性算法—— Raft 。

在现代的分布式系统中，基本上都能看到使用 Paxos 或者 Raft 来解决数据的强一致问题。关于 Paxos 和 Raft 算法相关的问题，我们的 Blog 里面都有介绍。这里大家可以先有个直观的印象，就是他们都是一致性算法， Paxos 是鼻祖， Raft 是 Paxos 的一个等价实现，但是更容易理解，更容易测试和更容易工程化。Raft更像是一个自适应的多副本的主从复制协议。对于每一次写请求， Raft 都会保证 Leader 写成功，这个图里面我们是标含了一个 Leader ，两个 follower其中一个写成功，它就认为大多数写成功并完全写成功。此时才会返回客户端，即使 Raft Group 的 Leader 挂掉了，在一个有限的时间范围内，会很快地选出一个新的 Leader 出来，继续提供服务。

有一个有意思的问题就是，它不同于刚才Master Slave的复制方案，他的follower之间可以选择一个任意的比较快的网络的副本，可以任意的进行写入，所以是一个自适应的复制方案。Raft 协议本身支持 Config Change ，增加一个新的节点，可以很容易地做副本数据分布的变更，而不需要停止任何服务。再结合 PD 对于全局路由信息和 TiKV 存储节点信息的管理，就可以选出合适的 TiKV 存储节点进行资源调度和自动故障恢复。所以从这个层面来看，基本上以 Spanner/F1 和 TiDB 为代表的 NewSQL 基本上解决了我们刚才提到的 MySQL Proxy 所提到的基本上所有的问题。

这是一个总结，供大家参考。