對 Directory-Enabled 應用程式的影響

版本扭曲

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

例如,RPC 服務可以使用標準 RPC (Api (例如 RpcNsBindingExport) )在目錄中發佈其端點。 用戶端會藉由查詢目錄中所需的端點 ( RpcNsBindingLookupBeginRpcNsBindingLookupNext等方式來連線至服務,並) 並系結至該端點。

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

部分更新

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

就目錄複寫而言,當應用程式在進行複寫時,從不同的複本讀取一組相同的物件時,就會發生部分更新。 遠端複本上的應用程式會看到部分(但不是全部)的變更。

注意

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

 

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

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

衝突

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

簡單的範例是使用者位址資訊:使用者變更了複本 R1 的郵寄地址,而系統管理員在複本 R2 上變更相同的郵寄地址。 寫入的值會傳播到另一個值是由衝突對帳機制選取該值之前。 只要值持續針對碰撞解析程式中的其他值「獲勝」,此值就會持續傳播。 最後,如果未進行其他變更,則會將此「獲勝」值傳播至 R1、R2 和所有其他複本。

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

考量以下事件順序:

  • 處於初始完整複寫狀態的物件會提供每秒 56 kb 的可用頻寬,而使用者可保留頻寬為每秒9600位。
  • 複本 R ₁的系統管理員會分別將值變更為64k 和19200。
  • 複本 R ₂的系統管理員會在 R ₁抵達的更新之前,分別將值變更為10000000和1000000。

如果有問題的屬性在發生更新時具有相同的版本號碼,則物件的最大頻寬可能是最大的,但如果應用程式以個別的寫入作業來執行更新,則物件的最大頻寬可能會有最大的最大頻寬和1百萬的使用者可保留。 應用程式一律會在單一作業中更新這兩個屬性。