TiDB 在今日头条的实践，分布式关系型数据库分析

TiDB 是什么？

TiDB 是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适OLAP 场景的混合数据库。

TiDB怎么来的？

开源分布式缓存服务 Codis 的作者，PingCAP 联合创始人& CTO ，资深 infrastructure 工程师的黄东旭，擅长分布式存储系统的设计与实现，开源狂热分子的技术大神级别人物。即使在互联网如此繁荣的今天，在数据库这片边界模糊且不确定地带，他还在努力寻找确定性的实践方向。

2012 年底，他看到 Google 发布的两篇论文，得到了很大的触动，这两篇论文描述了 Google 内部使用的一个海量关系型数据库 F1/Spanner ，解决了关系型数据库、弹性扩展以及全球分布的问题，并在生产中大规模使用。“如果这个能实现，对数据存储领域来说将是颠覆性的”，黄东旭为完美方案的出现而兴奋， PingCAP 的 TiDB 在此基础上诞生了。

TiDB架构

TiDB在整体架构基本是参考 Google Spanner 和 F1 的设计，上分两层为 TiDB 和 TiKV 。 TiDB 对应的是 Google F1， 是一层无状态的 SQL Layer ，兼容绝大多数 MySQL 语法，对外暴露 MySQL 网络协议，负责解析用户的 SQL 语句，生成分布式的 Query Plan，翻译成底层 Key Value 操作发送给 TiKV ， TiKV 是真正的存储数据的地方，对应的是 Google Spanner ，是一个分布式 Key Value 数据库，支持弹性水平扩展，自动的灾难恢复和故障转移（高可用），以及 ACID 跨行事务。值得一提的是 TiKV 并不像 HBase 或者 BigTable 那样依赖底层的分布式文件系统，在性能和灵活性上能更好，这个对于在线业务来说是非常重要。

TiDB 的事务模型

TiDB 的事务模型通过参考了 Google 的 Percolator。该论文发表于 2010 年，是描述 Google 在 BigTable 上的构建 ACID 跨行事务框架用于保证索引更新的一致性。算法的核心思想是两阶段提交，但是传统的分布式两阶段提交的问题是单点的事务管理器没法扩展，会成为整个系统的瓶颈，Percolator 使用了一个两级锁的机制实现了去中心化的事务管理器，使得整个系统的可扩展性大大提升。

TiDB如何解决传统数据库的痛点

任何企业，如果使用传统的单机关系型数据库，在数据量持续增长下，或者对业务的可用性有严格要求的情况下，可能都会面临单点故障和单点容量限制的问题，这个问题最近几年在互联网行业尤其突出，目前来说除了上面提到的分库分表和中间件也并没有其他的方案解决，几乎苦不堪言。

TiDB 基于更先进的 Raft 算法来实现了存储层的水平扩展基础上加上了分布式事务，构建了完整的 SQL 查询层，在保证不丧失 ACID 事务的前提下，支持 JOIN ，子查询等复杂查询，另外对外暴露 MySQL 接口，让用户几乎在无侵入性的前提下，解决大量结构化数据的存储问题。考虑到传统行业和互联网行业的代差大概在 3 年左右，另外这个时间在不断的缩短，最近随着 TiDB 趋于稳定，越来越多的互联网在使用 TiDB ，相信未来会成为扩展数据库的一个新的主流选择。

TiDB 在今日头条的实践讲解（分布式关系型数据库、高并发、 TP 和 AP 、分布式事务）

1. 分布式关系型数据库

2. 大数据量下如何进行高并发读写

3. 如何做到更细粒度的扩缩容

4. 如何实现 TP 和 AP 的融合

5. 如何解决分布式事务的单点问题？