Linux 下的伺服器時間同步方案有哪些？

01-03

是使用ntpdate+計劃任務呢，還是去配置NTP伺服器呢，各有什麼優勢和缺點，什麼樣的情況採取哪種方案？

基本上在任何時候都不應該使用 ntpdate。

大多數應用場景中，使用ntpd的-g參數令其在啟動時允許大步長同步就足夠了（除此之外還可以在配置中使用 iburst 來讓加速同步）。使用 ntpd 唯一需要注意的是在配置時應配置 ACL，以免成為攻擊跳板。

有些人會爭辯，在啟動 ntpd 之前運行一次ntpdate 的好處是 ntpdate 退出時，系統的時間已經調到了比較接近正確的時間。不過， ntp 作者已經在文檔中明確表示未來 ntpdate 會變成一個shell腳本（通過 ntpd -g -q 來實現），事實上，現在也可以在啟動時用 ntpq -c rv 來檢查 ntpd 的狀態了，對於精度要求比較高的應用，系統時間和時鐘快慢同等重要，如果不高，也沒有太大必要去另外運行 ntpdate 了。

定時運行 ntpdate 的系統很容易受到這樣的攻擊：如果有人故意調整了某個 ntp 伺服器的時間，所有使用 ntpdate 的系統都將跟隨其設置。舉例來說，假如已知某家公司的系統每天凌晨3點會執行某項非常耗時的任務，同時每4個小時會做一次ntpdate，那麼攻陷這台伺服器並令其一直返回凌晨 2:59，就可以很容易地實現四兩撥千斤的槓桿式攻擊了，而且，由於系統時間也會影響日誌，因此觀察日誌的人員也比較容易受其誤導。

與此相反，ntpd 通常會配置為使用多個參考伺服器，在運行時會參考多個伺服器的時間，並排除明顯異常的伺服器。而監控多個 ntp 伺服器相對來說要容易得多。

用 cron 或類似的任務計划去做 ntpdate 還有個問題是如果系統時間比較準的話，每到某個整點（或者特定的時間）的同步操作就變成了一次對 NTP 伺服器的 DDoS。機器多的話，這种放大效應對於集群本身和提供 NTP 服務的機器都是不利的。

ntupdate是更新本機時間的方案，臨時用用很方便。多個伺服器實際同步還是用NTPD吧。

單獨構建的ntpserver是一個本地集中式的時間同步解決方案，這樣的好處在於，快（本地）

壞處在於，有管理代價，如果你維護的不當，很可能造成全部over,給服務造成難以挽回的損失。

用別人的server的話，如果網路出問題很可能造成是同步時間不成功。同時同步完成時間也會受到網路的影響慢一些。但因為對方是專人維護，所以故障幾率小一些。

ntpdate是瞬間調整時間的，會導致伺服器的時間出現「斷層」或者「重複」。

比如伺服器運行這一個日誌系統，

00:00:00.10 客戶端A登陸了系統

00:00:00.11 系統用ntpdate對時，發現快了50ms，把系統時鐘回調50ms，變為00:00:00.06

00:00:00.07 客戶端A進行了事務操作

以上日誌就出問題了，因為按照日誌，.07秒時，客戶端A並未登陸，而客戶端卻進行了操作。

而ntpd則是作為服務，在後台潛移默化地調整時間，一天大概能調20ms，這時，伺服器的時間是連續的，只是伺服器的1s可能是事實上的0.99999999秒或者是1.00000001秒。在日誌系統上，不會出現新發生的事件有更老的時間戳之類的錯誤出現。

由於網路的抖動，以上問題在沒有被攻擊的情況下也會頻繁出現，所以ntpd建議大家用ntpd服務對時，而不是corn+ntpdate的方式對時。

nptd服務還會監控系統時鐘的漂移程度，能令系統1s更接近1s的定義長度，而ntpdate則只能調整時鐘，系統時鐘的漂移並不會被修正

盡量通過服務來協調，這是一套成熟的機制；如果寫腳本定期矯正，風險是矯正時候有些軟體可能無法正常工作，比如一些寫的不是很好的網路庫，依賴時間做過期的緩存服務等，而且你如何保證你的腳本能持續正確工作也是個挑戰。

PTP同步是NTP的加強方案,可實現時鐘誤差1us

硬體同步，用gps授時

嗯？這台時間差了有點多。打開百度搜索時間，然後date -s 17:07:11再clock -w。

你說為啥不用NTPD?因為根本用不了。

自建加密時間同步伺服器

先用ntpdate做一次同步。然後使用ntpd做日常同步。

如果要求精度高，可以使用PTP，參見： Precision Time Protocol

精度要求不高的話，ntpdate +crontab就可以了，缺點是可能會有時鐘漂移、回滾的情況。

ntp適合精度要求較高的情況，優點是時間不會漂移、回滾，缺點是要起系統服務，誤差太大的時候調教用時較多，有時候甚至調校不來。