【TiKV / HTAP 内核】新鲜度与一致性：safe-ts 如何定义可见时延
内容提要
本文讨论了TiFlash中的safe-ts机制，确保数据读取的一致性和可见性。safe-ts是一个时间戳，表示所有提交的事务已在TiFlash副本上完成。可见时延通常在亚秒级，由日志复制、应用和锁解析等因素决定。TiDB与TiFlash结合实现了准实时的快照一致性，而非最终一致性。文章还探讨了故障场景下的新鲜度退化及主动接受陈旧数据的选项。
关键要点
-
safe-ts 是一个时间戳，表示所有提交的事务已在 TiFlash 副本上完成。
-
可见时延通常在亚秒级，由日志复制、应用和锁解析等因素决定。
-
TiDB 与 TiFlash 结合实现了准实时的快照一致性，而非最终一致性。
-
safe-ts 的推进依赖于 Raft apply 位点的最大 commit_ts 和未决事务的 resolve 结果。
-
可见时延由提交到日志复制、日志 apply、safe-ts 推进和查询等待等多个阶段构成。
-
TiFlash 的新鲜度在故障场景下会退化，但不会读到错误结果。
-
TiDB 提供了主动接受陈旧数据的选项 Stale Read，以换取更低延迟或更均衡的负载。
-
safe-ts 保证的快照一致性与最终一致性不同，后者不承诺任何时刻读到的数据处于某个确定的逻辑时间点。
-
safe-ts 的定义与外部一致性（External Consistency）存在差距，TiDB 的 TSO 没有提供硬件级误差区间。
-
常见误解包括将 TiFlash 视为最终一致性和认为新鲜度只取决于网络延迟。
延伸解读
safe-ts 的重要性
safe-ts 是 TiFlash 中确保数据一致性和可见性的关键机制。它通过时间戳来标识所有已提交事务的状态，确保查询时读取的数据是最新的快照。这一机制的有效性直接影响到数据分析的准确性和实时性，因此在使用 TiFlash 时，理解 safe-ts 的推进机制至关重要。
可见时延的影响因素
可见时延是影响 TiFlash 数据读取速度的关键因素，主要由日志复制、日志应用和锁解析等多个阶段构成。特别是未决事务和锁的堆积，往往会导致 safe-ts 的推进受阻，从而延长可见时延。因此，在优化 TiFlash 性能时，需关注这些潜在的瓶颈。
新鲜度退化的场景
在 TiFlash 中，新鲜度退化通常发生在节点短暂下线、Region 迁移或大批量数据导入等情况下。这些场景会导致 safe-ts 的推进变慢，但不会导致读取错误结果。了解这些场景有助于用户在遇到数据延迟时进行有效的故障排查。
主动接受陈旧数据的选项
TiDB 提供了 Stale Read 选项，允许用户主动接受陈旧数据以换取更低的延迟。这一机制在高并发场景下尤为重要，可以有效缓解因等待新鲜度而导致的性能瓶颈。然而，用户需谨慎使用，以确保数据的准确性和一致性。
延伸问答
什么是safe-ts，它的作用是什么？
safe-ts是一个时间戳，表示所有提交的事务已在TiFlash副本上完成，确保数据读取的一致性和可见性。
可见时延是如何影响数据读取的？
可见时延是事务提交到分析查询能读到该提交之间的时间差，通常在亚秒级，由日志复制、应用和锁解析等因素决定。
TiDB与TiFlash的结合实现了什么样的一致性？
TiDB与TiFlash结合实现了准实时的快照一致性，而非最终一致性，确保查询结果与特定时间点的数据一致。
在故障场景下，TiFlash的新鲜度会如何退化？
在故障场景下，TiFlash的新鲜度会退化，但不会读到错误结果，查询可能会等待safe-ts推进或回退到TiKV读取。
什么是Stale Read，它有什么用？
Stale Read是TiDB提供的选项，允许主动接受陈旧数据，以换取更低延迟或更均衡的负载。
safe-ts与外部一致性有什么区别？
safe-ts保证的是快照一致性，而外部一致性要求跨数据中心的多个观察者看到的事件顺序与真实物理时间一致，二者的保证层级不同。
