etcd使用之ttl不准确问题

144次阅读

共计 2530 个字符，预计需要花费 7 分钟才能阅读完成。

问题现象

部署有一个 etcd 集群，分别是 10.8.65.106，10.8.65.107 和10.8.65.108。

然后我使用 etcdctl 为一个值设置 ttl，然后通过 watch 观察，发现失效时间不准确，而且时间随机。

比如我设置 /mytest/test 的 ttl 时间为 10 秒

[root@node-106 ~]# date &&etcdctl set --ttl 10 /mytest/test hello &&date
Fri Sep  2 05:31:10 EDT 2016
hello
Fri Sep  2 05:31:10 EDT 2016

这里采用的是东八区时间，所以 UTC 时间应该为2016-09-02T09:31:20

但是通过 watch 查看时候，发现 etcd 将其失效时间设置为了2016-09-02T09:31:18，而不是2016-09-02T09:31:20。

[root@node-106 ~]# curl -X GET "http://10.8.65.108:2379/v2/keys/mytest/test1?recursive=false&wait=true&stream=true"
{"action":"set","node":{"key":"/mytest/test","value":"hello","expiration":"2016-09-02T09:31:18.221701998Z","ttl":17,"modifiedIndex":306840,"createdIndex":306840}}
{"action":"expire","node":{"key":"/mytest/test","modifiedIndex":306844,"createdIndex":306840},"prevNode":{"key":"/mytest/test","value":"hello","expiration":"2016-09-02T09:31:18.221701998Z","ttl":9,"modifiedIndex":306840,"createdIndex":306840}}
{"action":"expire","node":{"key":"/mytest/test","modifiedIndex":306844,"createdIndex":306840},"prevNode":{"key":"/mytest/test","value":"hello","expiration":"2016-09-02T09:31:18.221701998Z","ttl":9,"modifiedIndex":306840,"createdIndex":306840}}

这个反复实验多次，发现理论失效时间 10 秒与实际失效时间的误差，最多可能到 9 秒，也有 0 秒。误差似乎是随机的。

问题分析

打开 debug 模式，进行详细分析。

[root@node-106 ~]# date && etcdctl --debug set --ttl 10 /mytest/test1 hello && date
Fri Sep  2 05:57:20 EDT 2016
start to sync cluster using endpoints(http://127.0.0.1:4001,http://127.0.0.1:2379)
cURL Command: curl -X GET http://127.0.0.1:4001/v2/members
cURL Command: curl -X GET http://127.0.0.1:2379/v2/members
got endpoints(http://10.8.65.107:2379,http://10.8.65.106:2379,http://10.8.65.108:2379) after sync
Cluster-Endpoints: http://10.8.65.107:2379, http://10.8.65.106:2379, http://10.8.65.108:2379
cURL Command: curl -X PUT http://10.8.65.107:2379/v2/keys/mytest/test1 -d "ttl=10&value=hello"
hello
Fri Sep  2 05:57:20 EDT 2016

可以看到 etcdctl 发起设置请求时，会首先获得集群的 members，然后向其中发送一个 set mytest/test1的请求。而这个请求会是随机的。如上是请求定位到了 10.8.65.107 之上。

之后我分别查看了三台机器的时间，发现三台时间不同步。初步判断是时间不同步导致的，因此这里使用 ntp 进行同步。

[root@node-106 ~]# ntpdate pool.ntp.org
 2 Sep 05:45:23 ntpdate[24846]: adjust time server 120.25.108.11 offset -0.000273 sec

之后再进行 ttl 设置，失效时间恢复准确。

回顾与解决

回顾整个问题，主要原因还是时间不同步。之后再出现该问题时，可以根据返回值进行判断。

[root@node-106 ~]# curl -X GET "http://10.8.65.108:2379/v2/keys/mytest/test1?recursive=false&wait=true&stream=true"
{"action":"set","node":{"key":"/mytest/test","value":"hello","expiration":"2016-09-02T09:31:18.221701998Z","ttl":17,"modifiedIndex":306840,"createdIndex":306840}}