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 就会发出警告，提示两者的时钟有较大的不同步。