Tikv Follower Read

🪐 TiDB 技术问题
1

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

2

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

在默认配置下，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即可

1
1953×392 74 KB

上图为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操作成功返回

    2
    2950×368 72.3 KB

    上图为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 个赞
3

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

4

牛牛牛，谢谢

5

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

6

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