Postgres是否合適替代Redis或Kafka實現釋出訂閱作業? - HN
駭客新聞網友針對原文的討論,原文披露:
使用 postgres 作為其釋出/訂閱實現,每天處理數十萬條訊息。postgres 例項現在在 32 個核心和 128GB 記憶體上執行,並且擴充套件性很好。
Postgres是否合適做些Redis或Kafka的釋出訂閱作業?下面是網友討論摘錄:
僅僅因為某物可以用來做某事並不意味著它應該做某事。Kafka 是專門為此目的而設計的,它是免費的,並且易於學習和使用。如果“從 Postgres 開始,然後在時機成熟時切換”可以節省資金,那麼我可以理解。否則,從一開始就為正確的工作使用正確的工具。
這似乎每年至少在 HN 上出現一次。當然它可以工作,但 LISTEN 繫結了一個連線,這限制了可擴充套件性,因為連線是有限且昂貴的。此外,像 PgBouncer 這樣的緩解策略不能與這種方法一起使用(我認為也不能擴充套件像 CitusDB 這樣的解決方案)。
當然,如果可擴充套件性不是問題(或者連線限制最終在 postgres 中得到修復 - 這在 14 中有所改進),這將是一個非常可行的方法。
與幾個使用者一起創業。高階工程師決定他們需要釋出/訂閱來發布新功能。藉助 Kafka,團隊將瞭解 Kafka 最佳實踐、選擇客戶端庫並瞭解 Kafka 的怪癖。他們還需要啟動 Kafka 例項。他們在一個月內交付。使用 postgres,他們可以在一天內獲得 MVP,並在一週內發貨。
我只花了兩個月的時間來展開一個不守規矩的 pg_boss 實現,那次經歷讓我對使用 postgres 進行釋出訂閱、工作或訊息傳遞感到厭煩。就我而言,Github Actions 適用於不頻繁的 cron 作業,或者即使是帶有 CloudWatch 規則的小型 lambda 也非常便宜,基礎設施即程式碼可以讓任何人都可以輕鬆(相對如此)部署。畢竟,我寧願將大部分時間花在編寫程式碼上,也不願成為 DevOps。如果我需要釋出/訂閱,我更願意使用 SNS 快速和骯髒,或 SNS+SQS 來處理繁重的工作。關注點分離和層分離對我來說仍然很重要,我不想依靠維護伺服器向前發展。
強烈反對將資料庫用作訊息佇列。這篇文章[0] 涵蓋了許多原因。總結:額外的應用程式複雜性並且不能很好地與工作人員一起擴充套件。
https://www.cloudamqp.com/blog/why-is-a-database-not-the-rig...
但是這篇文章可擴充套件性問題被誇大了。設定正確的隔離級別和鎖定模式並不難,現代雲託管的 PG/MySQL 可以每秒推送 10 萬次插入,沒問題。
我越來越認為關聯式資料庫絕對是為大多數專案構建佇列系統的正確方法。
當您開始從事務的角度考慮它們時,最大的優勢之一就會出現。事務保證在這裡非常有用:保證如果事務提交成功則將訊息寫入佇列,否則保證訊息不會寫入佇列。https://brandur.org/job-drain描述了使用 PostgreSQL 事務實現這一目標的絕佳模式。
rabbitmq 真的很難正確設定,而且諸如優先順序、基於時間的排程之類的東西並不比rabbitmq 容易得多。事實上,佇列增加了更多的複雜性,除非您超過資料庫規模,否則沒有必要。並不是說rabbitmq 可能更適合,它只是不適合開始。如果你有一個小於 8 的小團隊,最好儘可能少做一些事情,尤其是你知道的事情(很好)。
我之前曾考慮過使用 postgres 作為作業佇列,但我無法弄清楚如何確保兩個程式不會同時執行相同的工作。“FOR UPDATE”和“SKIP LOCKED”是本文中使這項工作成功的關鍵。本質上,據我所知,“SELECT FOR UPDATE”會在行被選中時鎖定它們(鎖定在事務之外顯然可見),而“SKIP LOCKED”則跳過其他事務已鎖定的選擇行。
下面的文章討論了將 postgres 用於作業佇列的一些缺點:即資料模型沒有最佳化以查詢新作業並將其傳送給大量訂閱者。像 Kafka/NATS 這樣的實際訊息傳遞系統在這方面做得更好。
https://www.2ndquadrant.com/en/blog/what-is-select-skip-lock...
這篇文章似乎是“訊息佇列公司討厭的一個奇怪的技巧”,因為據我所知,它正在以一種非常具體的方式利用一些 SQL 語義,以拼湊出一種方式來實現其他軟體旨在開箱即用的功能. 對於玩具系統來說,這似乎很好,但我不會將一家真正公司的成功押在這種方法上。
這篇文章再次證明,在 90% 的情況下 Postgres 是完全足夠的。如果您不期望高負載(並且大多數應用程式不期望),那麼就使用 Postgres,簡單勝出!
如果有人希望使用 postgres 作為帶有 node.js 客戶端的作業伺服器,我強烈推薦 pg-boss 庫 ( https://github.com/timgit/pg-boss )。看起來它也剛剛新增了 pub/sub(昨天),所以我想你也可以使用它。
相關文章
- Redis實現訊息釋出訂閱Redis
- 使用PostgreSQL替代Redis實現佇列、分散式鎖和釋出/訂閱SQLRedis佇列分散式
- Redis釋出訂閱Redis
- Redis 設計與實現 (六)--釋出訂閱Redis
- SpringBoot+Redis 實現訊息訂閱釋出Spring BootRedis
- [實戰]laravel + redis訂閱釋出 +swoole實現實時訂單通知LaravelRedis
- Redis(設計與實現):---釋出與訂閱介紹Redis
- Laravel Redis釋出與訂閱.LaravelRedis
- Redis 的訂閱與釋出Redis
- node 訂閱釋出及實現
- 設計模式之釋出訂閱模式(2) Redis 釋出/訂閱模式設計模式Redis
- 瑞士軍刀redis - 釋出訂閱Redis
- redis 釋出與訂閱原理分析Redis
- Redis系列(八):釋出與訂閱Redis
- 釋出於訂閱訊息系統-KafkaKafka
- Redis的訊息釋出和訂閱Redis
- 基於 Redis 的訂閱與釋出Redis
- SpringBoot Redis 釋出訂閱模式 Pub/SubSpring BootRedis模式
- js 實現簡單釋出訂閱模式JS模式
- spring boot 使用redis進行釋出訂閱Spring BootRedis
- 使用Spring Data Redis 釋出訂閱訊息SpringRedis
- 釋出-訂閱方式實現非同步併發非同步
- Redisson 分散式鎖實現之前置篇 → Redis 的釋出/訂閱 與 LuaRedis分散式
- Redis 釋出訂閱模式:原理拆解並實現一個訊息佇列Redis模式佇列
- 為什麼Twitter決定採用kafka作為其釋出訂閱系統?Kafka
- 面試官:請實現Javascript釋出-訂閱模式面試JavaScript模式
- redis原始碼分析之釋出訂閱(pub/sub)Redis原始碼
- Redis原始碼分析(三十)--- pubsub釋出訂閱模式Redis原始碼模式
- Redis學習筆記(二十) 釋出訂閱(下)Redis筆記
- 釋出訂閱EventEmitterMIT
- 釋出訂閱模式模式
- openGauss 釋出訂閱
- springboot整合redis實現訊息釋出訂閱模式-雙通道(跨多伺服器)Spring BootRedis模式伺服器
- 個人學習系列 - Spring Boot 配合 Redis 實現簡單的釋出訂閱功能Spring BootRedis
- 通過釋出訂閱模式實現的事件委託模式事件
- 如何實現一個簡單的釋出訂閱模式模式
- covrom/redispubsub:Redis Streams的釋出訂閱驅動程式VRRedis
- JS訂閱釋出模式JS模式