題幹與適用場景
面試題：多台伺服器需要記錄可比較的事件時間，同時部分服務還要量測逾時與延遲。請說明 NTP、PTP 與程序內單調時鐘各自解決的問題，給出部署選擇、失步處理與驗證方法。假設網路存在可變延遲、節點可能重啟，且業務不能把時間同步誤當成因果一致性。
面試官考察點
面試官看重能否分開三個概念：可跨節點比較的牆上時間、節點本地經過時間、事件因果順序。強回答先問精度與網路邊界，再說明 NTP 適合廣域網通用同步，PTP 適合受控區域網路與硬體時間戳，單調時鐘只用於同一節點的持續時間計算；不會籠統宣稱 PTP 永遠更準。
回答前需要釐清的問題
- 可接受的最大偏差是多少？毫秒級稽核通常可用 NTP，微秒級控制才值得評估 PTP 與硬體時間戳。
- 網路是否受控、交換器是否支援 IEEE 1588、鏈路是否有 boundary 或 transparent clock？不支援時 PTP 的理論精度無法落地。
- 時間用於排序、逾時、簽章還是合規留痕？逾時使用單調時鐘；跨節點排序仍需邏輯時鐘、序號或業務版本。
- 失去上游時間源時要停止寫入、降級還是繼續服務？答案決定 holdover、告警閾值與資料標記。
推薦方案與推導
先建立分層時間架構：少量受 GPS、原子鐘或可信上游約束的時間源，向區域 NTP 伺服器提供服務；一般主機透過 NTP 校準牆上時間。NTP 的報文交換要面對往返延遲與路徑不對稱，因此應記錄 offset、頻率誤差、round-trip delay、stratum 與最後同步時間，而不是只看服務是否啟動。
PTP 將 grandmaster 時間沿交換器傳播，並可用硬體時間戳減少作業系統排程與網卡排隊誤差。在同一受控區域網路、交換器支援 boundary/transparent clock、端點有硬體時間戳時，可滿足比 NTP 更緊的誤差預算；跨網際網路或變動的雲端網路則先驗證設備與網路是否真的滿足假設。
wall_now = CLOCK_REALTIME # 日曆、日誌、跨節點時間戳
elapsed = CLOCK_MONOTONIC # 逾時、重試、延遲量測
deadline = monotonic_start + timeout單調時鐘不會因 NTP 校時而倒退，適合計算經過時間；Linux 文件也區分 CLOCK_REALTIME 與 CLOCK_MONOTONIC 的語意。即使牆上時間同步良好，也不能用它計算 30 秒逾時，因校時可能產生跳變或頻率調整。
替代方案與取捨
只用 NTP 的優點是部署簡單、跨網路可用、營運工具成熟；缺點是誤差受路徑與主機時間戳影響。PTP 的優點是受控網路中較低的偏差與抖動；缺點是依賴網卡、交換器、驅動與時鐘源，設定和故障域更複雜。事件排序可用邏輯時鐘或資料庫序列；單機耗時則單調時鐘比兩種網路協定都合適。
失敗場景、邊界與反例
- 把 NTP 的「同步成功」當作業務時間準確，忽略 offset、stratum 與來源切換。
- 用
CLOCK_REALTIME做逾時；人工改時或校時跳變會讓計時過早或過晚。 - 在不支援硬體時間戳的雲端主機上宣稱 PTP 達到微秒精度；網路能力必須是前置條件。
- 用物理時間判斷跨節點因果關係。兩事件可能因網路延遲出現相同或逆序時間戳，應使用序號、版本或邏輯時鐘。
- 失步後仍產生看似精確的簽章和稽核記錄；記錄 time-source、sync-age 與 uncertainty，超過閾值時標記或拒絕高風險操作。
測試與驗證清單
驗證分三層：先在節點上檢查即時鐘與單調鐘的語意，再收集 NTP/PTP offset、jitter、頻率誤差與同步年齡，最後注入網路延遲、丟包、上游切換與重啟。驗收指標應寫成「在指定網路與硬體條件下，99.9% 時間窗口偏差小於 X」，並分別測試 holdover 與恢復時間；不能只做一次 date 比對。
追問與延伸
如何處理跨節點事件排序？
把物理時間當作顯示與稽核欄位，把因果關係交給單調遞增版本、訊息序號、資料庫提交序列或邏輯時鐘。若必須展示時間順序，明確允許的時鐘不確定區間，並在相同區間內使用穩定 tie-breaker。
PTP 是否可以完全取代 NTP？
不能直接下結論。PTP 適合有明確精度預算且網路可控的網域；NTP 仍涵蓋管理網路、廣域鏈路與沒有 PTP 硬體的節點。常見架構是 PTP 約束關鍵網域，再由網域內服務向其他主機提供 NTP。
失去時間源時是否應該停機？
按業務風險分級：普通快取或指標可在有界 holdover 內繼續；簽章、憑證、金融撮合等功能應在 uncertainty 超過閾值時拒絕或轉人工。所有降級都要產生告警、資料標籤與恢復後校準記錄。