TiDB集群架构学习

一，TiDB集群简介

TiDB 是 PingCAP 公司基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库。TiDB 具备如下 NewSQL 核心特性：SQL支持 （TiDB 是 MySQL 兼容的）
水平线性弹性扩展
分布式事务
跨数据中心数据强一致性保证
故障自恢复的高可用
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景。TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。

二、TiDB整体架构

深入了解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 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。

三、特性特性

1、水平扩展

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

2、高可用

高可用是TiDB的另一大特点，TiDB、PD、TiKV这3个组件都能容忍部分实例失败，从而不影响整个集群的可用性。a、TiDB      TiDB是无状态的，推荐至少2个实例，前段通过负载均衡组件对外提供服务。当单个实例失效的时候，会影响正在这个实例上进行的Session，从应用的角度看，会出现单次请求失败的情况，重新连接即可获取服务（有些像连接池连接失效重新获取）。单个实例失败后的处理，和mysql高可用的单个实例处理方法类似，重启实  例或者部署一个新的实例。b、PD    PD是一个集群，通过Raft协议保持数据的一致性 ，单个实例失效时候，如果这个实例不是Raft的leader，那么服务完全不受影响；如果这个实例是Raft的leader，会重新选出新的Raft leader，自动恢复服务。当然在重新进行选举的如果从中无法提供对外服务，这个时间约是3秒钟，推荐至少部署3个PD实例；单个实例失败后，添加新的实例或者重启这个实例，以保证集群永远有3+实例。c、TiKV     TiKV是一个集群，通过Raft协议保持数据的一致性（副本数量可配置，默认3副本），通过PD server进行复制均衡调度；当单个节点失效时，会影响这个节点上存储的所有Region。对于Region中的Leader节点，会中断服务，等待重新选举；对于Region中的Follower节点，不会影响服务。因此当某个TiKV节点失效，并且在一段时间内（默认10分钟）无法恢复，PD会将其上的数据迁移到其它的TiKV节点上。