https://docs.pingcap.com/zh/tidb/v6.0/cached-tables
读操作会刷新缓存的租约，在租约内写操作会被阻塞。那么在缓存没有过期，并且写操作被阻塞期间，如果不断有读操作来刷新租约，那么写操作会不会饿死？写操作阻塞期间的读操作读的是缓存还是TiKV?
读操作会刷新缓存的租约是从哪里看到的呢，租期的时间是由 tidb_table_cache_lease控制的。写操作期间的读操作读的是TiKV。
上面官方文档连接中有这么一句话：
缓存表的实现使用了一套基于 lease 的复杂机制：读操作在缓存数据同时，还会对于缓存设置一个有效期，也就是 lease，我理解意思就是每次读都要去设置这个lease，相当于刷新lease的时长了
不会的，每次读都要去设置这个lease的话对于访问频繁的表写操作就永远无法进行了。如果缓存表上没有读，也就不存在lease，可以直接写入。一旦有读就会设置租期，这时候写会阻塞，等租期过期后新的读会设置租期，租期内读操作不会刷新租期，我是这么理解的。
“写操作期间的读操作读的是TiKV”
这个写操作期间，是从被租约阻塞那一刻t1开始算，还是从解除阻塞真正开始执行时t2开始算？如果是t2，那t1~t2这个时间段中，读操作是落在cache还是TiKV上的？
读操作在缓存数据同时，对于缓存设置一个 lease有效期.在 lease 过期之前，写操作无法对数据执行修改操作。所以会导致写入延迟。延迟的时间受全局变量tidb_table_cache_lease控制。
缓存表首次加载从TiKV中读取，后续的读写应该都是访问内存中的缓存数据。
1 个赞
对的，从t2开始，这时候读操作落在tikv上
那t1～t2这个时间段中，读操作是读缓存表还是tikv？
主要是从文档中，看不出这这一块儿是如何设计的，按照我的理解，有两种可能：
假设写操作到来并开始阻塞的时刻为t1，解除阻塞开始执行的时刻为t2
方案一：每次读操作都去续租，读操作发现有写操作被阻塞时，便去读tikv，即t1至t2时段的读操作落在tikv上，此时自然就不会有读操作去续租，写操作在t2时刻便可以执行。这种方案的优势就是读性能稳定，缺点是写操作阻塞期间，只能去读tikv
方案二：读操作发现续约到期后再去续约，t1～t2时刻的读操作落在缓存表上。这种方案的优势就是不会频繁去刷新租约，并且写阻塞期间也能从缓存读，缺点就是租约一到期就要重新把数据从tikv读到缓存再续租，读性能会周期波动
以上就是我的推测，不知道是哪种方案
从我这边测试的结果看是方案二，可以实际测试看看。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。