2011-12-19 122 views
5

我目前正在使用WebSocket作爲向客戶端傳輸數據的一種方法。基礎設施看起來像這樣。
客戶端 - > Web服務器 - > Microsoft SQL數據庫Microsoft SQL數據庫的WebSocket偵聽器

我認爲最理想的情況是這樣的: 客戶端打開一個套接字服務器。 服務器打開Microsoft SQL數據庫的套接字。 每當數據庫更新(某些數據已插入)時,數據庫將數據寫入套接字。 服務器將數據寫回客戶端。 雖然這可能有點乏味,也許我可以以某種方式直接從客戶端打開數據庫的套接字?

我想知道是否有辦法自動通知套接字到Web服務器如果MSSQL數據庫更新,以便它可以處理該信息。

主要問題是真的;我將如何做這項工作?我研究過一些與WebSocket一起工作的項目,如Node.JS和Socket.IO,也是Tornado。儘管我還沒有找到任何有關在哪裏尋找這個特定功能的線索。我發現了一些針對NodeJS的MSSQL數據庫的相當不穩定的驅動程序,但不明白是否有任何方法可以向數據庫創建套接字,並在將數據泵入數據庫時​​立即通過套接字發送數據。我也認識到,在客戶端和數據庫之間建立一個套接字並不聰明,至少說安全性是明智的,因爲現在這不是問題,並且SQL不是實時應用程序的方式,米綁定到它現在:)

編輯1:

感謝@tomfanning我現在知道了解決這個問題的,但是嚴重懷疑在性能上的提升。讓我爲你描繪情況。在我使用MSSQL數據庫上的觸發器的情況下,我想象會發生這種情況。

情況1

  1. 數據庫中獲取更新
  2. 扣動扳機
  3. 的CLR腳本使得對Web服務器的連接。無論是通過 由它來打開套接字和關閉每一個觸發器或通過 涉及打開和關閉頭(其 是無用的開銷)
  4. Web服務器接收到觸發和HTTP(S)請求將數據發送到客戶端 。
  5. 客戶端更新。

現在想象同樣的場景,但然後用AJAX

情況2:

  1. 1000毫秒的超時是在客戶端AJAX設置請求
  2. 客戶端超時併發出AJAX請求
  3. 數據庫執行一些查詢並回傳結果
  4. 客戶端更新。

在情況1你需要一個請求和一個套接字發送/接收,在情況2你只需要一個請求。如果我將AJAX請求的超時設置爲10MS,那麼它對用戶來說就好像它是一個像websocket一樣的實時應用程序?或者情況1仍然更有效率,我只是誇大了?

在此先感謝!

+0

如果你可以通過websockets以不安全的方式訪問你的數據庫,我也可以。如果我可以訪問你的數據庫,我會把它扔給盧爾茲。安全不是一個笑話。 – Raynos

+0

@Raynos我知道安全不是一個玩笑,我一定會考慮它。但我現在只需知道是否有辦法做到這一點。 –

回答

3

可能的解決方案可能是T-SQL triggers on INSERT or UPDATECLR procedure,它向您的主應用程序發送一些通知,然後通過websockets將數據輸出到您的客戶端。將避免需要輪詢數據庫。

每您的評論 - 不知道AJAX將如何幫助您特別是在這種情況下 - 因爲從客戶端(瀏覽器)驅動的技術,你的解決方案將再次投票,你想避免這我明白。 WebSockets在這裏聽起來很合適,因爲它使您能夠在不需要輪詢的情況下從服務器到客戶端進行真正的「推送」。

顯然我在這裏用非常一般的和理論的術語來談論。

+0

我的確打算避免輪詢,並且希望在我的應用程序中使用WebSockets。但想象一下觸發器正在被拉動並且腳本正在執行,數據庫將不得不通過套接字建立到Web服務器的連接,否則它將以鏈接或類似的方式打開請求。這意味着它將不得不建立一個標題,我想避免由於開銷。如果我要從客戶端向服務器發送AJAX請求,它將需要一個請求而不是一個請求+套接字傳輸的權利? –

+0

在任何可以想到讓客戶端代碼直接與數據庫服務器對話的情況下,沒有任何方法是明智的。所以你總是會有某種形式的中間件,因此不管技術如何,總共有兩個連接(一個在客戶端和Web服務器之間,一個在Web服務器和數據庫服務器之間),而不是一個。如果您從*客戶端開始更新*,您總是會採用輪詢模式,這將比推送模式的可擴展性差。如果你想要一個真正的推式模型,你需要從數據庫端啓動操作。 – tomfanning

+0

我剛纔也想到,數據庫中的INSERT或UPDATE觸發器只會打開一個到web應用程序的連接,這可能會反過來知道需要接收推送的很多(幾十,幾千個)客戶端通過WebSockets通知。這比成千上萬的客戶端週期性地發送AJAX請求來輪詢更新要好得多,這反過來又會給數據庫帶來很大的壓力。 – tomfanning