想必看到此篇的同学对于newSQL已经不是很陌生了，那么直接进入今天的主题：
mysql的问题在哪？
一、不能通过mysql的server把InnoDB变成一个分布式数据库。
因为mysql生成的执行计划是个单机的
二、一个分布式的plan执行起来很复杂且低效。
比如使用分布式方案Proxy，因为它不支持分布式的transaction，也不支持跨节点的join
三、异步或半同步复制
因为有时候数据出问题你不知道是否应该切换节点，因为异步的方式会导致一部分数据“还在路上”。尤其是对于多数据中心的复制和数据中心的容灾。
而NewSQL真正发展起来是在2014年末到2015年初的时候，Raft论文发表之后，真正的NewSQL理论基础就基本确立了。
那么从技术实现的角度分析，为什么这样的技术会诞生呢？它又能解决哪些过去的产品解决不了或者不是最优方案的场景呢？
首先，举一个范围查询的例子，如果要查找一个班级里成绩在80-90之间的学生，那么通过KV的API的要很麻烦的，但是SQL的优化器就很容易解决此类问题，写一句SQL就可以搞定。
其次是高可用，未来的系统肯定是要设计成Auto-Failover的，即自动恢复，需要人工去干预的容灾系统不是好厨子。
然后针对业务还要说几点：
比如按照ID去分库分表，比如使用一致性哈希去指导节点均衡。如果问题上升到了一定的复杂度，如果再使用应用层的程序逻辑来决定数据流向，那么未免有些low。以后的系统肯定是要设计成完全解耦的，即应用层只负责处理业务逻辑，而数据流转全部交由基础设施层来决策。
下面先介绍下Google Spanner / F1，
http://www.valleytalk.org/wp-content/uploads/2012/10/Spanner-Chinese.pdf
这是厦大老师翻译的，非常棒的一篇论文。
现在有个想法突然冒出来：为什么工业界的论文可以诞生优秀的产品，而学术界却一直默默无闻呢？答案在下面链接中能找到：
http://news.zol.com.cn/647/6477905.html
TiDB and TiKV
首先看下他的架构模型：
其中TiKV对应的事Spanner，而TiDB对应的是F1。
F1强调分布式SQL层实现的方式，这里最重要的一点是它兼容了MySQL协议，对于迁移来说实在太合适不过了。
再来看下逻辑视图：
这个系统共分了六层，最底下的实现是RocksDB（基于LevelDB实现，具有高速写入的特性），在上层的Raft并没有实现Transaction，因为此时他需要保证写入的数据复制了足够多的副本。之后在分布式事务满足了之后再加上SQL层。
然后讲下扩容：
这个很容易理解，每个Region的所有副本组成一个raft group，所以一共有三个raft group，在每个Node上面数据的分布较均匀。因为每个region都分布在了不同的节点上，就算一个节点宕机，其他节点里的每个region也会通过raft的选举策略选出那个备份作为新的leader，将原leader中reply但没有commit的log做一个commit+apply，具体细节可以参考raft官网：https://raft.github.io/#implementations
最后说下分布式事务模型：
大家应该都知道，分布式事务的实现基本都是2PC的，也有2+xPC的，1PC很难做到，除非你在级别上做弱化，如果隔离级别要求很高，1PC是不太好做的。TiDB有一个TiKV driver，可以很好的将SQL语句落到存储层再映射到KV上面。对外的编码格式是Google Protocol Buffer。