TIDB架构自我总结 _TIDB架构

TiDB 是什么？
TiDB 是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。
TiDB怎么来的？
著名的开源分布式缓存服务 codis 的作者，PingCAP联合创始人& CTO ，资深 infrastructure 工程师的黄东旭，擅长分布式存储系统的设计与实现，开源狂热分子的技术大神级别人物。即使在互联网如此繁荣的今天，在数据库这片边界模糊且不确定地带，他还在努力寻找确定性的实践方向。
直到 2012 年底，他看到 google 发布的两篇论文，如同棱镜般，折射出他自己内心微烁的光彩。这两篇论文描述了 Google 内部使用的一个海量关系型数据库 F1/Spanner ，解决了关系型数据库、弹性扩展以及全球分布的问题，并在生产中大规模使用。“如果这个能实现，对数据存储领域来说将是颠覆性的”，黄东旭为完美方案的出现而兴奋，PingCAP 的 TiDB 在此基础上诞生了。
TiDB架构

文章插图

文章插图

??TiDB 集群主要分为三个组件：
１TiDB Server
　TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或F5）对外提供统一的接入地址。
２PD Server
　Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader的迁移等）；三是分配全局唯一且递增的事务 ID 。
　PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。
３TiKV Server
　TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range （从 StartKey 到EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 使用 Raft协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 RaftGroup，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。
以上三个分别是指计算、调度、存储三个技术点：
这次重点讲一下存储：
TIKV采用的key-》value的数据模型，我们可以把TIKV想象为一个巨大的Map，里面的是按照Key的二进制的顺序进行排序，也就是可以认为里面存储的都是一个个key-》value对，在这里我们需要记住的是这里的存储模型与SQL中的Table无关！
RocksDb
任何持久化的存储引擎，数据终究都是要存储在磁盘之上的，TIKV也不例外，但是TIKV是没有选择直接将数据写在磁盘之上的，而是采用了RocksDB，将数据交给OocksDB，由它将数据写在磁盘上，他们采用这个的原因是开发单机的引擎要把各种细致化的话，还要满足他们的各种需求，工作量较大。所以他们直接采用了Fecebook开发的RocksDB来使用，这样的话，就是存储的数据模型和数据的落地已经选择好。
Raft
目前已经有一个高效可靠的本地存储机制，现在要做的就是要求数据的分布，单机的存储就算再强大，也会丢失数据，机器挂掉了，或者机房断电了，再或者地震了等等情况，都会造成数据的丢失，所以他们要实现数据的分布，也就是分布式。单机不可能支持高可用。他们在这里采用Raft协议，Raft是一致性协议，在这里我们简单的讲解一下Raft，采用这个协议可以达成三个目标：
1. Leader 选举
2. 成员变更
3. 日志复制
TIKV通过Raft来做数据复制，每个数据变更都会落地成为一条Raft日志，通过Raft的日志复制功能，将数据安全可靠地同步到group的多数节点中。
?

文章插图

文章插图

??到这里我们总结一下，通过单机的RocksDB，我们可以将数据快速地存储在磁盘上；通过Raft，我们可以将数据复制到多台机器上，以防单机失效。数据的写入是通过Raft这一层的接口写入，而不是直接写RocksDB 。通过实现Raft，我们拥有了一个分布式的KV，现在再也不用担心某台机器挂掉了。