TIDB证书-PCTA学习笔记 v6课程（1）

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快）

3.3.5 Coprocessor（将计算下推到TiKV节点）