与传统的单机数据库相比，TiDB 具有以下优势：
- 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容
- 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL
- 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明
- 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账
- 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景
在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。对应的架构图如下：
-图 TiDB整体架构-
- SQL层，从外部公开MySQL协议的连接endpoint，负责接收客户机的连接、执行SQL解析和优化，并最终生成分布式执行计划。TiDB层本身是无状态的，并且在实际情况下可以启动多个TiDB实例，通过负载平衡组件(例如LVS，HAProxy或F5)向外部提供统一的访问地址，为了实现负载平衡，客户机的连接可以平均分配到多个TiDB实例。TiDBServer本身并不存储数据，只需要解析SQL，向底层存储节点TiKV(或TiFlash)转发实际的数据读取请求。
- PD(PlacementDriver)服务器：整个TiDB集群的元信息管理模块，该系统负责存储每一个TiKV节点的实时数据分布和总体拓扑结构，提供TiDBDashboard控制接口，并将事务ID分配给分布式事务。PD不仅存储元信息，而且根据TiKV节点实时上报的数据分布状态，发出给TiKV节点的具体数据调度命令，可以说是整个集群的“大脑”。另外，PD本身至少由3个节点组成，具有高可用性。推荐部署奇数PD节点。
- 存储节点
- TiKV Server：负责存储数据。从外部来看，TiKV是一个分布式的Key-Value存储引擎，提供事务。存储数据的基本单位是Region，每个Region负责存储一个Key Range(从StartKey到EndKey的左闭右开区间)的数据，每个TiKV节点负责多个Region。TiKV的API在KV键值上为分布式事务提供本地支持，默认情况下为SI(Snapshot isolation)提供隔离级别，这也是TiDB在SQL层面支持分布式事务的核心。TiDB SQL层完成SQL分析后，SQL的执行计划将转化为TiKV API的实际调用。因此，数据存储在TiKV中。此外，TiKV中的数据会自动维护多个副本(默认为三个副本)，自然支持高可用性和自动故障转移。
- TiFlash：TiFlash是一种特殊的存储节点。与普通TiKV节点不同，数据以列式存储在TiFlash中，其主要功能是加速分析场景。
评论区（0）