fbpx

realtime:使用 Websocket 來獲得 PostgreSQL 的資料庫變化通知

Contents

Realtime 是一個用 Elixir 建構的伺服器,使用 Phoenix 框架,允許你透過邏輯複製( logical replication )監聽 PostgreSQL 資料庫的變化,然後透過 WebSockets 廣播這些變化。

使用了 Realtime + postgreSQL 等於有了 Firebase 即時資料庫功能

Realtime 伺服器透過以下方式工作

  • 監聽PostgreSQL的複製功能(使用PostgreSQL的邏輯解碼功能
  • 將位元組串流轉換為 JSON
  • 透過 WebSockets 廣播

為什麼不直接使用PostgreSQL的 NOTIFY?

有幾個原因:

  • 你不需要在每個表格上設定觸發器
  • NOTIFY 的有效載荷( payload )限制為8000位元組,如果超過這個限制就會失敗。通常的解決方案是傳送一個ID,然後獲取記錄,但這對資料庫的影響很大
  • Realtime 伺服器消耗兩個連線到資料庫,然後你可以將許多客戶連線到這個伺服器。對你的資料庫來說更容易,而且要擴大規模,你只需增加額外的 Realtime 伺服器

有什麼好處?

  • 監聽複製( replication )功能的好處是,你可以從任何地方對你的資料庫進行修改–你的API,直接在資料庫中,透過控制台等。- 而你仍然可以透過 WebSockets 接收這些變化
  • 解耦合:例如,如果你想在每次有人進行新的購買時傳送一條新的 slack 訊息,你可以直接在你的 API 中建立這個功能。Realtime 允許你將你的非同步功能與你的 API 解耦合。
  • 這是用 Phoenix 建構的,Phoenix 是一個極其可擴充的 Elixir 框架。

這個伺服器能保證每一個數據變化的傳遞嗎?

還沒有! 由於以下的限制。

  • Postgres 資料庫由於 WAL(Write-Ahead Logging)的堆積而耗盡了磁碟空間,這可能會使資料庫崩潰,使 Realtime 伺服器無法進行串流式複製和廣播變化
  • Realtime 伺服器可能由於複製滯後( replication lag )大於可用記憶體而崩潰,迫使建立一個新的複製槽(replication slot ),並重新設定串流式複製以讀取最新的 WAL 資料。
  • 當 Realtime 伺服器由於任何原因落後太多,例如在 WAL 繼續積累時斷開與資料庫的連線,那麼資料庫可以刪除 realtime 伺服器仍然需要讀取的 WAL segments,例如在重新連線後。

專案網址


追蹤 Soft & Share

✍ 不受社群推薦演算法影響,建議 Telegram/Discord/e-mail

幫我們個小忙!

請為我們的網站評分(必)

Comments are closed.

Powered by WordPress.com.

Up ↑

%d 位部落客按了讚: