Time 确定过期-分布式节点-无需同步时钟

我有以下问题：

引线服务器创建具有开始时间和结束时间的对象。创建对象时设置开始时间和结束时间

对象的开始时间设置为引线节点上的当前时间，结束时间设置为开始时间+增量时间

线程定期唤醒并检查任何对象的结束时间是否小于当前时间（因此该对象已过期）-如果是，则需要删除该对象

只要在leader节点上运行顺利，所有这些都可以正常工作。如果引线节点下降，则其中一个跟随节点将成为新引线。（将在先导节点和跟随节点之间进行复制（RAFT算法））

现在，对于新领导人，时间可能与前任领导人大不相同。因此，步骤3中的计算可能会产生误导

解决此问题的一种方法是（尽可能）保持节点（领导者和追随者）的时钟同步

但我想知道是否有其他方法可以解决分布式节点的“过期”问题

进一步资料：

将使用RAFT协议进行消息传递和状态 复制

它将具有进程间消息延迟的已知界限

允许先导和跟随器故障（根据RAFT协议）

假定不会发生消息丢失（RAFT确保这一点）

对对象的操作是检查它们是否处于活动状态。对象将由客户端排队

各流程之间将有很强的一致性（RAFT提供了这一点）

---

如果您知道节点在某个epsilon内同步到某个绝对时间，那么简单的解决方案可能就是将epsilon烘焙到垃圾收集方案中。正常情况下，NTP的ε约为1ms。使用像PTP这样的协议，它将远低于1ms

然而，绝对时间在分布式系统中并不存在。依赖它可能是一个瓶颈，因为它意味着所有节点都需要通信。避免这种情况的一种方法，通常是同步，就是使用一个或一个间隔树时钟来保持事件的相对序列。这避免了将绝对时间作为状态进行同步的需要。由于序列描述相关事件，其含义是只有具有相关事件的节点才需要通信

---

因此，通过垃圾收集，可以使用节点序列号将对象标记为过时。然后，与垃圾收集器线程检查活动性不同，对象可以按序列号的增量进行收集，也可以只标记为过时并异步收集。

我看到了两种不同的方法。这两种方法都保证时间不会倒退，因为如果通过NTP同步时钟或使用系统时钟，可能会发生这种情况。特别是，这两种方法都利用芯片时钟来严格增加时间。（

System.nanoTime

在Javaland中）

这些方法仅适用于过期：时间不会回归，但时间可能会变慢

第一种方法 第一种方法有效，因为您使用的是raft集群（或类似协议）。它的工作原理是将一个不断增加的时钟从领导者广播到复制品

每个对等点维护我们称之为集群时钟的，该时钟几乎实时运行。先导通过raft定期广播时钟值

当对等机接收到该时钟值时，它会将其与当前芯片时钟值一起记录。当对等方被选为领导者时，它可以通过比较其当前芯片时钟与上次记录的芯片时钟值来确定自上次时钟值以来的持续时间

奖金1：集群时钟值可能会附加到每个转换，而不是有一个新的转换类型，在安静期间，领导者不会进行op转换，只是为了向前移动时钟。如果可以，将其连接到筏心跳机制

奖金2：我维护一些系统，在这些系统中，每次转换的时间都会增加，即使在同一时间段内。换句话说，每个转换都有一个唯一的时间戳。为了在不使时间过快地向前移动的情况下工作，时钟机制的粒度必须能够覆盖预期的转换速率。毫秒仅允许1000 tps，微秒允许1000000 tps，等等

第二种方法 每个对等机在接收到每个对象时只记录其芯片时钟，并将其与每个对象一起存储。这保证了对等方永远不会在领导者之前使对象过期，因为领导者记录时间戳，然后通过网络发送对象。这创造了一种严格的先发生后关系

---

然而，第二种方法容易受到服务器重启的影响。许多芯片和处理环境（如JVM）会在启动时将芯片时钟重置为随机值。第一种方法没有这个问题，但成本更高。

对象过期和删除是否严格取决于绝对（同步）时间？不，不需要。重要的是，在创建和过期之间经过一段时间使用此解决方案，我必须增加对象上的时钟值？如果是，那么线程增加对象上的时钟值会增加额外的复杂性？@Ngm这是两种可能的解决方案。第一个是有界时间偏移的情况（我称之为ε）。设置对象过期时间时，它将是

T+/-ε

。然后，任何过期的节点都将在

+/-2ε

范围内（每个节点都具有有界偏移ε）。您可以添加或减去

2ε

，这取决于您是想延迟还是提前到期。第二种解决方案更通用。而不是

T

b