简介
TiDB 是一款开源的分布式关系型数据库,具有水平扩展、高可用性和强一致性等特点,特别适用于需要高并发、低延迟和高可用性的大规模数据处理场景。TiDB 的架构设计灵感来自 Google 的 Spanner 和 F1,并且与 MySQL 兼容。以下是对 TiDB 集群原理的详细介绍。
1. TiDB 集群的整体架构
TiDB 集群主要由三个核心组件构成:
- TiDB Server: 无状态的 SQL 层,负责接收来自客户端的 SQL 请求,执行 SQL 解析、优化和计划生成,最终将数据读写请求分发给存储层。
- PD(Placement Driver): 集群的元数据管理模块,负责管理 TiKV 集群的元数据,调度数据的存储和副本分布,保证数据的负载均衡和高可用性。
- TiKV Server: 分布式的存储层,负责数据的存储和读取,提供分布式事务的支持,确保数据的一致性。
另外,还有 TiFlash 作为列存储引擎,用于加速分析型查询。
2. TiDB Server 详细解析
- 无状态设计: TiDB Server 是无状态的,所有请求都是通过负载均衡器分发到任意一台 TiDB Server 进行处理。这意味着 TiDB Server 可以轻松扩展,满足高并发的需求。
- SQL 处理流程:
- SQL 解析: 将 SQL 语句解析为抽象语法树(AST)。
- 查询优化: 基于元数据和统计信息,TiDB 优化器会选择最优的执行计划。
- 执行计划生成: 生成物理执行计划,确定如何访问数据以及如何执行操作。
- 请求分发: 将数据访问请求分发到存储层(TiKV 或 TiFlash)。
3. PD(Placement Driver)详细解析
- 元数据管理: PD 负责存储集群的元数据,包括每个 Region 的位置、副本分布和节点状态等信息。
- 负载均衡和调度:
- Region 的分裂与合并: 当某个 Region 的数据量或请求量过大时,PD 会自动将其分裂成多个小的 Region;相反,如果某些 Region 过小,PD 可能会将它们合并。
- 副本管理: PD 确保每个 Region 在集群中有足够数量的副本,通常是 3 个副本,以确保高可用性和容灾能力。
- Leader 选举: PD 负责为每个 Region 选择一个 Leader,Leader 负责处理所有的写入请求和大部分的读取请求。
- 时间同步: PD 使用内建的 TSO(Timestamp Oracle)服务为集群提供全局递增的时间戳,确保分布式事务的一致性。
4. TiKV Server 详细解析
- 分布式存储设计:
- Key-Value 存储模型: TiKV 以键值对的形式存储数据,支持范围查询,并且基于 Raft 协议实现分布式一致性。
- Region: TiKV 中的数据按范围切分成多个 Region,每个 Region 是连续的 Key-Value 对集合,默认大小为 96MB。每个 Region 在物理上被存储在不同的 TiKV 节点上。
- Raft 协议:
- 数据一致性: 每个 Region 的副本组通过 Raft 协议进行日志复制,确保数据一致性。Raft 中的 Leader 负责处理客户端请求,将操作日志复制到 Follower,并在多数副本确认后提交日志。
- 高可用性: 当某个副本故障时,PD 可以自动将其替换,并通过 Raft 协议确保新的副本能够恢复数据。
- 事务支持:
- 两阶段提交(2PC): TiKV 采用两阶段提交协议保证分布式事务的原子性和一致性。第一阶段预提交(Prewrite),第二阶段提交(Commit)。
- 乐观事务和悲观事务: TiKV 提供乐观事务(默认)和悲观事务两种模式,前者适用于冲突较少的场景,后者适用于冲突较多的场景。
5. TiFlash 解析
- 列存储引擎: TiFlash 是 TiDB 集群的列存储引擎,专为 OLAP(在线分析处理)场景设计。它与 TiKV 保持数据一致性,支持实时分析查询。
- 异步复制: TiDB 会将 TiKV 中的数据异步复制到 TiFlash 中,使得 TiFlash 能够加速复杂的分析查询,而不影响 TiKV 的事务性能。
6. 数据写入和读取流程
- 数据写入:
- 客户端通过 TiDB Server 发送写入请求。
- TiDB Server 解析 SQL 并将数据写入请求分发到对应的 TiKV Leader。
- TiKV Leader 通过 Raft 协议将数据复制到 Follower 节点。
- 在多数 Follower 节点确认写入后,Leader 将数据提交,并返回给 TiDB Server。
- 数据读取:
- 客户端通过 TiDB Server 发送读取请求。
- TiDB Server 解析 SQL,并根据 PD 提供的元数据确定数据所在的 TiKV 或 TiFlash 节点。
- TiDB Server 向对应的节点发送读取请求并获取数据。
- TiDB Server 将查询结果返回给客户端。
7. 高可用性和故障恢复
- 多副本存储: 每个 Region 在 TiKV 集群中有多个副本,通常为 3 个副本。即使某个节点故障,数据也可以通过其他副本进行恢复。
- 自动故障转移: 当 PD 监测到某个 TiKV 节点失效时,会将其上的 Leader 转移到其他正常节点上,保证集群的可用性。
- Raft Group 选举: Raft 协议确保在 Leader 节点失效后,剩余的 Follower 节点能够自动选举出新的 Leader,继续提供服务。
8. TiDB 的扩展性
- 水平扩展: TiDB 支持通过增加更多的 TiDB Server 和 TiKV Server 实现水平扩展,能够应对不断增长的业务需求。
- 负载均衡: PD 通过动态调整 Region 的分布和 Leader 的位置,确保集群负载均衡,避免单点热点问题。
9. TiDB 的强一致性
- 全局一致性: TiDB 使用 MVCC(多版本并发控制)和 Raft 协议来确保在分布式环境下的强一致性,所有读写操作都遵循线性一致性。
- 分布式事务: TiDB 的事务模型确保了 ACID(原子性、一致性、隔离性、持久性)属性,即使在跨节点的分布式事务中也能保持数据一致。
10. TiDB 的适用场景
- OLTP 场景: 由于 TiDB 的高并发支持和分布式事务能力,非常适合在线交易处理系统,如电商平台、金融系统等。
- HTAP 场景: 结合 TiKV 和 TiFlash,TiDB 能够同时支持 OLTP 和 OLAP 的混合负载,这使其在需要实时数据分析的场景中具有优势。
一、部署要求
1、硬件要求
CentOS 7.3及以上版本
组件 | CPU | 内存 | 硬盘类型 | 网络 | 实例数 |
---|---|---|---|---|---|
TiDB | 16核 | 32GB | SAS | 万兆网卡两块 | 2 |
PD | 4核 | 8GB | SSD | 万兆网卡两块 | 3 |
TiKV | 16核 | 32GB | SSD | 万兆网卡两块 | 3 |
TiFlash | 48核 | 128GB | SSD | 万兆网卡两块 | 2 |
TiCDC | 16核 | 16GB | SSD | 万兆网卡两块 | 2 |
监控 | 8核 | 16GB | SAS | 千兆网卡两块 | 1 |
注释:
- 生产环境TiDB和PD可以部署和运行在同一服务器上,如对性能要求较高,可分开部署。
TiKV硬盘大小建议 SSD 不超过 2TB使用NVME接口以保证读写更快,普通SSD不超过1.5TB。
TiFlash 支持多盘部署。
TiFlash 数据目录的第一块磁盘推荐用高性能 SSD来缓冲 TiKV 同步数据的实时写入,该盘性能应不低于 TiKV 所使用的磁盘,比如 PCI-E SSD。并且该磁盘容量建议不小于总容量的 10%,否则它可能成为这个节点的能承载的数据量的瓶颈。而其他磁盘可以根据需求部署多块普通 SSD,当然更好的 PCI-E SSD 硬盘会带来更好的性能。
- TiFlash 推荐与 TiKV 部署在不同节点,如果条件所限必须将 TiFlash 与 TiKV 部署在相同节点,则需要适当增加 CPU 核数和内存,且尽量将 TiFlash 与 TiKV 部署在不同的磁盘,以免互相干扰。
TiFlash 硬盘总容量大致为:
整个 TiKV 集群的需同步数据容量 / TiKV 副本数 * TiFlash 副本数
。例如整体 TiKV 的规划容量为 1 TB、TiKV 副本数为 3、TiFlash 副本数为 2,则 TiFlash 的推荐总容量为1024 GB / 3 * 2
。用户可以选择同步部分表数据而非全部,具体容量可以根据需要同步的表的数据量具体分析。TiCDC 硬盘配置建议 1 TB+ PCIE-SSD。
如果公司真的要用 TiDB 最低的要求也应该使用 NVME 的硬盘,否则不建议使用,而且必须部署在相同的交换机上,如果想要性能更好还是要使用万兆网卡,毕竟对于分布式来讲,现在最大的瓶颈就是网络。
2、网络要求
TiDB 各组件和端口说明:
组件 | 默认端口 | 说明 |
---|---|---|
TiDB | 4000 | 应用及 DBA 工具访问通信端口 |
TiDB | 10080 | TiDB 状态信息上报通信端口 |
TiKV | 20160 | TiKV 通信端口 |
TiKV | 20180 | TiKV 状态信息上报通信端口 |
PD | 2379 | 提供 TiDB 和 PD 通信端口 |
PD | 2380 | PD 集群节点间通信端口 |
TiFlash | 9000 | TiFlash TCP 服务端口 |
TiFlash | 8123 | TiFlash HTTP 服务端口 |
TiFlash | 3930 | TiFlash RAFT 服务和 Coprocessor 服务端口 |
TiFlash | 20170 | TiFlash Proxy 服务端口 |
TiFlash | 20292 | Prometheus 拉取 TiFlash Proxy metrics 端口 |
TiFlash | 8234 | Prometheus 拉取 TiFlash metrics 端口 |
Pump | 8250 | Pump 通信端口 |
Drainer | 8249 | Drainer 通信端口 |
CDC | 8300 | CDC 通信接口 |
Prometheus | 9090 | Prometheus 服务通信端口 |
Node_exporter | 9100 | TiDB 集群每个节点的系统信息上报通信端口 |
Blackbox_exporter | 9115 | Blackbox_exporter 通信端口,用于 TiDB 集群端口监控 |
Grafana | 3000 | Web 监控服务对外服务和客户端(浏览器)访问端口 |
Alertmanager | 9093 | 告警 web 服务端口 |
Alertmanager | 9094 | 告警通信端口 |
二、基础环境优化
1、使用ext4文件系统
2、开启高性能模式
# 查询 //虚拟机无信息
cpupower frequency-info --policy
# 修改为CPU高性能模式
cpupower frequency-set --governor performance
3、挂载优化
- noatime:读取文件时,将禁用对元数据的更新。
- nodiratime: 该行为会在读取目录时禁用对元数据的更新。
示例:
# 开机自动挂载
vi /etc/fstab
/dev/mapper/data /data ext4 defaults,nodelalloc,noatime 0 2
# 挂载数据盘
mount -a
# 挂载生效
mount -t ext4
4、关闭swap分区
echo "vm.swappiness = 0">> /etc/sysctl.conf
swapoff -a && swapon -a
sysctl -p
5、关闭防火墙
systemctl stop firewalld.service
systemctl disable firewalld.service
6、使用时间同步
# 安装ntpdate命令
yum install -y ntpdate
# 设置时间同步
crontal -e
* */12 * * * ntpdate ntp.aliyum.com
7、关闭大叶内存
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
8、调整I/O调度器
echo noop > /sys/block/sd[bc]/queue/scheduler
9、网络及内核参数
echo "fs.file-max = 1000000">> /etc/sysctl.conf
echo "net.core.somaxconn = 32768">> /etc/sysctl.conf
echo "net.ipv4.tcp_tw_recycle = 0">> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies = 0">> /etc/sysctl.conf
echo "vm.overcommit_memory = 1">> /etc/sysctl.conf
sysctl -p
cat >>/etc/security/limits.conf<<'EOF'
tidb soft nofile 1000000
tidb hard nofile 1000000
tidb soft stack 32768
tidb hard stack 32768
EOF