1. TiDB架构和概述
TiDBserver 概述
2 TiKV(应对查询OLTP场景)
3.PD
4.TiFlash(应对分析OLAP情景)
2.TiDBserver架构
2.1.TIDB架构
2.2.TiDB功能
1.处理客户端连接(Protocol Layer)
2.SQL语句解析转换成执行计划(Parse Compile)
3.关系型数据与KV转换
4.SQL语句执行(Executor DisrtSQL(范围,全表)KV(点查))(事务:Transaction KV )
5.Online DDL执行 (schema load,worker,start job)
6.热点小表缓存(Cache table)(不常修改,查多)
7.垃圾回收(GC)
2.2.1.SQL语句解析编译
2.2.2.KV结构
聚簇表:表id+主键形成唯一key
非聚簇表 :表id加rowid
2.2.3 SQL相关模块
2.2.4在线DDL模块(不阻塞读写)
2.2.5 GC相关模块
GC清理的内容:MVCC机制产生的历史数据
GC life-time:默认10min
2.2.6 TIDB缓存
组成:
1.SQL结果
2.线程缓存
3.元数据,统计信息
管理:
1.tidb_mem_quota_query 管理缓存
2.oom_action 报错或日志
2.2.7 热点小表缓存
1.表数据不大(64M)
2.只读表或者修改不频繁的表
3.表访问很频繁
2.2.8 热点小表原理
租约方法:租约(5s)内,可读不可写 cachetable
租约外:在TiKV读写
下一个租约:在cachetable 读,不可写
开启热点小表缓存的表不可以执行DDL语句
3.TIKV
3.1TIKV持久化
3.1.1 TIKV架构和作用
3.1.2 RocksDB
3.2 分布式事务
3.2.1 分布式事务
如果在commit时候,TIKV挂掉,重启后回来查询所的信息
3.2.2MVCC
3.3 Raft 和 Multi-raft
3.3.1 介绍
3.3.2 Raft复制
propose:tikv leader接收到事务
append:leader写入log
replicate:给foloowers同步
append:followers 写入日志
committed:followers给leader返回日志写入成功(不要要接受所有followers,超过半数即可)(保证修改不丢失)
reply:写入rocksDB kv
3.3.3 Raft Leader 选举
election time out 假设 = 10s (默认在100ms到300ms):超过10s没有接收到leader心跳,就会重新选举
第一个到达 election time out的节点会candidate,向其他节点发送选举信息,有多个同时进行选举的话,就会开启下一次选举
为了避免出现多次选举不成功,会将electiontimeout=random 随机时间
3.4TiKV读写与coprocessor
3.4.1 数据的写入
3.4.2 数据的读取
问题:1.怎么确定读取到的是leader:发心跳
2.读的一致性问题(下图)
3.4.3 Lease read
3.3.4 Follower Read
夜市等待到该节点apply到读取时刻的事务节点序号,证明之前的事务都执行完成了(与3.4.2中的问题2原理一样)
可能存在follower read 比主节点读取快的情况,(follower的apply快)