NTP時間服務器在分布式系統時鐘同步的重要性
點擊次數：2803 更新時間：2016-01-19
因為分布式系統使用分布式算法，所以它的同步機制比集中式系統更為復雜。在集中式系統中能夠做到的，在某一位置上能集收到系統的所有信息，然后由某些進程檢測這些信息，再做出同步決策，而這在分布式系統中常常是不可能做到的。分布式算法一般有以下特點：
1)相關信息分布在多臺機器上。
2)進程只根據本地可用的信息做出決策。
3)應避免系統中單機失效。
4)沒有公共時鐘或其他的全局時間源。
前面三點都是說在處理過程中的單個點上無法收集到系統的所有信息。例如，在做資源分配(以不會出現死鎖的方式分配I／O設備)時，通常不應將所有的UO請求發送給一個管理進程.管理進程檢查所有的I/O請求，根據其設備表中的信息決定滿足請求或拒絕請求。在大系統中，將所有的請求發送給單個管理進程，會使這個進程的負擔過重。而且象這樣的單機失效會使整個系統變得不可靠。理想情況下，分布式系統應該比單機更可靠。如果分布式系統中某臺機器停止工作，剩余的機器應該能夠繼續完成系統功能。不希望看到的是，由于某臺機器的失敗(如資源分配器)導致許多其他機器(如它的客戶)終止工作。為了在沒有集中控制的情況下實現同步，需要采取與傳統操作系統不同的方式。
上面列出的第4點也很重要。在集中式系統中，時間是很明確的。每個進程要知道當前時間，只要執行一個系統調用，操作系統內核就會返回當前系統時間給進程。如果進程A查詢了系統時間，稍后進程B也去查詢系統時間，那么進程B得到的時間將在進程A得到的時間值之后(也可能相等)，肯定不會在此之前。分布式系統中，要達到這種時間的一致性不是件簡單的事。
作為一個簡單例子，考慮一下缺乏全局一致的時間對UNIX中make程序的意義。在UNIX中，大型程序通常分割成多個源文件，這樣在修改某個文件時只要編譯這一個文件，而不是編譯所有的文件。如果程序有一百個文件，則不需因為有一個文件發生了較大的變化而重新編譯所有文件，從而大大加快了程序員工作的速度。
通常，make程序的工作方式很簡單。程序員在修改源文件后，啟動nla~e。Make程序檢查源文件及與它相應的目標文件的后修改時間。如果源文件input．C的后修改時間為2151，而相應目標程minput．o的后修改時間為2150，make程序就可以確定在創建input．o后，修改了源文件input．C，因此要重新編譯源文件input．C。相反，如果output．c的后修改時間為2144，而output,o的后改時間為2145，就不需要重新編譯output，c了。Make程序遍歷所有的源文件，找
出需要重新編譯的文件，調用編譯器編譯這些文件。
現在，想象在沒有全局—致時間的分布式系統中執行make程序。假設ouput．o的后修改時間還是2144，隨即修改了源文件output．c，但是由于編輯output．c的機器的時鐘慢，所以修改后output．c的后時間被為2143，這時，make程序就不會重新編譯output.c結果，生成的可執行文件就包括由舊的源文件生成的目標文件和新的源文件產生的目標文件。這樣，程序的運行就會存在問題，而程序員要在代碼中找到問題的出處，也是大傷腦筋的事。
上面我們看到，時間是人們考慮問題的基礎，時鐘之間的不同步會產生戲劇性的結果。因此，以“分布系統中的所有時鐘可能同步嗎?”這樣一個簡單問題開始研究同步是比較合適的。
