etcd节点系统时间不一致的影响

问题现象:

the clock difference against peer xxxxxxx is too high [秒数xxx s> 1s]

原理分析

有关 Etcd TTL 的实现原理分析如下:

Etcd Server 在接受客户端的 PUT 请求时,会解析 PUT 请求参数,如果里面包含 TTL 参数,则会将 TTL 的值加上自己系统的当前时间,以此作为 key 的过期时间。由于 Etcd Server 端极有可能是 Leader,也可能是 Follower,因此系统时间即可能是 Leader 节点的,也有可能是 Follwer 节点的。假设系统当前时间是 1:00:00,TTL 是 10s,则 key 的过期时间是 1:00:00,默认情况下系统会在 1:00:10 时删掉这个 key。

执行完以上操作之后,Etcd 节点会再次将这个客户端请求通过 Raft 协议的 RPC 消息同步到其他节点上。这里有一个有趣的细节,即如果接受客户端请求的是 Leader,则直接同步;如果是 Follower,额先把请求转发给 Leader 再由 Leader 同步给其他节点,但是该 key 的 "expiration" 值以接收请求的那个 Follower 设置的值为准。Etcd 在将这个请求写盘的同时,将会设置过 TTL 的 key 加入到一个有序的 map 里面,姑且称之为 ttlKeyHeap。

在 Leader 中运行一个 tick,将会每 500ms 触发一次,这个 tick 也因此会产生一个 sync 消息,这个 sync 消息里面带有一个 Time,这个 Time 是 Leader 所在节点的系统时间,姑且称之为 syncTime。Leader 把 sync 消息通过 Raft 协议广播给其他所有节点,这个 sync 消息就是告诉所有节点把在 syncTime 之前要过期的 key 都删除掉。具体就是各个 Etcd 节点查询 ttlKeyHeap,拿 expiration 小于 syncTime 的 key 都删除掉。

影响结果

从上面的描述可以看出,如果 Etcd 节点之间系统时钟不同步,准确地说就是接受写请求的节点与 Leader 的系统时间不一致,就可能会出现定义了 TTL 的 可以被早删或者晚删的情况。因此,当 Follower 与 Leader 的系统时钟相差 1 秒以上,Etcd 就会发出警告,提示两者的时钟有较大的不同步。

你可能感兴趣的:(Ops,etcd,数据库)