在路上2021-11-30徐老师好，在Spanner论文的最后一页，描述了Paxos Leader-Lease Management，证明了Leader切换后时间戳的单调递增性。Leader选举需要多数Paxos成员的支持，所以一定存在一个Paxos成员同时参与了前后两轮选举，假设这个成员为r0，任何Paxos成员参与Leader选举之后，10秒之内不会再参与选举，Leader租期的结束时间由投支持票的Paxos成员的投票时间决定，选择最小的投票时间加上10秒。如果r0的投票时间是最小时间，那么下一轮Leader选举响应时间在10秒后，Leader切换后时间戳单调递增。如果r0的投票时间不是最小时间，那么下一轮Leader选举响应时间更在10秒后，Leader切换后时间戳单调递增。这个说明过程省略了earliest和latest之分，更详细的可以看看论文。9- 在路上2021-12-02徐老师好，论文第4.2.2节提到，如果只读事务只涉及一个paxos group，读操作的时间戳选择Leader的LastTS()，如果涉及多个paxos group，读操作的时间戳选择本地的TT.now().latest()，这个时间可能会超过t_paxos_safe，需要等待safe time的推进。在没有新的事务发生时，如果依靠每8秒钟更新一次的MinNextTS(n)推进safe time，我觉得读操作太慢了。我在Life of Cloud Spanner Reads & Writes中读到多节点的Strong Read，副本不知道自己是不是最新的情况会去请求Leader，我觉得这是更快的方法。3
- Helios2021-12-29一般的数据中心没有原子钟和 GPS 时钟，是不是就不适合使用spanner这类的数据库了呢。或者用了话，导致时间区间会很大1
Eternal2023-03-28 来自重庆粗浅理解：所有事务请求都是按照全局绝对时间来顺序执行的，通过在不同事务时间点前后插入误差时间来使得事务之间是按照绝对时间串行执行。然后通过原子钟+GPS来保障绝对时间误差足够小，最坏情况是7毫秒，也就是极限情况2阶段来算，每个事务可能浪费2阶段*14ms=28毫秒，这是最坏的情况，实际可能更小；那这样来的话，全局时间就是一个单点了，如果后续技术进步，全局时间的误差能控制得更小，比如1ms内，那简直就是完美
霍彦文2022-01-03老师我们会有这批论文的解读吗？ lightning: HTAP as a service - ACM Digital Library