京东金融闰秒事件复盘

丙申年，庚子月，戊子日。

西元二〇一七年元日，帝都霾，不禁杀。

从立秋到冬至，乃决大辟罪之季。

柴市牌楼前，人头涌动，听说今日要处决一重犯，大家都拿着瓜子端着茶壶出来看热闹。

十字路口上，面向南方跪着一位蓬头垢面的犯人，身披三械，背后斜插着一支亡命牌。身边一名刽子手，袒胸露乳，一身腱 子肉闪着黝黑的光亮，双手端着一把鬼头刀，寒光凌厉。在重犯身后五丈远的地方，放置着一具长案，案上台布一片腥红，桌上还放着一筒火签，旁边有一个香炉，里头插着一根三寸长的檀香。桌后四仰八叉慵懒闲散躺着一位监斩官，不停用嘴吹着檀香，好快点燃完。

太阳像一张没有烙熟的鸡蛋煎饼，无力地透过厚厚的雾层，耷拉在圭表上。石柱的影子虚弱地投在坑坑洼洼的石板上，实在难以辨认现在是几时几刻。

檀香还剩一寸的时候，监斩官已经失去耐心，猛地翻起身来，从签筒里胡乱抽出一支火签令，扔到桌前面的地上：『吉时已到，行刑』。

刽子手双手举刀过头，口中碎碎念叨，全身肌肉绷得紧紧地，拧腰沉肘，一道青霜。

突然犯人仰头长笑几声：『哈哈哈哈』，惊得牌楼上循着血腥味来觅食的几只乌鸦扑棱棱飞起。刽子手也愣了一下，没料到他会在这生死关头突然发笑，手中的刀自然也就没有再落下来。

监斩官眯着眼睛道：『你不知死到临头，为甚做这鬼叫声！』

犯人若有所思道：『看来专家说得没错，每天笑一笑，可以延长寿命五秒钟。』

监斩官道：『弱爆了，专家的话你也信！你难道不知，你今日已经多活了一秒！』

犯人蒙逼道：『此话怎讲？』

监斩官鄙夷道：『闰秒！』

目录

• 历史和闰秒问题的提出

• 闰秒事件的同步实现方式和限制

• 闰秒在Linux系统上的实现方式

• 他家公司对闰秒的处理

• 我们的问题

• 时间融合集群架构和实现

• 架构和硬件

• 软件

• 测试

• 实施

• 监控和测量方法

• 结论和后续工作

• 参考文献

历史和闰秒问题的提出

最初，秒是依据地球绕着轴自转和绕太阳的公转，以平均太阳日的1/86400来定义（太阳时）。到了20世纪中叶，很明显的，地球自转没有提供足够一致的标准，于是在1956年改以绕太阳轨道公转一年的时间重新定义秒。在1967年，秒又被以物理学的属性再一次重新定义：以铯133的振荡频率来定义秒，并可以用原子钟来测量。地球自转变慢的主要因素由于潮汐加速，其他因素主要是地球质量的分布不均匀变化，包括冰河反弹，2004年的印度洋地震使其缩短2.68毫秒等。

图 1展示了国际地球自转和参考系服务（https://www.iers.org）观测到的地球自转数据。

图 1A

图 1B

闰秒是在协调世界时（UTC）中增加或减少一秒，从而使之与平太阳时贴近所做的调整。

闰秒由国际地球自转和参考系服务（https://www.iers.org）发布，图 2是本次闰秒的公告：

图 2

在2016年12月31日，http://www.time.gov展现了这次闰秒（图 3）：

图 3

而2015年6月30日的闰秒事件，影响了纽约股票交易所，多种互联网路由器，Twitter，Instagram，Netflix，Amazon，Altea航空订票系统等。

闰秒事件的同步实现方式和限制

闰秒在Linux系统上的实现方式

