浅谈TIDB及其整体架构 | docker-compose单机部署TIDB集群 | 多台主机使用docker部署TIDB集群 | 网络容器的作用
TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical
Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，
支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online
Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的
解决方案。
TiDB 具备如下核心特性：
高度兼容 MySQL
水平弹性扩展
分布式事务
真正金融级高可用
一站式 HTAP 解决方案
云原生 SQL 数据库
要深入了解 TiDB 的水平扩展和高可用特点，首先需要了解 TiDB 的整体架构。TiDB 集群主
要包括三个核心组件：TiDBServer，PD Server 和 TiKV Server。此外，还有用于解决用户
复杂 OLAP 需求的 TiSpark 组件。
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 为单位进行调度。
TiSpark
TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在
TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。至此，TiDB 可
以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。
核心特性
水平扩展
无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力和存储能力。TiDB
Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDBServer 节点，提高整
体的处理能力，提供更高的吞吐。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV
Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度，将
部分数据迁移到新加的节点上。所以在业务的早期，可以只部署少量的服务实例（推荐至少部署
3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实
例。
高可用
高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整
个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。
TiDB
TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例
失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情
况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。
PD
PD 是一个集群，通过 Raft协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft
的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft
leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是 3 秒钟。推
荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。
TiKV
TiKV 是一个集群，通过 Raft协议保持数据的一致性（副本数量可配置，默认保存三副本），
并通过 PD做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于
Region 中的 Leader 结点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，
不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会
将其上的数据迁移到其他的 TiKV 节点上。
https://pingcap.com/docs-cn/QUICKSTART/ TIDB 详细入门指南见官网
TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环
境及主流虚拟化环境，并支持绝大多数的主流硬件网络。作为一款高性能数据库系统，TiDB 支
持主流的 Linux 操作系统环境。
https://pingcap.com/docs-cn/op-guide/recommendation/ 软硬件环境需求
使用 docker 部署 TIDB 集群
卸载低版本，安装高版本 docker，启动 docker 服务
配置 rhel7.3的 yum 源
方法一：在单机上通过 Docker Compose 快速一键部署一套 TiDB 测试集群。
Docker Compose 可以通过一个 YAML 文件定义多个容器的应用服务，然后一键启动或停止
https://pingcap.com/docs-cn/op-guide/docker-compose/
1，下载 tidb-docker-compose
git clone https://github.com/pingcap/tidb-docker-compose.git
2，获取并导入 tidb 相关软件包
**Dockerfile 是 tidb-docker-compose 自带的，其余的 tar 包是我们自己获取的，需要导入，
docker 不支持一次导入多个包，只能一个一个导入
3，在 tidb-docker-compose 目录下 compose 服务
这里我们要修改官方原来的.yml文件，改变文件句柄，每个 tikv 下面做如下修改
4，在 tidb-docker-compose 目录下 compose 服务
注意：如果要重新 compose，先停掉服务，然后删除数据目录下的内容
此时查看 yml 文件定义的服务已经全部启动
4，浏览器查看监控
初始用户 admin，初始密码 admin
5，登录数据库
6，关闭集群
注意：我们在 compose 创建服务时，自动创建了一个网路，这个网络就是提供这个服务中多个
容器之间的通信
方法二：如何在多台主机上使用 Docker 部署一个 TiDB 集群（本实验在一台主机模拟多台主
机）
https://pingcap.com/docs-cn/op-guide/docker-deployment/
1，创建网络容器
！！！这个网卡绑定的是 172.20.0.1/16（其实是从 17 开始向上递增的，这是第三次实验，所
以变成了 20），创建这个网卡的左右和 yml 文件定义的网卡的作用一样，实现容器间通信，而
且是自动做了 dns 解析，普通网卡只能 ping ip 地址，不可以 ping 容器名，搭建这个网卡之
后就自动做了解析，可以 ping 容器名，至于为什么一定要用容器名，而不用 ip，这是因为我
们创建容器时并不知道 ip 是多少，这个 ip 是创建之后随即分配的，虽然有递增的规律，但是对
于一个特定的实例来说，我们并不知道要给他分配的 ip 是多少，而在创建一个服务时，我们需
要用到多个容器，并且会让他们通信，这个时候就必须用容器名，且创建之后对应的 ip 自动解
析到位
***************************实验验证***********************
普通网卡
使用网卡容器
在 yml 文件中，我们都可以看到使用容器名而没有使用ip
************************************继续搭建*********************************
清空 data 下的数据（可忽略）
2，创建集群
pd:
tikv:
tidb:
3，这个没有监控页面，如果想要监控页面，仿照以上和 yml 文件添加
4，登录数据库测试