初识TiDB分布式数据库

目前最流行的分布式数据库有两类，一个是以Google Spanner为代表，一个是以AWS Auraro为代表。Spanner 是 shared nothing 的架构，内部维护了自动分片、分布式事务、弹性扩展能力，数据存储还是需要 sharding，plan 计算也需要涉及多台机器，也就涉及了分布式计算和分布式事务。主要产品代表为TiDB、CockroachDB、OceanBase等；这三个产品可以说目前话题量不相上下，TiDB属于国产PingCAP公司的、CockroachDB比TiDB早出来一年、OceanBase阿里团队的，2017年双11交出4200万/秒的处理能力。Auraro 主要思想是计算和存储分离架构，使用共享存储技术，这样就提高了容灾和总容量的扩展。但是在协议层，只要是不涉及到存储的部分，本质还是单机实例的 MySQL，不涉及分布式存储和分布式计算，这样就和 MySQL 兼容性非常高。主要产品代表为 PolarDB。

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

TiDB 具备如下 NewSQL 核心特性：

• SQL支持 （TiDB 是 MySQL 兼容的）
• 水平线性弹性扩展
• 分布式事务
• 跨数据中心数据强一致性保证
• 故障自恢复的高可用

TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景。

• TiDB 集群主要分为三个组件：

1. TiDB Server

TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。 TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。

1. PD Server

Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个： 一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。

1. TiKV Server

TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region（区域），每个 Region 负责存储一个 Key Range （从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。

• 核心特性：

1. 水平扩展 

　无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力和存储能力。TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。所以在业务的早期，可以只部署少量的服务实例（推荐至少部署 3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实例。 

1. 高可用 

　高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。 
 

• 压力测试总结

顺序扫描效率高，连续行大概率存储同一台机器邻近位置，批量读取/写入效率高
控制并发运行的线程数，会减少请求响应时间，提高处理性能

• 场景建议

适合线上业务混合读写场景
适合顺序写场景：数据归档、操作日志、摊销流水等