本文来自微信公众号： 宇众不同的露萱 ，作者：宇众不同的露萱，原文标题：《为什么 Google 要重新定义一秒钟？》

在写代码的时候，我们习惯了调用System.currentTimeMillis()，默认拿到的就是一个平滑、单调、绝对向前的数字。这种感觉就像我们呼吸空气一样自然——时间嘛，不就是一直在往前走吗？

直到线上第一次碰到因为时间回拨导致的分布式ID重复事故，我才被现实狠狠补了一课。

后来我去翻Google关于TrueTime和Leap Second（闰秒）的工程文档，心里最大的感触不是“这套方案有多牛”，而是一种极其荒谬的落差：

我们今天支撑着整个现代文明的计算机网络，底层居然建立在一个连“一秒钟有多长”都说不清楚的脆弱基石上。

为了不让这个基石崩塌，Google干脆做了一件听起来有点霸道的事情：他们单方面决定，在某些日子里，重新定义软件世界里的“一秒钟”。

很多关于闰秒的文章，一上来就喜欢从地球自转减慢、潮汐摩擦开始讲起。

这些天文知识当然没错，但天文学家的烦恼，原本是不需要软件工程师来买单的。

天文学家的时间叫UT1，是以地球自转为基准的——地球转一圈就是一天，平分给86400秒。但现实是，地球这个大石头一点都不规整，内部岩浆在涌动，表面海水在摩擦，甚至连板块地震都会改变它的转速。所以，物理世界里的“一天”，从来都不是精准的86400秒。

而计算机科学家用的是原子钟（TAI），靠铯原子振荡来计数。原子钟极度精准，它不在乎地球怎么转，它的秒是绝对均匀的。

这两拨人凑在一起，矛盾就出来了。

天文学家说：“太阳升到最高点必须是中午12点，你原子钟走得太快，和地球自转偏了，你得等等我。”计算机派说：“我的逻辑只要求绝对单调，你一会儿走得快一会儿走得慢，我的系统怎么算高并发事务？”

最后在1972年，大家搞了个折中方案，叫协调世界时（UTC）。规则很粗暴：以原子钟为准，但如果和地球自转偏差快超过0.9秒了，就在某个月的最后一天，强行插进1秒。

这就是那个著名的23:59:60。

第一次读到这里的时候，我其实觉得挺神奇的——时间居然能出现60秒。但如果你写过基础库或者内核代码，你就会明白，这对于计算机来说根本不是神奇，这是一个噩梦。

计算机的最大愿望，其实就是大家都别改时间。

在软件工程师构筑的世界里，有一个至高无上的基本假设：时间是单调递增的，且一秒就是一秒。

你可以想想看，POSIX时间戳（Unix Timestamp）的底层定义就是“从1970年1月1日开始流逝的秒数”。整个软件生态——从Linux内核的定时器、线程锁，到数据库的MVCC事务版本号、分布式系统的Lease租约——全部建立在这个假设之上。

但23:59:60的出现，直接把这个基本假设砸碎了。

当国际地球自转服务（IERS）宣布要加一秒的时候，底层操作系统面临着一个极其尴尬的选择：

1. 让时间出现23:59:60：大多数编程语言的标准库和POSIX API根本没有定义过第60秒。你调用时间函数返回这个值，很多解析代码直接报错崩掉。

2. 让时间停顿一秒（把时钟冻结在59秒两次）：表面上看没有非法数字了，但对于高并发系统来说，意味着在这一秒内，两个不同时刻产生的日志记录，拥有完全相同的时间戳；两个请求发起的死锁检测，时间差是0。

3. 把时间往回拨一秒：这是最惨的。时钟倒退，直接击穿了大部分基于逻辑时钟和分布式锁的算法。

2012年那次著名的“闰秒大惨案”，本质上就是Linux内核在处理NTP传过来的闰秒标志位时，触发了一个隐藏在futex（快速用户空间互斥锁）里的死锁Bug。当时Reddit、Mozilla、Qantas航空的系统成片崩溃，服务器CPU瞬间飙到100%。

那次事故给整个工程界留下的心理阴影极其深远。

大家突然发现，天文学家为了让自转和太阳对齐而做出的“文明浪漫”，对于高并发的数字世界来说，无异于一次高空投弹。

