我添加了一个循环,尝试从数据库读取数据,如果尚不可用,则休眠 250 毫秒,然后重试。它的工作原理是,它最终会检索数据,但与没有循环相比,这样做所需的时间增加了 1 秒。
旧代码:
data, err := db.Read(key)
if err != nil {
return err
}
...handle data...
新代码:
var data string
var err error
for {
data, err = db.Read(key)
if len(data) > 0 {
break // it worked
}
if !strings.Contains(err.Error(), "not found") {
return err
}
time.Sleep(250 * time.Milliseconds)
}
...handle data...
在旧的情况下,它在 70% 的时间内有效。整个过程大约需要2秒就成功。
在第二种情况下,95% 的时间都有效,大约需要 3 秒才能成功。
我非常确定数据会在 250 毫秒到 500 毫秒内变得可用。然而,运行该过程的时间显然增加了 1 秒。我认为虚拟机(例如运行 Docker 的 Google Cloud pod)上的
time.Sleep()
命令无法访问如此高精度的时钟。
我的问题是:您是否有机会验证虚拟机时钟以查看亚秒级睡眠是否能够非常一致地工作(或不工作)?对我来说,感觉就像这样的睡眠等待下一秒然后醒来。因此,有时它可能接近 250 毫秒,很多时候可能接近 750 毫秒,具体取决于当前秒内的开始位置。
我认为虚拟机(例如运行 Docker 的 Google Cloud pod)上的 time.Sleep() 命令无法访问如此高精度的时钟。
这绝对不是真的。在这样的共享环境中,您可能会有更多的计时抖动,但计时分辨率与您在任何现代 Linux 系统上发现的相同,当然远没有整秒那么粗糙。