• TiDB基本架构简单总结


    TiDB特点

    • 高可用
    • 水平拓展
    • 事务
    • SQL支持

    TiDB架构

    ​ 和MySql不同,TiDB是一个分布式的数据库而不是单个进程,所以整个TiDB是由以下角色组成: TiKV, PD, TiDB, TiSpark。每个角色都是部署在多台机器上的进程组成的集群。

    TiKV PD TiDB功能

    TiKV

    ​ TiKV负责数据的存储,对外而言,它就是一个提供key-value存储的引擎。但它存储的并不是离散的Key,而在一个范围内的Key,这个范围内的key-value是存储的基本单元,称为Region。

    ​ 对不同的数据类型,存储的数据格式如下:

    数据类型 key value
    行记录 表ID+行ID 行数据
    唯一索引或主键 表ID+索引ID+索引值 行ID
    非唯一索引 表ID+索引ID+索引值+行ID

    ​ 而TiKV集群上的单节点上真正负责存储的是FaceBook开源的RocksDB引擎。但RocksDB自身并没有解决单点失效的问题,TiKV采用多副本的方式来解决,而实现则是在RocksDB之上封装一层支持Raft协议,以在多节点之间同步数据。仅对于同一个Region, 只有一个leader节点接收外部对其的读写,其他节点只是用来做备份(即不同机器上的同一个Region 组成一个 Raft group)。

    ​ 所以对外部而言,TiKV可以认为是一个可以提供无限大容量的K-V存储服务(当磁盘空间不足时,可以比较方便地通过增加机器来拓容)。

    PD

    ​ PD全称是Placement Driver,是对整个TiDB集群管理进行管理的角色。它最重要的功能是存储数据的元数据,即Key和TiKV中节点的对应关系。此外,负责对集群进行调度和负载均衡Region迁移, Region Raft Leader迁移),以及提供全局唯一递增的事务ID。PD集群也是通过Raft协议保证数据安全,但只有一台机器(Leader)负责处理所有的操作。

    TiDB

    ​ TiDB角色负责对外交互(mysql协议),优化sql之后,向PD获取要读取的Key对应的TiKV节点信息,之后再向TiKV上的Region Raft Leader所在节点发起请求获取数据,再返回客户端。即TiDB是无状态的,不存储任何数据。

  • 相关阅读:
    C# 实现 Snowflake算法生成唯一性Id
    kafka可视化客户端工具(Kafka Tool)的基本使用(转)
    docker 安装kafka
    Model类代码生成器
    使用docker 部署rabbitmq 镜像
    Vue 增删改查 demo
    git 提交代码到库
    Android ble蓝牙问题
    mac 配置 ssh 到git (Could not resolve hostname github.com, Failed to connect to github.com port 443 Operation timed out)
    okhttp
  • 原文地址:https://www.cnblogs.com/Me1onRind/p/11337079.html
Copyright © 2020-2023  润新知