背景

特点

TiDB产品架构

TiKV

• TiDB 使用 RocksDB 作为它的存储引擎。（以便不同 Region 的写入可以合并在一次 I/O中）

• 在 TiKV中，数据是以 key-value的形式行式存储的，其中 key-value pair 按照key的二进制顺序有序，即找到一个key 的位置后，可以找到它的next 来递增地获取比这个key 大的key-value。

• TiKV 将 key 有序存储后，根据 key 的 range 分片，某一段连续的 key 都保存在一个存储节点上，这样一段连续的 key 叫做 region（域）。

• 当某个Region的大小超过一定限制（默认是144MB）后，TiKV 会将它分裂为两个或者更多个 Region，以保证各个 Region 的大小是大致接近的，这样更有利于 PD 进行调度决策。同样的，当某个 Region 因为大量的删除请求导致 Region 的大小变得更小时，TiKV 会将比较小的两个相邻 Region 合并为一个。

• 一个region的多个 replica 保存在不同的节点上，构成一个 Raft Group。根据 raft 协议，其中一个拥有最新日志复制的副本会被选举为 leader，其它的副本作为 follower（默认3副本）。由leader进行读写操作，再复制给follower，确认完成后提交。

• 当PD 需要把某个 Region 的一个副本从一个 TiKV 节点调度到另一个上面时，PD 会先为这个 Raft Group 在目标节点上增加一个 Learner 副本（虽然会复制 leader 的数据，但是不会计入写请求的多数副本中）。当这个 Learner 副本的进度大致追上 Leader 副本时，Leader 会将它变更为 Follower，之后再移除操作节点的 Follower 副本，这样就完成了 Region 副本的一次调度。

• 以region为单位，创建多个replica（副本），每个 replica 之间，通过 Raft 协议来达到数据的一致性。

• TiKV 基于 Google Spanner 架构支持多版本控制（MVCC）

PD

• 存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）。
• 对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）。
• 分配全局唯一且递增的事务 ID。

• 一个 region 的副本数量正确。
• 一个 raft group 中的多个 replica 不在同一个位置（服务器）。
• 副本在 TiKV 节点之间的分布均匀分配。
• Leader数量在 TiKV 节点之间均匀分配。
• 访问热点数量在 TiKV 节点之间均匀分配。
• 各个TiKV 节点的存储空间占用大致相等。
• 管理节点状态，包括手动上线/下线节点，以及自动下线失效节点。
• PD定期收集 TiKV 节点与 leader 副本的信息信息，判断调度策略（增加副本、删除副本、转移副本）。

TiDB

中间件 SQL 解析

其它组件

备份恢复

• 逻辑备份工具 Mydumper
• 数据导入工具 Loader
• 增量数据导入工具 Syncer

数据迁移

• 数据同步工具 Data Migration
• 全量数据高速导入工具 TiDB Lightning

其它工具

• 校验数据是否一致并提供修复的工具sync-diff-inspector
• 用于收集 binlog 的 TiDB Binlog
• 解决 HTAP 需求的 TiSpark
• 各种命令行工具。

对比与分析

TiKV优势与劣势

优势

• 运维成本低：TiKV 通过 raft 协议数据复制，用户不需要像搭建 MySQL 主从复制关系那样，搭建复制 关系，宕机后需要人工介入，将数据一致后，重新启动服务。但现在 MySQL5.7 支持基于 paxos 协议的 MGR 复制方式，也可以通过内部选举来达到数据一致。
• 不需要配置分片规则：在 TiKV 中，用户不能对分片字段分片规则作设定，若主键为数值类型则以主键作为分片字段且调度者PD来决定分片大小。减少用户使用分布式数据的学习成本，虽然灵活性低，但是 PD 可以只能调整region大小与位置，达到负载均衡。

劣势

• 无法配置分片规则：虽然 PD 可以通过调整 region 大小与位置，达到负载均衡，但当写入集中于某一张表时，特别是如果写入的值的索引值也是连续的（比如 update time 这种按时间递增的字段），因表数据和索引数据都具有相同的前缀，且它们都是连续存储的，就会造成在很少的几个 Region 上形成写入热点，成为整个系统的瓶颈。同样，读取也有类似问题。

• 没有提供region的路由位置：虽然在大部分 TiDB 场景，用户不需要关注底层数据的存储，但是一旦发生问题，TiDB并不能提供路由位置供排查问题。
• 需要很多优化器：因为使用 RocksDB 作为存储引擎，所以 TiKV 需要自己写很多优化器来优化存储引擎，但 中间件（分库分表） 会将这些工作都下沉到 MySQL，由 MySQL 完成。
• 硬件要求高：中间件至少需要两台机器就能提供高可用服务，而 TiKV 则需要三台（官网上说至少三台，但是基于 raft 的选举，若三台机器中有一台宕机，为了防止脑裂，另外两台投票也选不出 leader，所以应该至少 4 台才能达到高可用）。