目前在Linux上多使用NTP协议同步时间，在NTP的数据包中包含闰秒标志位。在NTP时间同步部署正确的情况下，闰秒标志位被传递至最终的客户端，并设置在内核中，闰秒发生时，在系统中将出现23:59:60这样的时间，并且由内核控制时间将进行跳跃1秒，此时时间将不连续（图 4）。在CentOS中由于历史原因和系统的复杂性，闰秒问题变得更为复杂[1]，并且在特定的系统版本中会引起系统hang住[2]、高系统负载等内核BUG[3]等现象。

图 4

NTPD提供了Slew模式（-x参数），但是在存在闰秒标志位的情况下，仅对足够新的NTPD版本才有效果[4]。在Slew模式正常工作的情况下，系统时间的变化仍然不均匀，并可能引起多节点的不一致（图 5）。

图 5

业界公司对闰秒的处理

为了使这1秒的同步连续且均匀，Google和Amazon对闰秒问题提供了不同的解决方案[5][6]。

Google的解决方法是修改内部的Stratum 2时间服务器软件以进行“闰秒融合”，在闰秒事件发生后均匀的增加（或减少）时间：

其中w为这次融合需要经历的时间。

Amazon的解决方法是均匀的时间调整。在闰秒事件发生前12小时，以每秒1/86400秒的步调，最终比UTC时间快0.5秒；闰秒后比UTC时间慢0.5秒，在闰秒后12个小时再以每秒1/86400秒的步调追改UTC时间。 这两种方法都可以使时间连续变化，并且使客户端不会因时间同步服务的突然变化而丢失同步，或者选择其他的时间源，而使集群时间不一致。

我们的问题

在2015年的闰秒事件中，我们经历了由闰秒带来的各种系统和软件问题。 在我们的生产环境中，管理着超过30K个节点，位于不同地理位置的IDC，他们使用内部的Stratum 2时间源同步。这些节点配置有NTPD作为时间同步客户端。使用的操纵系统版本包括CentOS 6.2-6.5版本。大部分NTPD客户端版本为ntp-4.2.6p5-1.el6， minpoll和maxpoll参数使用默认的配置，即时间稳定后1024秒同步一次，时间变化频率不超过500PPM。 由于操作系统环境的多样性，闰秒标志位若下发则不可避免的触发操作系统和软件的BUG；节点数量巨大，因此对大批量节点的操作会有不可测的风险；同时考虑到运行服务的性质，因为是在跨年时间调整，提前调整时间可能会对业务逻辑产生影响。我们决定不下发闰秒标志位，在闰秒事件发售后，使用时间发生后缓慢调整的方式进行。

时间融合集群架构和实现

架构和硬件

我们的时间Stratum 2时间同步服务器分布在3个IDC，有8台独立的物理机，他们使用互联网上的4个相互独立的Stratum 1时间源和内部的两台铷原子钟守时时间服务器作为时间同步标准。 位于多个IDC的环境，外部独立的时间源，内部低延迟的时间源，使Stratum 2时间服务器可以稳定运行。

软件

目前在CentOS系列操作系统上可以选择的时间同步软件有NTPD、CHRONYD、PTP4L、PHC2SYS。PTP4L、PHC2SYS需要特定的硬件结构进行同步，而NTPD在slew模式下无法均匀同步时间。Chronyd作为CentOS 7中替换NTPD的方案，在CentOS 7.2和6.8中的chrony 2.1版本提供了时间平滑变化的方法[7]。 Chronyd的时间平滑算法分为3个阶段。第一阶段频率（frequency）以固定比率（wander）变化至最大值（max_freq）；第二阶段频率维持在最大变化频率（max_freq）足够的时间；第三阶段频率由再以固定比率（wander）变化至0。假设这个变化从时刻0开始，时刻a完成第一阶段变化，时刻b完成第二阶段变化，时刻b+a完成第三阶段变化：

以此方式变化，则时间偏移为：

由于我们的客户端使用NTP同步，他的最大允许频率变化为500PPM（PPM＝Part Per Million，10－6秒），而500PPM的变化反映在1天的区间，将会达到43秒。因此在时间调整过程中，我们不会达到像500PPM这样的数量级[8]。因此，以上公式变为：

