谷歌、Meta等四大科技巨头倡议废除闰秒
谷歌、Meta等四大科技巨头倡议废除闰秒,谷歌、微软、Meta和亚马逊近日呼吁废除闰秒,美国和法国已对此表示赞同。谷歌、Meta等四大科技巨头倡议废除闰秒。
谷歌、Meta等四大科技巨头倡议废除闰秒1大厂们再也无法忍受闰秒带来的一堆bug了。
现在,谷歌Meta微软亚马逊等一众科技巨头发起了一项倡议:废除闰秒!
闰秒这玩意,说白了就是通过给“世界标准时间”加(或减)1秒,让它更接近“太阳时”。
“世界标准时间”(UTC)与原子钟测量的精确时间同步,“太阳时”根据地球自转测量得出,但地球自转并不稳定。
例如,两者相差超过0.9秒时,就在23点59分59秒与00点00分00秒之间,插入一个原本不存在的“23点59分60秒”,来将时间调慢一秒钟。
然鹅,就是这个看似有点用的闰秒,把一众程序员愁坏了。
凭空少一秒、或冒出一个“第60秒”,就得出动一众人调整时间(如暂时关闭NTP等)、修改程序,尽可能降低闰秒带来的影响。对此Meta表示:
闰秒造成的破坏,比它带来的用处大多了。
这群大厂还找来了两家权威机构,即美国国家标准与技术研究院(NIST)和国际计量局(BIPM),与他们达成了一致意见。
虽然闰秒似乎离我们略远,不过这些年来,它确实给计算机行业惹了不少麻烦。
“1秒钟”让计算机宕机
闰秒于1972年被引入,迄今为止已经增加了27个闰秒。
每一次增加闰秒,都会引起不少公司的计算机或是应用程序出现问题。
例如,在互联网发展得如火如荼的2012年,闰秒就带来了一波“潮水般”的影响。
闰秒在当年6月30号出现后,国外社区Reddit、浏览器Mozilla、领英和点评网站Yelp的服务器全部出现了问题,此外依赖计时器的机票预订服务Amadeus也发生了故障。
但闰秒造成的影响,并没有在这之后消失,毕竟总有新的bug出现(手动狗头)。
2017年,Cloudflare也遇上了闰秒故障,导致一众客户用不了相关服务。尽管程序员们已经提前写好应对程序,然而在实际运行时,还是出了问题。
所以,究竟应该如何消除闰秒带来的影响?
当前最常用的方法是“平摊法”。
以谷歌为例,程序员们会将多出来的一秒钟分割成很多个小时间段(如几分之一秒),然后,在不影响程序运行的情况下悄悄加入到时间中。
这样,当闰秒来临时,程序实际上已经平安无事地度过了这一秒钟。
对于Meta程序员来说,采取的也是相似的做法,把这个闰秒在时间表上悄无声息地“抹掉”。
但无论如何,只要下一个闰秒还会出现,大厂们就还得继续面临闰秒带来的影响,花费额外的精力去“消除”它。
包括谷歌、亚马逊、Meta和微软等大厂在内,都感觉闰秒的出现是利大于弊,Meta还专门写了篇文章,呼吁废除闰秒。
当然,想废除闰秒的也不止这几个大厂。
早在2015年的时候,国际电信联盟就在WRC上讨论过是否要保留闰秒的事情。
只是报告结果还没出来,预计会等到2023年。
对于废除闰秒这事儿,有网友调侃:
Meta的开发们实在太害怕闰秒了,他们觉得推动计时法改变是比修代码更简单的事情。
但此前也有网友提到,其实不止IT行业,工业上也会受到闰秒的影响。
你受到过闰秒带来的影响吗?
谷歌、Meta等四大科技巨头倡议废除闰秒2在某些时候,如果你遭遇过网络中端或者服务中断,这可能是闰秒引起的。所谓闰秒,是指为了保持协调世界时接近于世界时时刻,由国际计量局统一规定在年底或年中(也可能在季末)对协调世界时增加或减少1秒的调整。
7月26日消息,谷歌、微软、Meta和亚马逊近日呼吁废除闰秒,美国和法国已对此表示赞同。谷歌等科技巨头抛弃闰秒的理由有很多,比如网络中断等。
这样的例子有很多。2012年,闰秒的变化引发Reddit的大规模停机,Mozilla、LinkedIn、Yelp和机票预订服务Amadeus也都遇到过类似问题。2017年,Cloudflare因此遭遇故障,导致客户一部分服务器离线。此外,在今年早些时候,当网络浏览器的版本号达到100时,一些网站因编程只处理两位数的版本号而发生堵塞。
Meta的研究科学家艾哈迈德·拜亚戈维(Ahmad Byagowi)称:“我们预测,如果我们只坚持使用‘国际原子时’,而不进行闰秒观测,那么我们应该至少可以坚持2000年。就此而言,我们可能需要考虑进行修正。”美国国家标准与技术研究所(NIST)和法国国际计量局(BIPM)也认为,是时候该要抛弃闰秒了。
据了解,自1972年以来,世界计时机构已经为被称为“国际原子时”(TAI)的全球时钟增加了27次闰秒。
谷歌、Meta等四大科技巨头倡议废除闰秒3“闰秒”可能会被取消。
据科技新闻网站Cnet报道,7月25日,谷歌、微软、Meta和亚马逊四位科技巨头呼吁废除闰秒,美国国家标准与技术研究院( NIST ) 与国际计量局 ( BIPM )也投出了赞成票。
国际地球自转服务(IERS) 于1972年首次提出闰秒这一概念。当世界标准时间“协调世界时”与“世界时”之间的误差超过0.9秒时,国际计量局会统一规定在年底或年中将“协调世界时”拨快或拨慢1秒。
1972年以来,闰秒已经出现过27次,上一次是2017年1月1日7时59分60秒。当“正闰秒”发生时,一分钟将有61秒——23:59:59之后不是00:00:00,而是会多出另一个23:59:60。多出的'这一秒会导致计算机产生“错乱”,因为计算机依靠精准的计时服务器展开活动,记录向数据库更新等事情的准确顺序。
在过去,闰秒曾多次给网络平台造成故障。据科技媒体WIRED, 2012年,社交网站Reddit因为闰秒而遭遇一次大规模停机,用户在30到40分钟内无法访问此网站,工程师不得不重启服务器。据英国卫报,开源社区Mozilla、社交平台LinkedIn、美国商户点评网站Yelp和机票预订供应商Amadeus也都遇到过类似情况。
此外,2017年,美国云安全网络公司Cloudflare受闰秒影响,导致托管在该公司的部分网络资源暂时脱机。
针对闰秒问题,谷歌曾于2011年提出“闰秒弥补(leap smear)”方案——调整系统内部的网络时间协议(NTP)服务器,每次更新时增加几毫秒,弥补闰秒多出来的那一秒钟,以保证服务器能够正常运行。
但Meta工程博客页面上的公告中,Meta工程师Oleg Obleukhov和Ahmad Byagowi表示,这一方案只适用于解决“正闰秒”出现的情况,随着地球自转模式的改变,未来还可能出现“负闰秒”。不彻底解决这一问题,“将对依靠计时器或调度器的软件带来毁灭性的影响。”
上述工程师还表示,如果取消闰秒,不再继续调整时间,未来1000年内可能不会再出现类似问题。
如今,谷歌、微软、Meta和亚马逊共同呼吁取消闰秒,美国国家标准与技术研究院( NIST ) 及国际计量局 ( BIPM )也同意这一主张。
CNET称,政府机构的支持至关重要,归根结底负责全球时钟系统的是政府和科学家,而不是科技公司。
a. 若由于其他原因实在无法进行内核升级,且应用对时间的敏感度不是非常高,容许有1秒钟的差值,有如下建议:
对于使用ntpd服务进行时间同步的RHEL,至少提前1天停止ntpd服务。并确保每台
机器上安装的tzdata的版本低于2011n-2(不 包含该版本)。
对于不使用ntpd服务进行时间同步的RHEL,确保每台机器上安装的tzdata的版本低
于2011n-2(不包含该版本)。
从而使系统不进行闰秒调整,待该事件完成之后,再可启动ntpd服务进行同步,或
者手动修改时间为正确时间。 www.2cto.com
提示:对于内部的以RHEL作为NTP服务器的系统,它是NTP服务器的同时,也是使用
ntpd服务与更上层NTP服务器进行时间同步的客户端, 故上述方法也适用于该系统。
b. 若由于其他原因实在无法进行内核升级,但应用对时间的敏感度非常高,不容
许有1秒钟的差值,则有可能发生kernel hang住的问题,尽管这个可能性是非常小的。
如果发生问题,可考虑重启该系统恢复。
根据这个情况,相应的解决方法如下:
如相关设备是使用Linux kernel 为2.6.18-164.e15以前的Linux系统,请做如下预防工作:
1、2012年6月28日当天(北京时间23点以前)先确认ntp服务已同步,然而关闭ntpd服务。
2、2012年7月2日(北京时间8点以后)当天开启ntpd服务,并确认ntp服务已同步。
对照上面的解决方法,检测所有服务器(100多台,累死了),发现rhel5.4服务器的内核都为2.6.18-164.e15,但都没有开启ntp服务,而所有的SUSE Linux Enterprise Server 10 的linux系统里内核都是2.6.16.60-0.54.5-smp,就1台数据库服务器启动了ntp服务,下面演示是如何的解决这个问题方法:
1、先查看服务器是否有开启ntp服务,可以使用以下命令查询:
netstat -aunl|grep123 #由于123是ntp启动的端口,所有可以使用netstat来查看ntp的123端口,查看ntp服务是否启动;
ps -ef|grep ntp #查看ntp服务的进程是否在后台运行;
service ntp status #使用service来查看ntp服务的启动状态
下面是使用这3中方法进行的检测结果
www.2cto.com
可以看得我的服务器里ntp服务正在运行
关闭是方法如下:
直接杀掉ntp的进程,命令为:kill -9 $(ps -ef|grep ntp|grep -v grep|awk '{print $2}');
使用service来关闭ntp,命令为:service ntp stop;
关闭后为了保证安全,还需要把ntp开机自动启动给关闭,命令为:chk
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)