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

Contents

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

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

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

為什麼不直接使用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，例如在重新連線後。

專案網址

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