# Tidb 架构
  + 组件：
    + Placement Driver (PD) 群集
    + 使用 MySQL 协议连接应用程序的 TiDB 集群
    + 存储集群 (TiKV TiFlash)
    + 使用 Spark SQL 进行Spark 集群连接	

![left](./student-guide/diagram/TiDBArchitecture_aa_001_20220524.png)

------------------------------------------------------------
组件：
  -PD 集群（过程控制）
  -TiDB 集群（TiDB 数据库）<-> 通过 MySQL 协议进行应用
  -存储集群 (tikV/TiFlash)
  -Spark Cluster/TiSpark <-> Sparl SQL

当我们谈论云中的 TiDB 时，我们仍然在谈论 TiDB 架构具有本地存在的功能。
在云端，TiDB 仍然负责管理 TiDB 架构组件。

上镜像中的组件完全由 TiDB Cloud 控制平面自动托管，并根据租户的购买需求开启。
  -注意：仍然需要手动开设和管理 AWS 和 GCP 账户。在设计了 Prod OU 单元权限边界和 Prod 的 Group and Role 和 Policy 模板之后，有了与安全操作相关的安全即代码管理，应用程序功能可以由 Infra 作为 Code Managed 进行管理，但在集成到 Code 之前，任何角色和策略都需要通过安全性复查以避免自动集成角色和策略。权限太大且无法控制。

TiKV 服务器负责存储数据。TiKV 是一个分布式事务键值存储引擎。Region 是存储数据的基本单位。每个Region 存储特定键范围的数据，该范围是从 startKey 到 EndKey 的左闭右开间隔。每个 TiKV 节点中存在多个区域。TiKV API 在键值对级别为分布式事务提供原生支持，默认支持快照隔离级别隔离。这是 TiDB 如何在 SQL 层面支持分布式事务的核心。处理 SQL 语句后，TiDB 服务器会将 SQL 执行计划转换为对 TiKV API 的实际调用。因此，数据存储在 TiKV 中。TiKV 中的所有数据都会自动保存在多个副本中（默认为三个副本），因此 TiKV 具有原生高可用并支持自动故障转移。

TiFlash 服务器是一种特殊类型存储服务器。与普通的 TiKV 节点不同，TiFlash 按列存储数据，主要是为了加速分析处理。
当我们在区域中分发和复制数据时，我们有一个分布式键值系统，该系统在某种程度上具有容灾能力。您不再需要担心容量、磁盘故障和数据丢失。

TiDB 使用 Raft共识算法来确保数据高度可用，并在 Raft Group 的存储中安全复制。数据在存储节点之间进行冗余拷贝，并放置在不同的可用性区中，以防止计算机或数据中心出现故障。TiDB 云集群由三个主要组件组成：TiDB 节点、TiKV 节点和 TiFlash 节点。每个组件的高可用性实现如下所示：

  -TiDB 节点
  TiDB 仅用于计算，不存储数据。它具有水平可扩展性。TiDB Cloud 将 TiDB 节点平均部署到一个地域的不同可用性区。建议您在每个 TiDB 云集群中至少配置两个 TiDB 节点以实现高可用。

  -TiKV 节点
  TiKV 用于存储数据。它可横向扩展，节点数量应至少为 1 组（3 个不同可用性区中的 3 个节点）。每个 TiDB Cloud 集群的 TiKV 中的数据有 3 个副本，每个副本存储在三个不同的 TiKV 节点中，这些节点分布在三个不同的可用性区中。

  -TiFlash（测试版）节点
  作为 TiKV 的列式存储扩展，TiFlashBeta 是使 TiDB 实质上成为混合事务/分析处理 (HTAP) 数据库的关键组件。在 TiFlashBeta 中，列式副本是根据 Raft Learner 共识算法异步复制的。为了节省 TiFlashBeta 节点之间的数据传输成本，TiDB Cloud 将一个 TiDB Cloud 集群的所有 TiFlashBeta 节点部署到一个地域的一个可用区中。建议您在每个 TiDB Cloud 集群中至少配置两个 TiFlashBeta 节点，并至少创建 2 个数据副本，以便在生产环境中实现高可用。