京準電鐘：GPS北斗衛(wèi)星時間同步裝置作用是什么？

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

審核編輯黃宇