分布式 New SQL数据库 TiDB 总体架构

      这篇文章将向大家介绍TiDB数据库系统的总体架构,本文参考了pingcap官方文档,并补充了少量内容。在介绍TiDB总体架构时,还简要描述了每一个组件的可扩展性和高可用性。

      TiDB 分布式数据库集群如上图所示主要分为三个组件:
      (1) TiDB Server
      TiDB Server 负责接收SQL请求,处理SQL 相关的逻辑,并通过PD 找到存储计算所需数据的TiKV 地址,与TiKV交互获取数据,最终返回结果。
     TiDB Server 是无状态的,其本身并不存储数据,只负责计算,可以无限水平扩展,可以通过负载均衡组件(如LVS、HAProxy 或F5)对外提供统一的接入地址。
      为了确保靠可用,推荐至少部署两个TiDB实例,前端通过负载均衡组件对外提供服务。当单个实例失效时,只会影响正在这个实例上进行的Session,从应用的角度看,会出现单次请求失败的情况,重新连接后即可继续获得服务。单个TiDB实例失效后,可以重启这个实例或者部署一个新的实例。

     (2) PD Server
     Placement Driver (简称PD) 是整个集群的管理模块,其主要工作职责有三个:一是存储集群的元信息(某个Key 存储在哪个TiKV 节点);二是对TiKV 集群进行调度和负载均衡(如Region的迁移、Raft group leader 的迁移等);三是分配全局唯一且递增的事务ID(全局事务时间戳)。
     PD 是一个集群,其内置了etcd组件负责集群元数据的存储和管理,它采用Raft分布式共识协议保证所存储数据多副本的强一致性。PD集群可以水平扩展,需要部署奇数个节点,一般线上推荐至少部署3 个节点以保证PD集群的高可用。
     当PD 集群中的某个实例失效时,如果这个实例不是Raft 的leader,那么服务完全不受影响;如果这个实例是Raft 的leader,那么剩余的PD实列会重新选出新的Raft leader,自动恢复服务。PD在选举的过程中无法对外提供服务,这个时间大约是3 秒钟。推荐至少部署三个PD 实例,单个实例失效后,重启这个实例或者添加新的实例。

     (3) TiKV Server
     TiKV Server 负责存储数据,是整个TiDB数据库集群的存储引擎。从外部看,TiKV 是一个分布式的提供事务和强一致性的Key-Value 存储引擎。存储数据的最小粒度是记录行(也就是一个key-value对),存储数据的基本逻辑单位是Region,它是PD进行数据调度的基本单位,也是TiKV集群中数据复制的基本单位。每个Region 负责存储一个Key Range (从StartKey 到EndKey 的左闭右开区间)的数据,每个TiKV节点上会有多个Region 。TiKV 使用Raft 协议做复制,保证数据的一致性和高可用容灾。副本以Region 为单位进行管理,不同节点上的多个Region 副本构成一个Raft Group(副本数量可配置,默认保存三副本)。数据在多个TiKV 之间的负载均衡由PD 调度,这里也是以Region 为单位进行调度。
     TiKV 集群可以水平扩展,需要部署奇数个节点,一般线上推荐至少部署3 个节点以保证PD集群的高可用。
     当单个TiKV实例失败时,会影响这个实例中存储的所有Region。对于这些Region 中的leader,会中断服务,等待重新选举;对于Region 中的Follower 节点,不会影响服务。当某个TiKV 节点失效,并且 在一段相对较长的时间内(默认30 分钟)无法恢复,PD 会将其上的数据迁移到其他的TiKV节点上。

展开阅读全文

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