真正的瓶颈不在于怎么写那几行代码去兼容23:59:60。

真正的瓶颈在于，在复杂的分布式系统中，你根本无法保证几万台服务器能在绝对相同的微秒级时间内，同时收到并执行“加一秒”的指令。

哪怕只有几毫秒的时间差，集群内某些节点进入了第60秒，另一些节点还在第59秒，分布式数据库的一致性就荡然无存了。

既然物理世界不可预测，而多节点同步又不可能完美，Google的工程师们在2008年前后做出了一个非常符合他们实用主义风格的决定：

我不陪天文学家玩了。我也不在软件里处理什么23:59:60了。从今天起，我的服务器里根本不存在这一秒。

这就是所谓的Time Smear（时间抹平/时间渐变）。

Google的做法说白了有点“自欺欺人”，但极其管用：

当闰秒要来的那一天，Google的内部NTP服务器不会向客户端下发任何“要加一秒”的警告。相反，它从闰秒发生前12小时开始，故意把自己的时钟摆频（Clock Frequency）调慢一点点——每一秒都比真正的物理秒稍微长那么一丁点。

它把那需要增加的1秒钟，均匀地拆碎成几十万份，“抹”进了这24小时（前12小时到后12小时）的每一个瞬间里。

等这24小时过去，那额外的1秒钟已经在不知不觉中被系统消化掉了。时钟平滑地贴合上了新的UTC时间，而运行在上面的任何业务代码、任何数据库、任何内核锁，全程毫无察觉。

从头到尾，没有任何时间跳跃，没有任何23:59:60，也没有任何时间回拨。

如果站在纯粹的标准制定者或者天文学家的角度来看，Google的Time Smear简直是“邪教”。

因为它在抹平的那24小时里，Google服务器所输出的时间，既不是严格的UTC（因为没有处理60秒），也不是严格的TAI（因为它故意走慢了），它是一个由Google自主定义的、只存在于它数据中心内部的“伪时间”。

在标准协议的卫道士看来，这是对国际时间标准的公然篡改。

但现实却无比真实：工业界最终全盘接受了这个代价。

因为对于软件系统来说，“符合标准”远没有“系统不崩”来得重要。

后来AWS跟进了，Meta（当时的Facebook）跟进了，微软也跟进了。大家发现，用微小的频率偏差去换取时钟的绝对单调和连续，是收益最高、风险最小的工程选择。

甚至可以说是Google的这种强硬姿配，直接倒逼了上层计量学界去重新审视闰秒的存在价值。

在经历了四十多年的折腾之后，2022年第27届国际计量大会（CGPM）终于通过了一项历史性决议：决定在2035年之前，正式取消UTC中的闰秒机制。

天文学家们最终向计算机科学家妥协了。在这个高度依赖算法和数据流转的时代，文明最终选择放弃让机械的时间去强行贴合地球的律动。

但其实，今天工程界依然留着一个尴尬的尾巴。

虽然大家都接受了“抹平”的思想，但因为当年没有统一的标准，各大云计算巨头的Smear策略并不一致：

• Google采用的是以闰秒时刻为中心的24小时线性抹平；

• AWS采用的是从前一天中午开始的24小时余弦/线性抹平；

• Meta曾经使用过17.5小时（63000秒）的抹平方案；

这就导致在有闰秒出现的那一天，如果你的系统跨了云平台——比如一部分节点部署在AWS，另一部分部署在GCP——它们在抹平期间拿到的时间戳，最大可能存在几百毫秒的偏差。

在极其敏感的跨云分布式事务里，这个偏差依然有可能引发意料之外的数据不一致。

看似完美的工程妥协，只是把一个显性的崩溃Bug，变成了一个隐蔽的、概率发生的分布式漂移问题。

我们搞了几万年的时间计量，建立了如此庞大的分布式计算网络，但直到今天，我们依然无法完全消除物理世界与数字世界之间的那道时间缝隙。

本内容由作者授权发布，观点仅代表作者本人，不代表虎嗅立场。如对本稿件有异议或投诉，请联系 tougao@huxiu.com。

本文来自虎嗅，原文链接：//www.huxiu.com/article/4881845.html?f=wyxwapp