• RocksDB的缺点：同样因为使用RocksDB作为存储引擎，所以未来它需要克服RocksDB的缺点以及瓶颈，例如读写放大问题，牺牲读取性能来达到写入性能提升，对于需要大量查询的业务场景，性能会大大降低。

• 大量跨库事务：这样的存储结构意味着每一个表都是分片表，因此 join 查询几乎都是跨节点的。

中间件 跨库Join

疑问

PD调度优势

• 负载均衡：PD 通过调度策略来满足上述目标，实现负载均衡，且是多维度（leader、访问热点、存储空间、副本分配等）的负载均衡。
• 故障自动恢复：若一个节点手动下线（或自动下线，但官网没有明确指出），PD 感知到后，可以将该节点上的 region 调度到其它节点，若其自动手动上线，也可以将其它节点上的 region 调度过来。
• 水平扩容：与故障自动恢复原理相同，通过 region 的调度，加入新增节点。但理论上，节点越多，性能越差。

MySQL兼容性

• 存储过程与函数
• 触发器
• 事件
• 自定义函数
• 外键约束
• 全文/空间函数与索引
• 非 ascii/latin1/binary/utf8/utf8mb4 的字符集
• SYS schema
• MySQL 追踪优化器
• XML 函数
• X Protocol
• Savepoints
• 列级权限
• XA 语法（TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开）
• CREATE TABLE tblName AS SELECT stmt 语法
• CREATE TEMPORARY TABLE 语法
• CHECK TABLE 语法
• CHECKSUM TABLE 语法
• SELECT INTO FILE 语法

事务与隔离级别

中间件 分布式事务

弱一致模式

• 不保证隔离级别正确性。
• 一个分布式事务中各个MySQL节点的子事务可能出现部分提交。

强一致模式：

• 应保证RR和SERIALIZABLE的隔离级别正确性。
• 保证一个分布式事务中各个MySQL节点的子事务全提交或者全回滚。

• 客户端收到OK包的，都没问题。
• 强一致模式下，客户端COMMIT连接断开或者COMMIT报错的，保证全提交或者全回滚。
• 弱一致模式下，客户端COMMIT连接断开或者COMMIT报错的，可能部分提交部分回滚，客户端需要根据该事务执行的SQL和MySQL节点实际的数据情况判断事务提交情况。

TiDB 事务模型劣势

• 只支持一种隔离级别，快照隔离：快照隔离有它的优势，因为不用加锁，所以有更高的读性能。

• 乐观锁导致高并发下的大量死锁，性能大幅下降：乐观锁是指只有在真正提交的时候，才会做冲突检测，如果有冲突，则需要重试。这种模型在冲突严重的场景下，会比较低效，因为重试之前的操作都是无效的，需要重复做。尤其是金融场景，悲观事务是不可或缺的一个特性。

• 全局唯一的时间戳：无论是 spanner 框架还是 percolator 模型，都需要依靠全局时间戳。Google 通过原子钟实现该功能，但 TiDB 使用的是类似 Percolator 的 Timestamp Oracle（TSO）机制，也就意味着多一次网络开销。尤其是 TiDB 宣传的跨数据中心容灾方案，同一个集群中的不同 TiDB、PD、TiKV 分布在不同的异地 idc 上，在这样情况下，多一次网络开销将会不可避免地影响性能。
• 对事务的大小有限制，否则会导致raft 的复制卡住，即使是 spanner 也有类似限制：单个事务包含的 SQL 语句不超过 5000 条（默认）；单条 KV entry 不超过 6MB；KV entry 的总条数不超过 30W；KV entry 的总大小不超过 100MB；单行数据不大于6MB；总的行数*(1 + 索引个数) < 30W；一次提交的全部数据小于 100MB；以及建议每个事务的行数不超过 200 行，且单行数据小于 100k，否则性能可能不好。

数据迁移

• Mydumper：用于从 MySQL 导出数据。（相当于 mysqldump 导出）
• Loader：用于将 Mydumper 导出格式的数据导入到 TiDB。（相当于 mysqldump 导入）
• Syncer：用于将数据从 MySQL 增量同步到 TiDB。（相当于 mysqlbinlog）
• DM（Data Migration）：支持 MySQL 数据的全量导出和到 TiDB 的全量导入，还支持 MySQL binlog 数据到 TiDB 的增量同步。（相当于集成了 Mydumper、Loader、Syncer 的功能）
• TiDB Lightning：用于将全量数据高速导入到 TiDB 集群。例如，如果要导入超过1TiB 的数据，使用 Loader 往往需花费几十个小时，而使用 TiDB-Lightning 的导入速度至少是 Loader 的三倍。

备份恢复

HTAP思考

