整体架构
组件
PD server
集群的管理者，存储元数据，负责复杂均衡， 分配全局唯一的事务id<br>
会在TiKV server节点之间以Region为单位做调度，将部分数据迁移到新加的节点上<br>
TiDB server<br>
负责接收sql请求的，解析sql<br>
通过PD存储的元数据找到数据存在在哪个TiKV，并和TiKV交互，将结果返回用户<br>
简单的增加TiDB server，可以提高整体的处理能力，提供更高的吞吐
无状态的，可以水平无限扩容增加计算能力
TiKV server
真正存储数据的<br>
本质上是key value 存储引擎
部署更多的TiKV server节点解决数据扩容的问题
数据是以Region为单位进行存储的
类似HBase的Region
默认3副本
通过Raft协议保证数据一致和高可用
与HDFS类似
通过RocksDB实现了TB级别的本地化存储
与HBase类似
通过LSM树作为存储方案
避免了B+树叶子节点膨胀带来的大量随机读写<br>从而提升整体的吞吐量
Ti Spark<br>
解决用户复杂OLAP查询需求的组件<br>
TiDB Operate<br>
负责云上部署的组件
推荐部署最少，3个TiKV,3个PD,2个TiDB<br>
随着业务的增长按需增加TiKV和TiDB实例<br>
核心特性<br>
高度兼容MySQL
大多数情况下，无需修改代码即可从MySQL轻松迁移至TiDB，分库分表后MySQL集群也可以通过TiDB工具实时迁移
一站式HTAP解决方案
典型OLTP行存数据库，兼具强大的OLAP性能，配合TiSpark，可提供一站式HTAP
一份存储同时处理OLTP&OLAP，无需传统繁琐的ETL过程
云原生SQL数据库
配合TiDB Operator可实现自动化运维，使部署、配置、维护变得简单
水平弹性扩展
通过简单的增加新节点可实现TiDB的水平扩展，按需扩展吞吐或存储，轻松应对高并发。海量数据场景
金融级高可用
基于Raft的多数派选举协议数据强一致性保证，且在不丢失大多数副本的前提下，可实现故障的自动恢复，无需人工介入
实现原理
TiDB
TiDB无状态，前端通过负载均衡组件对外提供服务。单个实例失效，会影响正在这个实例上进行的session。从应用角度，会出现单次请求失败的情况，重新连接后即可继续获得服务。<br>
PD
集群，Raft协议保持数据的一致性，单个实例失效，如果不是leader节点，服务完全不受影响；<br>如果是leader，会重新选出新的Raft leader自动恢复服务。PD在选举过程无法对外提供服务，大概3秒。<br>推荐至少3台PD
TiKV
Raft保持数据的一致性，默认保存3副本。单个节点失效，会影响这个节点上存储的所有Region
leader挂会中断服务，等待重新选举；follower，不会影响服务
默认3副本
当某个节点失效，并且在默认30min无法恢复时，PD会将其上的数据迁移到其他TiKV
