导语
市场上有很多数据库产品，如Oracle、MySQL、SQLServer、NoSQL、NewSQL等，那么目前数据库圈最火的分布式关系型数据库之一TiDB你了解吗？相信很多同学以前听说过TiDB，也知道是一款国人研发的数据库，但你知道TiDB到底是如何实现的？它跟其他数据库产品相比，它的核心优势是什么？
此次夜校分享，xiaoyu向大家介绍了数据库发展史、TiDB 设计、架构及生态及TiDB在得物的应用。
数据库技术发展演进
2008年以前
2008 年以前应用最为广泛的是单机关系型数据库（SQL），能很好的解决复杂的数据运算及表间处理，多用于银行、电信等传统行业复杂业务逻辑场景中，以 Oracle 为代表。此类数据库挑战在于成本高，随着数据量增加，只能通过购买更贵更好的服务器；无法线性扩容，海量数据下处理能力大幅下降。
2008年至2013年
2008年至2013年，随着搜索/社交的发展，数据量爆发增长，传统数据库高成本，无法线性扩容问题日益突显；分布式及分布式非关系型（NoSQL）开始快速发展，如 MongoDB，HBase。但此类数据库的局限在于无法处理交易类数据及复杂业务逻辑的特性，限制其在非互联网领域的发展。
2013年以后
2013年以来，有个新的概念为分布式关系型数据库（NewSQL），它是兼具NoSQL扩展性又不丧失传统关系型数据库ACID特性的分布式数据库。随着互联网向银行、电信、电力等方向的渗透，传统行业数据量迅速提升，需要同时满足低成本、线性扩容及能够处理交易类事务的新型数据库，大数据的存储刚需不可避免。NewSQL的挑战在于，它是基于 Google Spanner/F1 论文，未开源它的代码及技术细节，是基础软件最前沿的领域之一，技术门槛最高。NewSQL 代表产品有Spanner/F1(未开源)、CockroachDB(开源)和TiDB(开源)。
TiDB 设计及架构
与传统的单机数据库相比，TiDB 具有以下优势：
- 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容
- 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL
- 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明
- 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账
- 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景
图｜TiDB整体架构
TiDB Server
SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
PD Server
整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。
TiKV Server
负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
TiKV如何完成自动扩容？步骤如下：
1、比如当前的架构是4台 TiKV 节点，假设其中 Node1 的负载较高，我们要把 Region1 迁移出到新节点。
2、此时我们加入一台 Node5用于扩容集群
3、此时 PD 将Region1 的 leader 迁移至 Node2
4、在新的 Node5上新增一个 Region1的副本，复制完成后会将 Leader 角色迁移至 Node5。
5、然后将 Node1上的 Region1 删除掉，本次扩容就结束了。
TiKV - 异地多数据中心
两地三中心架构，即生产数据中心、同城灾备中心、异地灾备中心的高可用容灾方案。在这种模式下，两个城市的三个数据中心互联互通，如果一个数据中心发生故障或灾难，其他数据中心可以正常运行并对关键业务或全部业务实现接管。相比同城多中心方案，两地三中心具有跨城级高可用能力，可以应对城市级自然灾害。
TiDB 分布式数据库通过 Raft 算法原生支持两地三中心架构的建设，并保证数据库集群数据的一致性和高可用性。而且因同城数据中心网络延迟相对较小，可以把业务流量同时派发到同城两个数据中心，并通过控制 Region Leader 和 PD Leader 分布实现同城数据中心共同负载业务流量的设计。
该架构具备高可用能力，同时通过 PD 调度限制了 Region Leader 尽量只出现在同城的两个数据中心，这相比于三数据中心，即 Region Leader 分布不受限制的方案有以下优缺点：
优点：
- Region Leader 都在同城低延迟机房，数据写入速度更优；
- 两中心可同时对外提供服务，资源利用率更高；
- 可保证任一数据中心失效后，服务可用并且不发生数据丢失。
缺点：
- 因为数据一致性是基于 Raft 算法实现，当同城两个数据中心同时失效时，因为异地灾备中心只剩下一份副本，不满足 Raft 算法大多数副本存活的要求。最终将导致集群暂时不可用，需要从一副本恢复集群，只会丢失少部分还没同步的热数据。这种情况出现的概率是比较小的；
- 由于使用到了网络专线，导致该架构下网络设施成本较高；
- 两地三中心需设置 5 副本，数据冗余度增加，增加空间成本。