怎么样提高网站点击率,随州网站建设厂家,中国移动wap什么意思,有哪些做课件的网站目录 1. TiKV架构和作用
2. RocksDB
2.1 写入
2.2 查询
2.3 Column Families列簇
3. 分布式事务
3.1 事务流程
3.2 分布式事务流程
3.3 MVCC
4. Raft与Multi Raft
4.1 Raft日志复制
4.2 Raft Leader选举
5. TiKV- 读写
5.1 数据的写入
5.2 数据的读取ReadIndex …目录 1. TiKV架构和作用
2. RocksDB
2.1 写入
2.2 查询
2.3 Column Families列簇
3. 分布式事务
3.1 事务流程
3.2 分布式事务流程
3.3 MVCC
4. Raft与Multi Raft
4.1 Raft日志复制
4.2 Raft Leader选举
5. TiKV- 读写
5.1 数据的写入
5.2 数据的读取ReadIndex Read
5.3 数据的读取Lease Read 5.4 数据的读取 Follower Read
6. Coprocessor
7. 小结 1. TiKV架构和作用 数据持久化分布式一致性MVCC分布式事务Coprocessor
2. RocksDB
RocksDB 针对 Flash 存储进行优化,延迟极小,使用 LSM 存储引擎
高性能的 Key-Value 数据库完善的持久化机制,同时保证性能和安全性良好的支持范围查询为需要存储 TB 级别数据到本地 FLASH 或者 RAM 的应用服务器设计针对存储在高速设备的中小键值进行优化一可以存储在 FLASH 或者直接存储在内存性能随 CPU 数量线性提升,对多核系统友好
2.1 写入 假如插入(1,tom)这条数据首先做WAL(Write Ahead Log保证事务的原子性和持久性),写到磁盘中的日志文件中(sync_logTrue)不经过操作系统缓存再把(1,tom)写到MemTable内存中,当写入的大小达到write_buffer_size的值时把数据刷到immutable MemTable中(固定内存不能修改了防止写阻塞)然后RocksDB重新开辟一个MemTable,immutable MemTable中的数据会刷到磁盘SST文件中当写入速度太快immutable MemTable个数太多还没来得及写入磁盘这时候就会限制写入IO日志中会产生write stall信息当MemTable中的数据落盘了wal日志文件中的数据就可以被覆盖了 Level 0是immutable MemTable的复刻当Level 0文件默认达到4个的时候就会compaction压缩到Level 1文件并把Key排好序当Level 1达到256M继续向下一级合并并排好序当Level 2达到2.5G时再向下一级合并以此类推
2.2 查询 最近最常读取的数据在Block Cache中读取速度就很快如果读取的数据不在Block Cache中则相继去MemTable、immutable MemTable、Level 0、Level 1等等中去找当在SST文件中查找时有个Bloom Filter过滤器意思就是要查找的值一定不在该文件中那就真不在该文件中要查找的值在该文件中那该值可能在该文件中
2.3 Column Families列簇 写的时候可以指定列簇可以存放同一类的数据一张表或者几张表的键值对没有指定列簇的话就会放在一个默认default中一个RocksDB可以有多个列簇每个列簇可以对应一张表或者几张表每个列簇有自己的Mem Table和SST文件,列簇之间共享一份WAL日志其实就是RocksDB的分片技术
3. 分布式事务
3.1 事务流程 在TiDB中begin一个事务会先从PD中获取一个时间戳start timestamp(start_ts)表示事务的开始时间然后把要修改的数据读取到内存中在内存中进行修改commit后就进入两阶段提交首先进行prewrite将修改的数据和锁信息写到TiKV节点中三个列簇一个存修改的数据Default一个存锁信息Lock(第一行主锁)一个存提交信息Write然后commitcommit的时候会向PD获取一个事务的结束时间commit_ts同时产生一个提交信息把锁信息标记为D删除状态表示事务结束。 在事务中如果有其他查询来读取首先查看write列簇有信息就直接读取该事务中已经修改过的数据如果write中没有信息能看到锁信息表示不能从这个地方读则从其他地方读取。 Write 列:当用户写入了一行数据时,如果该行数据长度小于 255 字节,那么会被存储 write 列中,否则的话该行数据会被存入到 default 列中。Default 列:用于存储超过 255 字节长度的数据
3.2 分布式事务流程 当还未写入TiKV Node 2中的Write的时候发生了宕机此时2节点Lock中就没有删除锁的信息那就会顺着W1这条锁信息去找1节点中的锁信息发现1节点的锁信息是删除了那么2节点会补上一个删除锁的信息。
3.3 MVCC 事务1提交了事务2未提交假设此时TSO120要读取1和4会去查看write最近提交信息的TSO版本查到了就去Default里面找数据如果此时要修改1和4则还要查看Lock中的信息有锁就不能修改如果此时去读2也是先查看write提交信息最近的TSO版本然后去Default里面把数据读出来修改2的话则查找了Write的提交信息还要去查看Lock中的锁此时没有2的锁信息则可以修改2这就是MVCC的实现 4. Raft与Multi Raft Leader所有的读写流量都走Leader通过心跳与Follower通信,并通过日志把数据同步给FollowerFollower:不参与读写长时间收不到Leader消息会变成候选者发起投票region左闭又开的存放数据一个region初始默认大小96M达到96M后生成一个新region类似于存[1,1000)[1000,2000)如果后面有修改并且修改后比原来大达到144M后会分裂如果修改后的数据比原来小还可以合并region多个TiKV的同一个region构成一个raft group
4.1 Raft日志复制 propose Leader接收到数据写入本地raft log命名为region号日志序号append将raft log存入本地RocksDBreplicate,Leader通过raft算法将raft日志一条条给Follower做复制(replicate)Follower收到日志写入本地raft log的RocksDB中持久化返回一个消息给Leadercommitted当大多数节点(超过一半)返回成功的消息后Leader就认为该条修改的数据修改成功apply将数据写入KV的RocksDB中 ProposeAppendReplicate AppendCommittedApply
4.2 Raft Leader选举 每个region有一个计时器election_timeout为10sraft-election-timeout-ticks10集群建立初始状态都不是Leader如果Follower10S都没有Leader的消息Follower就会认为集群中没有Leader 就会变为condidate发起投票term时间大于其他节点大多数其他节点投票给该节点该节点就成为Leader。 有一种情况就是几个节点同时发出选举term时间一样这样就选不出Leader会发生重复选举把每个TiKV的elaction_timeout设置为随机值比如100ms~300ms之间这样每个TiKV的elaction_timeout值不一样重复选举的概率就大大降低 集群运行一段时间后heartbeat time interval为5sraft-heartbeat-ticks5,当Leader节点挂了有其他节点5s都未接收到Leader消息则发起投票
Election timeout:raft-election-timeout-ticksHeartbeat time interval:raft-heartbeat-ticksraft-heartbeat-ticks *raft-base-tick-intervalraft-election-timeout-ticks *raft-base-tick-interval 意思就是 Election timeout是由参数raft-election-timeout-ticks的值决定Heartbeat time interval是由raft-heartbeat-ticks参数值决定这两个参数的值乘以raft-base-tick-interval默认1S的值就是得到实际的秒数raft-election-timeout-ticksraft-heartbeat-ticks
5. TiKV- 读写
5.1 数据的写入 Leader的raftstore pool写入raft RocksDB并且其他副本也写好后apply pool解析raft日志写入RocksDB kv此时用户的commit才算完成
5.2 数据的读取ReadIndex Read 能保证读取的TiKV是Leader角色吗读的时候Leader向Follower发心跳我是Leader你是不是Follower 没错你是我们的Leader我们是Follower。 保证线性一致性当用户在10:00时插入一个值(1,jack)用户commit后此时raft log为1_95目前RocksDB KV还在1_92另一个用户在10:05读取(1,jack)此时apply在1_93apply还没到1_95raft commit在1_97这时就记录该值(1_97)该值就叫readindexread的时候会等待一直等待到1_97apply后(1,jack)就能读取。 5.3 数据的读取Lease Read 10:00的时候Leader发了一个心跳heartbeat time interval为10秒那么在10秒内TiKV node 2一直是Leader如果心跳成功收到回复那么下一个时间间隔(heartbeat time interval)继续发心跳如果10秒内其他节点未收到心跳其他节点会认为集群是无主状态并且时间超过了election timeout则其他节点发起投票重新选举从10:00到election timeout的这段时间该Leader会一直是Leader读取就叫lease read。lease read又叫local read。 5.4 数据的读取 Follower Read
原理和indexread类似 10:00的时候(1,tom)修改为(1,jack)用户commit后此时Leader raft log为1-95然后10:05的时候用户去Follower读取(1,jack)此时Follower的raft commit为1-97,1-97就是readindex要等待Follower1-97 apply后才能读取到(1,jack)10:08的时候Leader的1-95apply成功(相当于用户commit成功了)实际上在Follower上还是读不到(1,jack)要到到Follower上的1-97apply后才能读取所以在10:10时Follower上apply了1-97此时Follower上就能读取(1,jack)
Leader Follower 有可能在Follower中读取的新值比在Leader中要快也就是说Leader中未读取到的值在Follower中已经有了Follower在10:06的时候1-97已经apply了而Leader在10:06后1-97才apply成功此时在Follower中就先读取到(1,jack)比在Leader中快原因就在于Follower apply的速度比Leader要快。 6. Coprocessor 当用户发送语句select count(*) from T; 如果把数据都读到TiDB上网络开销比较大cpu负载比较高。 当用户发送语句select count(*) from T;把count(*)计算下推到TiKV中做TiKV中的coprocessor分别在几个节点计算完然后汇聚在TiDB中TiDB在收到数据后进行二次整理(3339)这样TiDB压力就减轻了很多。
TiKV coprocesstor大多数都在执行物理算子为sql计算出中间结果减少TiDB的计算。
下推的物理算子包括
table scanindex scanselection过滤limit聚合采样分析数据统计信息对表进行校验 7. 小结
TiKV 的结构与作用TiVK 的持久化的数据读取原理TiKV 对于分布式事务和 MVCC 的支持TiKV 基于 Raft 算法的分布式一致性保证TiKV 的 coprocessor
来自TiDB官方资料
