本文详细解读了TiKV如何利用RocksDB进行数据持久化，涉及写操作、查询策略、分布式事务的两阶段提交机制以及MVCC的设计。还介绍了TiKV-Raft的日志复制和Leader选举，以及数据写入和读取的过程，以及Coprocessor的协同处理器功能。
Lesson 03—TiKV
一、TiKV 持久化
TiKV 数据持久化靠RocksDB实现。
RocksDB介绍：
RocksDB写操作：
RocksDB写入磁盘的操作：
先把WAL直接写入磁盘日志中，MemTable中追加到最大值后，就开始转存到immutable MemTable。RocksDB重新开辟一个MemTable。
immutable Mentable 是刷入磁盘的中间状态，防止写入阻塞。immutable Mentable 达到5个以后，会限速。
Level 0 是 immutable MemTable 的复刻，内容一样。达到4个以后，会向下一层走，这个过程叫做 compaction
删除操作：只写入Delete语句，不去真正删除。更新操作同理。
RocksDB 查询操作：
查询操作：只查询最新的值。
最近最常用的数据在Block Cache中，不在的话，就去MemTable，再去immutable MemTable，最后再去磁盘。
在SST文件中对文件进行排序，采用二分查找法。
bloom Filter：判定在的话可能在，不在的话肯定不在。
RocksDB 列簇（CF）：
共用日志文件。
二、分布式事务
两阶段提交：
第一阶段，prewrite 修改数据（TiKV 节点用三个列簇来保存）和锁信息，写入TiKV节点中。
第二阶段，commit 到PD中去要时间，也就是结束时间。
在写入之前，别人感知不到，叫做 乐观锁；提前将锁写入TiKV节点中，叫做悲观锁。
第一行加主锁，之后都是追随主锁。
Default：放修改数据
Lock：放锁信息
Write：放提交信息和小于255字节的修改信息。
只为分布式事务的第一行加锁。
三、MVCC
查询的话先到Write中找最近的值，再去Default中找到。
写数据的话，先Write ，再Lock，有锁就写不了，没锁就可以写。
四、TiKV-Raft
日志复制：
Region是一个逻辑概念。Region 默认初始大小96M，涨到144M时会分裂。
-
Propose：外面的客户端写入raft log。
-
Append：写到本地RocksDB log 中，。
-
Replicate：将 Leader 中的日志分发到其它 follower 中。
append：其它节点也持久化到RocksDB 中。
-
committed：返回一个响应值，当大多数（超过一半）follower region反馈提交成功。Raft 日志的commited，而不是用户的commited。
-
Apply：将 Raft log 写入RocksDB KV中，这时候返回用户的Commited。
Leader 选举：
term ：时间段，没有固定长度。
每一个 Region 有一个计时器，election timeout = 10s，可自行设置。
收到候选者的请求后，如果term大于自己，就会投一票。
heartbeat time interval = 10 s
在时间内，收不到心跳信息，就会判定leader挂了，然后发起一个选举。
election timeout + random。
Election timeout：多少个ticks之后发起选举。
Heartbeat timeinterval： 发送心跳间隔时间，默认1s。
五、数据写入和读取
数据写入：
raftstore pool：日志线程池
apply pool：日志解析线程池
- 先去PD查数据存放位置
- 读的时候发心跳确认是否为Leader。
数据读取：
增加 readindex 用来记录当前 commit 的位置。
增加 Applyindex 用来记录当前 apply 的位置。
Leader：
Follower：
六、Coprocessor
Coprocessor——协同处理器
算子下推：
- 物理计算
- 分析数据
- 统计信息
七、跳转链接
下面是我的笔记链接：
2945
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
