客户端秒级时间同步方案

在客户端开发中,往往会有一些功能对时间要求比较严格,客户端需要获取到当前最准确的时间。但由于客户端环境多种多样,我们无法保证直接在客户端设备上获取到的时间是最准确的时间。

对于某些问题设备来说,设备时间与比当前实际的时间差了几个小时,甚至几天的情况都存在。倘若某功能依赖于当前时间,而客户端所提供的时间不准,就往往会给客户造成一些困扰。

那么,客户端如何能够获取到当前最准确的时间呢?

从服务器同步时间

我们首先想到的是,服务器可以提供一个获取当前时间戳的接口。客户端每次获取当前时间时,都直接从服务器拉数据就可以了。

这个方案简单粗暴,但是问题也可以一眼看出:

每次都从服务器拉时间,一方面会对服务器造成一些压力;另一方面网络也存在时延损耗和不稳定的可能,将会减低客户端的体验。

只拉取一次时间

那么,能不能只从服务器拉取一次时间,不用每次都访问服务器呢?

我们可以在客户端初始化的时候,拉取一次时间接口。

记此时的服务器时间为server_init_time,同时获取到当前客户端的时间, 记为local_init_time

当客户端需要获取当前的准确时间的时候,首先得到客户端的当前时间 记为local_now_time

那么,当前最准确的时间就可以通过一个简单的差值计算得到。

server_now_time = server_init_time + (local_now_time - local_init_time)

通过计算两次本地时间的差值,就可以推出当前服务器的时间了。

网络时延的损耗

上述方案实际上已经能够准确的获取到当前服务器的时间了。

但是仍然有个不严谨的地方:

在该方案中,我们假设server_init_time和local_init_time是同一时刻。

但实际上并不是这样的。server_init_time只是http请求到达服务器的时间。

server_init_time和local_init_time还差一个请求返回时间。

网络时延

我们都知道网络是不可靠的,严重情况下,一次网络时延可以达到数秒。这对于时间校准的也会造成一些小小的干扰。

基于这个问题,我们可以假设客户端发出请求到服务器的时间服务器回复请求到客户端的时间基本是一致的。虽然在实际情况下,有可能存在偏差。

此时

server_init_time = server_init_time - delta / 2;

其中delta是指一次请求的总时延。

防止客户端运行期间时间改变

基于以上考虑,我们的时间校准方案已经基本上可以满足大多数客户端的需求了。

但是,你永远也不会知道客户端会出现什么情况。

假如,在软件运行期间,无论是出于被动还是用户有意主动的修改,客户端的时间发生了变化。那么,以上通过计算两次本地时间差值来获取准确时间的方案将会失效。

因此,我们需要使用一个不随本地时间变化的维度作为校对的标准。我们首先想到了开机时长,开机时长是指当前时刻距离设备开机时刻的毫秒数,而这个东西是不随设备的时钟变化的。

因此我们的公式可以修改为:

server_now_time = server_init_time + (local_now_tickcount - local_init_tickout)

local_now_tickcount和local_init_tickout分别指的是设备当前的开机时长和初始化阶段用户的开机时长。

时间溢出

使用开机时长作为校对的标准的方案,看似完美无缺,实际上仍然存在着一些意想不到的问题....

以Windows为例,C#用来返回开机时长的方法Environment.TickCount是int32类型的,单位为ms。

我们可以简单计算下,一天大概有 24 * 60 * 60 * 1000 = 86400000 毫秒,而int32的最大值是2^31 - 1 = 2147483647

这也就意味着,当开机时间超过2147483647 / 86400000 = 24.85 天的时候int32就溢出了。。

也就意味着,如果我们的客户端软件运行在一个25天未关机的设备上,那么软件的时间校准将会出现严重的问题。。。

在真实的情况下,客户端设备25天不关机的情况太常见了。

那么,如果解决此问题呢?

我们发现C#有一个StopWatch函数,常常用来统计函数运行时长。而它的时间表示stopWatch.ElapsedMilliseconds是long型的。同时,StopWatch是基于Timer实现的时间统计,也不与本地时钟相关。

那么,与利用开机时长的方案类似,我们在软件初始化时,开启一个StopWatch。每次获取准确时间的时候,将stopWatch中记录的当前耗时时间与服务器初始时间相加,即可得到当前的准确时间。

最终的时间校准方案如下:

server_init_time = server_init_time - delta / 2;
server_now_time = server_init_time + stopWatch.ElapsedMilliseconds / 1000

基于该方案,我们就实现了一个秒级的时间同步方案

本文首发于腾讯云+社区,稍后同步于博客www.cyhone.com

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏恰同学骚年

【大型网站技术实践】初级篇:借助LVS+Keepalived实现负载均衡

  当前大多数的互联网系统都使用了服务器集群技术,集群即将相同服务部署在多台服务器上构成一个集群整体对外提供服务,这些集群可以是Web应用服务器集群,也可以是数...

772
来自专栏枕边书

Linux“体检”指标

前言 在“求佛保佑服务器不宕机”、“杀程序员祭天”的环境下,程序员每天可谓是战战兢兢,接到电话和短信都吓得瑟瑟发抖,为了我们的安全,及时发现服务器运行问题已不仅...

1876
来自专栏北京马哥教育

13 种在 Linux 系统上检测 CPU 信息的工具

根据你的需要,有各种各样的关于你的CPU处理器信息你需要了解,比如CPU供应商名、模型名、时钟频率、插槽/内核的数量, L1/L2/L3缓存配置、可用的处理器...

2739
来自专栏ASP.NETCore

讨论.NET Core 配置对GC 工作模式与内存的影响

https://mp.weixin.qq.com/s/PqhUzvFpzopU7rVRgdy7eg

753
来自专栏沃趣科技

ASM 翻译系列第三弹:基础知识 About ASM disk groups, disks and files

原作者:Bane Radulovic 译者: 赵恩东 审核: 魏兴华 DBGeeK社群联合出品 Oracle ASM使用磁盘组来存放数据文件,每一个...

3748
来自专栏数据和云

RAC一个节点自动重启问题分析

题记:在RAC数据库的故障当中,节点重启的现象很常见,在这种问题的处理当中,有一定的规律性。为了更好的说明这个问题的处理过程,保证出现该类问题的时候,能够有序的...

3215
来自专栏公有云大数据平台弹性MapReduce

Redis 单机主从高可用性优化

redis是一款高性能的内存数据库,本文侧重描述redis在主从模式下遇到的一些问题以及如何调优,特别是在云环境下遇到的一些特殊问题,至于redis如何使用以及...

4.7K0
来自专栏Hadoop实操

HOSTS配置问题导致集群异常故障分析

CM节点上的所有服务的角色日志不能正常通过ClouderaManager控制台查看,显示如下错误:

3919
来自专栏Java学习123

Jboss调优——最佳线程数

2595
来自专栏个人分享

分布式系统中的线程与进程

  虽然进程构成了分布式系统中的基本组成单元,但是操作系统提供的用于构建分布式系统的进程在粒度上还是太大了,而就粒度而言,将每个进程细分为若干控制线程的形式则更...

491

扫码关注云+社区