2009-11-17 63 views
0

我剛剛開始將.NET應用程序及其SQL Server數據庫分爲兩個系統 - Intranet和一個公共網站。同步Intranet和Web數據

各種數據庫表將需要以不同的方式在兩個數據庫之間進行同步,例如:

  • 移動從網絡到內部網與內網數據變得只讀
  • 從內網移動到網絡,與網絡數據變得只讀
  • 需要被同步,並讀取在Intranet和網絡數據庫都/寫表。

某些同步需要以最小的延遲相對快速地發生,可能通過某種類型的事務鎖定來確保可重複讀取等。其他時間無論同步之間是否存在延遲都無關緊要。

我不太肯定這一切開始,因爲似乎是實現這一目標的許多不同的方式。我應該關注哪些技術和策略?

任何提示?

+0

是否有任何特別的原因,你不只是指向內部網和互聯網網站在同一個數據庫?這會爲你節省很多頭痛。 – David

+0

爲什麼社區wiki? –

+0

主要原因是從我們在網絡服務器上存儲大量敏感數據並不是一個好主意,因爲它比互聯網更廣泛地暴露於互聯網。 – cbp

回答

2

像這樣的系統看起來像組件相當緊密耦合。一次跨多個系統的升級可能變成相當惡夢。

看起來這不太複製問題,更如何保持持續連接到遠程數據庫的問題沒有太多的I/O延遲。儘管可以完成,但在可擴展性方面並不能很好地解決問題。

你可能看使用一些消息隊列和異步數據處理從遠程站點到Intranet。您可能需要調整業務方面的一些預期,以免他們認爲所有事情都可以實時訪問。

當然,它很難給出具體細節沒有更多的細節。研究SOA和消息傳遞系統的原理可能是一個好主意。

2

開箱即用的是SQL Server複製。聽起來像是一對filteredtransactional複製出版物可以完成這項工作。事務性複製對發佈程序的開銷較低,並且可以確保發佈的更改的事務一致性。

彌敦道提出了關於需要一個更加鬆散耦合解決一些非常有效點。 Service Broker可以很好地適應那個鞋子與鬆散耦合的異步性質,並且由於SSB是compatible between SQL Server versions and editions,所以提供了一個頭疼的免費升級未來。但是這種自由的代價是讓實際檢測變化並將它們應用於表格,作爲應用程序代碼,而不是小事。