Tikv Follower Read

Tikv版本6.0
请问Tikv Follower Read原理是什么呢?
Client在发送请求的时候会向PD要Region leader信息,如果是Follower Read,PD会随机的给Client Tikv节点地址吗?
Follower Read流程是什么呢?

视频课上将的非常详细,推荐看一下。

在默认配置下,TiDB采用"strong leader"策略,针对Region的读写请求都是由Leader来承担的。但是当TiDB中存在读热点Region时,Leader可能构成瓶颈。Follower Read是指在保证线性一致性读的前提下使用Region的Follower副本来承载数据的读取任务,从而提升TiDB集群的读吞吐能力并降低Leader负载。Follower Read包含一系列将TiKV读取负载从Region Leader副本offload到follower副本的负载均衡机制(根据负载均衡策略将某个Region的读取请求发送到Follower节点上)。要开启TiDB的Follower Read功能,将SESSION变量tidb_replica_read的值设置为follower或leader-and-follower即可


上图为Leader副本上COMMIT操作执行的过程:

  • 10:00:用户A发起COMMIT命令,commit_ts为10点整,它的raft log为1-95,仅持久化在了raftdb中,还未apply到kvdb上,只有当1-95在kvdb上apply成功后,COMMIT才能返回

  • 10:05:raftdb中日志增加至1-97,kvdb上日志应用到1-93,用户A的COMMIT还未返回

  • 10:08:kvdb上apply日志到1-95,即ApplyIndex为1-95,用户A的COMMIT操作成功返回


    上图为Follower副本上的读操作执行的过程:

  • 10:00:raftdb中,已经commit到1-96号日志,这点与Leader副本所在节点保持一致,但apply比Leader那边慢

  • 10:05:用户B发起Follower Read,会向Leader副本所在节点申请获取其raftdb中最新的日志为1-97,即CommitIndex为1-97

  • 10:10:CommitIndex日志在Follower副本所在kvdb被apply,用户B开始读取kvdb中的数据

事实上,Follower Read可能比默认从leader上读还要快,因为从leader上读取时必须等kvdb上apply到ReadIndex,也就是要等读操作前发起的COMMIT操作都执行完才能读取。而如果Follower所在节点的性能足够好,apply的足够快,那有可能在leader那边的COMMIT还没执行完,Follower这边已经apply到CommitIndex了,那么Follower Read就可以前开始从kvdb中读取数据,也不会破坏线性一致性

1赞

:+1::+1::+1:

牛牛牛,谢谢

:+1::+1::+1:

:+1::+1::+1: