TiDB分布式数据库

概述

TiDB 是 PingCAP 公司设计的开源分布式数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性

TIDB架构图

TiDB 特性：

1. 高度兼容mysql
2. 水平弹性扩展，通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
3. 分布式事务，支持标准的 ACID 事务（原子性（Atomicity），一致性（Consistency），隔离性（Isolation）持久性（Durability））
4. 真正金融级高可用，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入
5. TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景

TIDB集群组件TIDB，TIKV ，PD

TiDB Server
负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。 TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址
PD Server
是整个集群的管理模块，其主要工作有三个： 一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID
TiKV
TiKV Server 负责存储数据，数据以什么样的形式保存下来。TiKV 的选择是 Key-Value 模型，并且提供有序遍历方法，那么数据是如何落盘的， TiKV 没有选择直接向磁盘上写数据，而是把数据保存在 RocksDB 存储引擎中，具体的数据落地由 RocksDB 负责。为了实现存储的水平扩展，我们需要将数据分散在多台机器上，将数据分散在多台机器上有两种比较典型的方案：一种是按照 Key 做 Hash，根据 Hash 值选择对应的存储节点；另一种是分 Range，某一段连续的 Key 都保存在一个存储节点上。TiKV 选择了第二种方式，将整个 Key-Value 空间分成很多段，每一段是一系列连续的 Key，我们将每一段叫做一个 Region，以 Region 为单位做 Raft 的复制和成员管理
MVCC
很多数据库都会实现多版本控制（MVCC），TiKV 也不例外。设想这样的场景，两个 Client 同时去修改一个 Key 的 Value，如果没有 MVCC，就需要对数据上锁，在分布式场景下，可能会带来性能以及死锁问题。 TiKV 的 MVCC 实现是通过在 Key 后面添加 Version 来实现的。

Key1-Version3 -> Value
	Key1-Version2 -> Value
	Key1-Version1 -> Value
	……
	Key2-Version4 -> Value
	Key2-Version3 -> Value
	Key2-Version2 -> Value
	Key2-Version1 -> Value
	……
	KeyN-Version2 -> Value
	KeyN-Version1 -> Value

事务
TiKV 的事务采用的是 Percolator 模型，并且做了大量的优化。事务的细节这里不详述，大家可以参考论文以及我们的其他文章。这里只提一点，TiKV 的事务采用乐观锁，事务的执行过程中，不会检测写写冲突，只有在提交过程中，才会做冲突检测
冲突的双方中比较早完成提交的会写入成功，另一方会尝试重新执行整个事务