测试

测试集群包括1个节点作为时间调整源（Stratum 1，时间手动调整），3台时间融合节点（Stratum 2，chronyd），连接至时间融合节点的Stratum 3节点（ntpd）和连接到以上节点的Stratum 4节点（ntpd）。

以下验证了参数wander对时间同步效果的影响。

Wander=0.001ppm（图 6,图 7):

图 6

图 7

wander=0.002ppm（图 8、图 9）：

图 8

图 9

wander=0.004ppm（图 10、图 11）

图 10

图 11

总结测试数据如下

因为闰秒事件于北京时间早晨8点开始，并且需要当天0点之前完成同步，因此我们选择使用参数wander=0.002ppm进行时间融合。而max_freq=400ppm

实施

时间融合节点的选用

时间融合节为改造过的Stratum 2节点，使用x86服务器。X86服务器电子振荡器（石英晶振）作为守时元件，他们受外界环境因素影响，主要是温度[8]。而我们的Stratum 2时间服务器的守时质量也并不一致。图 12展示了一周的时间周期内Stratum 2时间服务器Frequency error的变化。

图 12 我们选择其中4个变化幅度较小的节点作为时间融合节点，如此NTP客户端可以选择其中3个节点进行时间同步计算，并且有1个节点作为冗余[9]。

实施过程和时间点

时间融合期间的观测数据

时间融合期间，我们在位于3个IDC与时间融合集群同步的服务器上观测了铷原子钟、时间融合集群、客户端相对与铷原子钟的偏移（图 13、图 14）。观测点同步与铷原子钟。还有时间融合集群3个节点见的差距（图 15）。

图 13

图 14

图 15

性能分析

在12.41小时的时间融合之后，仍需1.39小时使集群与原子钟重新同步，而连接时间融合集群的客户端需要更长的时间进行同步，时间融合集群各节点间差距小于2ms，生产服务器依照时间融合集群步调融合时间，生产服务器集群和时间融合集群、以及生产服务器之间的时间差距不超过100ms。

监控和测量方法

监控使用Collectd收集数据，Graphite作为数据存储，Grafana作为数据展示，数据收集的精度为每10秒一次。监测机同步至内部的铷原子钟以获得稳定的参考基线。

结论和后续工作

CentOS 6.8和7.2版本中加入的Chrony版本2.1提供了一种对时间变化控制的方法，而不需再定制Stratum 2节点软件。

通过建立时间融合集群，同步复杂部署环境下超过30k个节点的时间变化，将其步调一致的变慢1秒。避免了时间变化的不连续和由于闰秒机制带来的潜在BUG。

在实施过程中也发现了若干问题，在时间融合期间，时间融合服务器的时间变化性能受服务器个体、外界环境温度等因素影响；时间同步受传输过程中经过的长路径设施、防火墙等网络设备时，传输延迟摆动带来的时间不均匀变化也不容忽视。

后续考虑在Stratum 2和时间融合节点引入更精确的时间参考标准，比如PTP、PPS信号等方式，使时间变化过程控制更加均匀，时间融合节点间的误差更低；在传输设备上部署PTP，以抵长距离和跨IDC网络传输对时间同步带来的影响。

参考文献

• [1] Resolve Leap Second Issues in Red Hat Enterprise Linux.https://access.redhat.com/articles/15145

• [2] Systems hang due to leap-second livelock.https://access.redhat.com/solutions/154713

• [3] High CPU usage after inserting leap second.https://access.redhat.com/solutions/154793

• [4] Does Red Hat plan to release a ntp package including xleap.patch.https://access.redhat.com/solutions/1379783

• [5] Time, technology and leaping seconds.https://googleblog.blogspot.jp/2011/09/time-technology-and-leaping-seconds.html

• [6] Look Before You Leap – The Coming Leap Second and AWS.https://aws.amazon.com/cn/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/

• [7] Chrony News. https://chrony.tuxfamily.org/news.html

• [8] Clock Quality. http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm

• [9] Selecting Offsite NTP Servers.http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers