TiDB概念

### 一、cap理论
1、一致性(保证一致性就要牺牲性能 要有lock的参与)
2、可用性(保证可用性就要牺牲一致性)
3、分区容忍性(节点或者网络故障的时候,仍然能够对外提供满足一致性或者可用性的服务)

兼容关系型数据库,兼容MySQL。

TiDB结构

一、TiDB

1、负责连接层的工作。和sql处理的工作。
2、限制。不支持存储过程、触发器、外键、一部分函数。
3、连接使用mysql客户端工具连接。
也支持多节点。全局有序的分布式key-Value 引擎。

优化器算法相当于直接从TiDB内拿到数据行相关的行然后返回给TIDB处理。
大量jion的场景,比传统的mysql要快。它可以并行分批处理(多个TiKV并行处理)。

二、PD

为分布式系统分配全局统一的事务ID, 存储整体TIKV分布式数据库的实时元数据信息,和TIDB的数据库整体的结构. 提供TIDB 监控管理的UI 界面. 除此以外PD 还上报整体TIKV数据存储的分布情况,以及后面根据相关的情况来调整数据的在多个TIKV节点的分布.
1、调度数据分配全局唯一事务号
2、PD 管理TIKV 的REGION的分割后的管理,如果REGION 达到一定的大小会分割,当数据delete后也会进行相关的数据的清理,进行REGION的合并. PD 为这些新增的或消减的REGION 进行编号的发放和记载.
3、路由信息, 从TIDB 上下发的获取数据的指令是要通过PD来指定到哪里进行数据的获取的, PD 告知相关信息在那个TIKV 并且将信息缓存在 TIDB 中,下次如果继续访问数据可以从自己的缓存中获得地址, 同时如果TIKV的REGION分割,删除,新增了,则第一次获取数据会失败, 会将新的地址更新,让TIDB 在此访问新的位置获取数据.

三、TiKV

如何做到高并发读写的方式。
LSM tree 写到一定程度合并。利用顺序IO的方式大大提高了写入效率。
基本单位是 range(顺序的算法)。默认96M。 (相邻的range存储的数据相邻。)
range 是有endkey startkey标识(默认存储在PD节点里面)。
当range大小超过144M后会默认分成两个range。

Raft协议原理。

在这里插入图片描述
分布式协调的方式。(随机设置超时时间,谁快谁就变candidate.然后发起投票。然后一直发起超时时间接收到leader心跳重置超时时间。如果在超时时间内没有收到心跳包,者重新投票)
开始状态 follower 。
预备状态 candidate。
可读写状态 leader。

二、TiDB
需要考虑的问题。
弹性扩展。数据库颗粒度越小越好。
强一致性高可用。探测包含这数据一起去探测db节点的数据。
标准sql
事务ACID
兼容主流协议
云原生
HTAP

三、数据库技术栈-常见的基础因素有哪些。
数据模型
包括关系型模型。Key-value 模型。

TiDB分布式事务介绍。

TiDB 会在默认是类似rr级别,但是没有间隙锁的概念。
事务是在begin的时候就开启了快照。不是mysql的查询的时候就开启快照了。
其他的开启,回滚方式和MySQL一样。包括显示提交隐式提交。
惰性检查。类似于乐观锁机制。优化了通过批处理约束检查并减少网络通信来提升性能。
tidb_constraint_check_in_place = true 禁用该行为。
对于运行不同节点的事务而言,不同事务启动和提交的顺序取决于从PD获取时间戳的顺序。

一个事务的执行流程。(乐观锁 锁冲突发生在TiKV上)

一、客户端开始一个事务。
从PD获取一个全局唯一递增的时间戳为当前事务的唯一ID。这里称为start_ts.
TiDB 实现了多版本并发控制(MVCC)。同时也做为该事务获取的数据库快照版本。该事务只能读到此start_ts
版本可以读到的数据。

二、客户端发起读请求
TiDB 从PD获取路由信息。即数据具体存在那个TiKV节点上面。
TiDB 从TiKV获取 start_ts版本下对应的数据。

三、客户端发起写请求。
TiDB校验写入数据是否符合约束(如数据类型是否正确。是否符合非空约束。)
通过的数据将放在TiDB中该事务的私有内存中。

四、客户端commit
TiDB 开始两阶段提交。在保证事务原子性的前提下。进行数据持久化。
TiDB 从当前要写入的数据中选择一个key作为当前事务的主键。
TiDB 从PD中获取所有数据的写入路由信息。并将所有的KEY按照所有的路由进行分类。
TiDB 并发的向所有的涉及的TiKV发起prewrite请求。TiKV收到数据后,检查数据版本是否存在冲突。
符合条件的数据都会加锁。
TiDB 收到所有的prewrite响应且都提交成功(大多数节点判定无冲突提交操作。)
TiDB向PD节点获取第二个全局唯一的递增版本号。定义为本次事务的commit_ts;
TiDB 向主键所在的TiKV发起第二阶段提交。TiKV检测数据合法性,清理prewrite阶段留下的锁。

五、TiDB收到两阶段提交成功的信息。
向客户端返回事务提交成功的信息。
TiDB异步清理本次事务遗留的锁信息。

悲观锁

在这里插入图片描述
在这里插入图片描述

差异

1、TiDB不支持共享锁。不支持间隙锁,和 net key lock。
2、DDL可能会导致悲观事务提交失败。
mysql在执行DDL语句时。会被正在执行的事务阻塞,而在TiDB中DDL操作会成功。炒作悲观事务提交会失败。导致事务提交报错。
3、mysql 仍然可能会读取到之后在其他事务创建的表。而TiDB不能。
4、autocommit 事务优先采用乐观事务提交。
5、DDL操作都可以瞬间完成。

TiDB MVCC实现

通过Key-values实现在key后面添加版本号实现。

TiKV 计算下推模块

在这里插入图片描述

在这里插入图片描述

DM工具

导入数据的。

TiCDC

工具导出数据用。

Tiflush 处理AP类业务的。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值