读写分离

总结

优势

• SQL兼容能满足基本业务需求：从 SQL 兼容性上来看，因 TiDB 底层是以 key-value 形式存储的，在 SQL 兼容性上自然是不如 HotDB，但也能满足基本的业务需求。不支持外键约束、全文函数与索引、空间函数与索引、存储过程与函数、触发器、事件、自定义函数、增删主键等。
• 基于spanner框架的 ACID 的分布式事务：基于 spanner 框架，通过乐观锁、MVCC、二阶段提交、全局单点时间戳等多项技术， 实现了分布式事务的 ACID。
• 基于调度算法的自动故障恢复、水平扩容、负载均衡：PD 根据心跳检测收集来的状态信息，调整调度算法。即使发生了增加节点或节点故 障，PD 也可以通过增加、删除、转移 region，实现访问热点、存储空间、Leader 数 量等多维度的均匀分配。
• 基于raft 的多副本高可用：TiKV 底层以 region 为单位，创建多个 replica（副本），每个 replica 之间，通过 Raft 协议来达到数据的一致性。根据 raft 协议，其中一个拥有最新日志复制的副本 会被选举为 leader，其它的副本作为 follower。由 leader 进行读写操作，再复制给 follower，确认完成后提交。
• 运维成本低，用户几乎不需要关注底层是如何存储的：用户不需要配置分片规则，也不需要关心底层路由结果，故障后不需要特殊处理，PD 会自动将故障节点中的 region 调度到其它节点。
• 数据迁移成本低：TiDB 提供丰富的数据迁移工具，不仅有相当于 mysqldump 和 mysqlbinglog 的 Mydumper、Loader、Syncer，还有将这三者集成在一起的工具 Data Migration，以及 提供全量数据高速导入的 TiDB Lightning。

劣势

• 硬件要求高：中间件 至少需要两台机器就能提供高可用服务，而 TiKV 则需要三台（官网上说至少三 台，但是基于 raft 的选举，若三台机器中有一台宕机，另外两台投票也选不出 leader，所以应该至少 4 台才能达到高可用）。另外，无论是 RocksDB 还是 TiKV、 TiDB，从架构上应该都会对内存有很大消耗。
• 备份恢复功能不强：TiDB 备份恢复功能，会比较麻烦一点， 需要通过使用 Mydumper 从 TiDB 导出数据后，通过 Loader 导入数据到 TiDB，再通 过 TiDB binlog 进行增量的备份与恢复。
• key的连续存储导致性能瓶颈：当写入集中于某一张表时，特别是如果写入的值的索引值也是连续的，就会造成在很 少的几个 Region上形成写入热点，成为整个系统的瓶颈。同样，读取也有类似问 题。但在 中间件 上，类似这样大表可以通过水平分片并将访问热点打散的方法，将一 张表分片到多个节点。
• 性能不稳定，跨库事务多：无论是 spanner 框架还是 percolator 模型，都需要依靠全局时间戳。谷歌通过原子钟 实现该功能，但 TiDB 使用的是类似 Percolator 的 Timestamp Oracle（TSO）机制， 也就意味着多一次网络开销。尤其是 TiDB 宣传的跨数据中心容灾方案，同一个集群中 的不同 TiDB、PD、TiKV 分布在不同的异地 idc 上，在这样情况下，多一次网络开销将 会不可避免地影响性能。
• 全局唯一的时间戳意味着每个操作会多一次网络开销：无论是 spanner 框架还是 percolator 模型，都需要依靠全局时间戳。谷歌通过原子钟 实现该功能，但 TiDB 使用的是类似 Percolator 的 Timestamp Oracle（TSO）机制， 也就意味着多一次网络开销。尤其是 TiDB 宣传的跨数据中心容灾方案，同一个集群中 的不同 TiDB、PD、TiKV 分布在不同的异地 idc 上，在这样情况下，多一次网络开销将 会不可避免地影响性能。
• 只支持一种隔离级别，快照隔离：快照隔离有它的优势，因为不用加锁，所以有更高的读性能。但它也有它的劣势，会 有写入结果出错的情况，在有些业务场景下，尤其是金融业务，可能是无法接受的。 但 TiDB 只提供一种隔离级别，用户没有选择。
• 乐观锁导致高并发下的大量死锁，性能大幅下降：乐观锁是指只有在真正提交的时候，才会做冲突检测，如果有冲突，则需要重试。这种模型会导致高并发下的大量死锁，性能大幅下降。尤其是金融场景，悲观事务是不可或缺的一个特性。不过 TiDB 在 3.0 的时候，推出了悲观事务，并且推出了死锁检测机制（乐观锁不存在死锁问题），实际情况有待考证。
• 事务大小有限制：对事务的大小有限制，否则会导致 raft 的复制卡住，即使是 spanner 也有类似限制。