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,例如在重新連線後。
專案網址
✍ 不受社群推薦演算法影響,建議 Telegram/Discord/e-mail