對Directory-Enabled應用程式的影響

版本扭曲

當應用程式在複寫變更之前,從不同的複本讀取相同的物件時,就會發生版本扭曲。 讀取遠端複本的應用程式會辨識未變更的物件。 當指定的應用程式或一組應用程式使用目錄中的資料來交互操作時,版本扭曲是一個問題。

例如,RPC 服務可以使用標準 RPC API (,在目錄中發佈其端點,例如 RpcNsBindingExport) 。 用戶端會透過查閱目錄中所需的端點來連線到服務, ( RpcNsBindingLookupBeginRpcNsBindingLookupNext等等) 並系結至服務。

假設 RPC 服務 S₁發佈端點 Es₁,然後接著移至不同的電腦。 原始端點 Es₁ 會變更為Es2, 以反映新電腦的位址。 讀取目錄服務的遠端複本的用戶端無法連線到服務,直到複寫更新的端點為止。 不過,將服務從一部電腦移至另一部電腦是罕見的;因此,很少會遇到這種中斷/延遲,特別是當服務移動已妥善規劃時。

部分更新

一般而言,當一個應用程式讀取一組資料時,另一個應用程式正在寫入該相同資料集時,就會發生部分更新。 這是多宿主系統中任何應用程式可能發生的情況。 有許多方式可以發生。 您一次可以有多個應用程式寫入相同的資料集。 如果您以這種方式查看,目錄複寫服務只是另一個可能寫入另一個應用程式可能寫入另一個應用程式可能讀取的相同資料集。 這可能是應用程式的潛在問題。 不過,部分更新可能會影響應用程式的時間範圍相當小。 如果應用程式不相依于多個物件的同步處理,這應該很少發生。 如果您的應用程式高度相依于一組相關物件的同步處理,您應該考慮應用程式設計中部分更新的效果。

就目錄複寫而言,當應用程式在複寫進行時,從不同複本讀取相同物件集時,就會發生部分更新。 遠端複本上的應用程式會看到一些變更,但並非所有變更。

注意

部分更新可能會影響應用程式的視窗很小:應用程式必須在輸入複寫進行時開始讀取物件,之後一或多個相關的已變更物件,但在收到所有物件之前。 來源複本上的更新之間的時間會直接影響此視窗的大小--一起發生的更新會一起複寫在一起。 當應用程式使用一組相關的物件時,部分更新可能會是問題。

 

例如,遠端存取服務可以使用目錄來儲存原則和設定檔資料。 原則資料會儲存在一組物件中,而設定檔則儲存在另一個集合中。 當使用者連線到遠端存取服務時,遠端存取服務會讀取原則,以判斷使用者是否允許連線,以及是否要套用至使用者會話的設定檔。 部分更新可能會以數種方式影響遠端存取服務:

  • 如果原則很複雜,且由多個物件所組成,遠端存取服務可能會讀取部分更新的原則,導致拒絕或授與使用者服務、無法因內部不一致而無法處理原則等等。
  • 如果原則和設定檔都已更新,服務可能會正確處理原則,但套用過時的設定檔,因為原則物件已複寫,但設定檔物件尚未複寫。
  • 如果設定檔很複雜且包含多個物件,服務可能會正確處理原則,但因為原則物件已複寫,但只有部分設定檔物件已這麼做。

衝突

在相同複寫間隔期間變更指定物件兩個或多個複本的相同屬性時,就會發生衝突。 複寫程式會協調衝突;因為對帳使用者或應用程式可能會「看到」一個值,而不是他們撰寫的值。

簡單的範例是使用者位址資訊:使用者變更複本 R1 的郵寄地址,而系統管理員會在複本 R2 變更相同的郵寄地址。 寫入的值會傳播到衝突對帳機制選取另一個值超過該值為止。 只要某個值會繼續對衝突解析程式中的其他值「win」,值就會繼續傳播。 最後,如果沒有任何其他變更,這個「成功」值將會傳播至 R1、R2 和所有其他複本。

衝突解決是應用程式的問題,可假設物件或物件集合的內部一致性。 例如,網路頻寬建構管理服務會將指定網路區段的網路頻寬資料儲存在物件 O1 的目錄中。 物件包含每秒位可用的頻寬,以及任何單一使用者可以保留的最大頻寬。 服務預期使用者可保留的頻寬一律小於或等於可用的頻寬。

考量以下事件順序:

  • 初始完整複寫狀態中的 物件會提供每秒 56 KB 的可用頻寬,而使用者每秒可保留的頻寬為 9,600 位。
  • 複本 R₁的系統管理員分別將值變更為 64k 和 19,200。
  • 複本 Rー 的系統管理員會在 R₁ 更新送達之前,分別將值變更為 1000 萬和 1 百萬。

假設有問題的屬性在更新發生時具有相等的版本號碼,但實際上,物件最終會有最大頻寬為 64k,且使用者可保留的最大頻寬為 1 百萬—如果應用程式以個別寫入作業執行更新, 應用程式應該一律在單一作業中更新這兩個屬性。