TiDB on Azure介绍

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/cyezhou/article/details/80827223

最近的一个项目中,有客户希望在Azure上使用分布式的数据库以满足未来不可预见的业务需求。本文简单介绍了TiDB及在Azure上部署的架构。

什么是TiDB?

TiDB 是 PingCAP 公司基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库。

TiDB 具备如下 NewSQL 核心特性:

  • 高度兼容MySQL
  • 水平线性弹性扩展
  • 分布式事务
  • 强一致性保证
  • 故障自恢复的高可用
  • 一站式HATP解决方案
  • 云原生数据库

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 为单位进行调度。

TiDB on Azure参考架构

这里写图片描述

前端的Web Tier和App Tier就先不描述了,我们只看TiDB Tier部分:

  • TiDB Server
    由于是无状态的服务器,因此可以放在一个Avset中,通过前端的负载均衡实现高可用。

  • PD Server
    作为管理集群,需要部署奇数节点,可以放在一个Avset中来实现高可用。

  • TiKV Server
    通过TiKV启动参数,可以将TiKV的拓扑信息上报PD,PD可以基于TiKV的拓扑来进行最优的调度,通过Avset的配合来实现高可用,在后续的文章中我会进行详细说明。

没有更多推荐了,返回首页