大家好，又见面了，我是你们的朋友全栈君。
1. 问题背景描述
2021年7月23日宜春现场出现一台信号机在应该跑早高峰方案的时候，实际上跑了凌晨的方案，从而造成现场车辆拥堵的问题，客户进行了投诉并要求给出解释和解决方案。
2. 问题排查和分析
排查过程中发现宜春现场的校时配置十分混乱。现场存在NTP，GPS，平台校时三种模式同时进行校时的情况。并且现场并不止有一个平台，也就是通过平台校时这个方式的校时源有多种。
所以可以得知的是，现场的信号机在较多情况下同时会接受3-5种不同的校时源进行校时。
3. 同时有多种不同校时源下存在的风险
信号机是一个时间敏感的设备，在时间变化的时候，需要进行重新计算当前时刻应该进行的方案。这里举个例子方便理解：
例如当前信号机时间是10点，但实际上真实时间已经到了下午2点。很有可能10点是早高峰方案，而下午2点已经是平峰方案。所以在时间切换的时候，需要重新查找调度表和时段表来确定新时刻应该走什么方案。
同时，信号机为了避免高频校时带来的重复无意义写硬时钟，对于差别1秒以内（含1秒）的校时是不会产生实际修改效果的。这么做同样是为了避免微小时间差带来的方案反复跳变，同时保护了信号机的硬时钟不会有过于频繁的写入。但这个容差不能设置的过大，否则绿波功能就会有较大差异，甚至失效。这里不做展开。
在以上前提背景下，多校时源下存在的风险大概会有如下几个：
A. 方案突变：
校时源A：10点，校时源B：16点，同时给信号机校时，信号机系统时间会反复来回跳6个小时。基于信号机的方案切换是必须走完一个周期后再实际切，所以可能并不是一下跑10点的方案一下跑16点的方案，因为存在10点校时成16点后，升成了下一个要走的新方案（16点方案），但是在真的要走下个方案之前，16点又校时回来了。那么表象看，好像一切都很正常，实际上带来了不稳定的风险。
B. 突发的黄闪：
校时源A：10点，校时源B：凌晨2点，同时信号机中凌晨2点是黄闪方案（大多数城市凌晨都是黄闪方案）。这个时候出现反复跳变就比较容易了，因为普通方案切黄闪是立即的，黄闪切普通也是立即。那么在反复校时切换的时候，信号机就会在黄闪和普通方案之间跳变。这种情况用户肉眼可见，而且更为危险。
更多的风险暂时不暂开，过于频繁的反复校时导致硬时钟频繁更改，更有可能触发老内核下的bug，导致系统无法启动。这些风险更为不常见，但是同样是存在的。
4. 当前现场存在的一台特殊路口，NTP校时跑久了会出现可以被NTP校时，但是越跑时间越偏差
4.1 NTP校时跑偏
这台信号机存在这样的一个问题，NTP服务器配置校时的时候，是可以被服务器校时的。表现在真实时间是13点，信号机时间改为0点后，在校时频率范围内，信号机时间会重新被设置成13点，这是正常现象。
异常在于接着上面的场景，过了一阵子真实时间到了2点的时候，信号机会被校时为1点55，而且设置成0点后依旧会被校时为1点55。这个偏差会随着真实时间的增大，越偏越远。
4.2 问题信号机中网络状况
登陆到问题信号机中，会发现netstat这个指令中看到了，在udp的端口存在接收队列持续有较多值一直未处理的情况，并且这个值会缓慢增长。udp的37250这个端口通过抓包后发现，正是和NTP服务器upd 123通信使用的端口。
奇怪在于为何NTP服务器中来的数据会有这么多未处理的。正常情况下，NTP的机制是被校时客户端请求一次（这个场景里，被校时客户端即信号机），NTP服务器收到校时请求后会回复一次。
那么在信号机中进行抓包看看情况如何，以下内容为信号机端在校时出现问题时候，抓取的与NTP服务器之间的交互包。
可以大概看到问题了，信号机端（ip:192.1.1.22）每60秒往NTP服务器（ip:192.0.1.69）发送一个请求包，而服务器有时候会回复2次数据，而且是很短的时间连连续回复2个包。
4.3 继续深入重复包的逐字节分析
那么同时在问题信号机和NTP服务器进行抓包，看看会如何：
对于上图中121秒的连续两个NTP回复包，在NTP端和信号机端同时抓包的分析截图：
a. 问题信号机的包：
b. NTP端的包：
可以发现无论是信号机，还是NTP服务器，都是真实的抓取到了这种二次回复的行为，而且回复的UDP内容完全一致，区别仅在IP部首的Identification这个字段不同，而这个字段也说明了这相同的内容的确是发了2个包。
而对比两个包，可以看到，同样的包，在信号机端只发送了一次，但是收到了两个回复。在NTP服务器端能看到发送了两个包，所以才回复了两次。那么问题肯定出现在中间路由转发的过程中造成了某个包重复转发的问题。
信号机端的包
NTP端的包
信号机端只有3个包，但是NTP端有4个。
并且这种路由器多转发的现象，还不仅在于这一台信号机，抓包过程中，NTP服务器在短时间内收到多次请求的并不只有一个信号器，甚至有些校时请求在短期内收到了3次。
4.4 延迟校时的根因分析
到这里为何延迟的问题就十分明确了，在6分钟内我们观察到了2次NTP服务器答复双包的行为。而正常协议应该是发一个，回一个。那么我们把这个问题换成另一个好理解的模型，来理解一下这个延迟校时的问题。
假设每小时校时一次，例如当前是5点钟，信号机请求，服务器回复5点。信号机接受。6点的时候，信号机再次请求，服务器恢复了2个包，都是6点，然后信号机用掉了第一个包。第二个包因为没有请求，所以一直在系统缓存中。在7点的时候，信号机发送请求，服务器回复了7点。但是信号机拿到的是6点回复的第二个包。
这个场景很明显了，长此以往，双包回复频率越高，那么信号机的延迟时间就越严重。
5. 本问题的处理方式以及后续需要注意的要点
虽然信号机端可以进行处理，每次将多收到的包进行丢弃。但这种情况并不具有普适性，而且属于掩盖问题的解决方式。路由重复转发包的行为对于NTP这一点还好说，万一我们的控制协议，或者别的更重要的包进行重复转发，那么造成的逻辑影响甚至会更大。
所以这里有以下建议：
- 查明路由多次转发包的原因，排查网络拓扑问题。
- 对于之前存在错误的多校时源同时对某一个信号机进行校时的问题，进行及时修复，务必保证在同一时刻只有一个校时源在进行校时。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/150288.html原文链接：https://javaforall.net
![Vue上传文件遇到的问题[通俗易懂]](https://javaforall.net/wp-content/uploads/2020/11/2020110817443450-480x300.jpg)
