Lựa chọn công nghệ hàng đợi Postgres

 (adriano.fyi)
6 điểm bởi GN⁺ 2023-09-25 | 1 bình luận | Chia sẻ qua WhatsApp
  • Hàng đợi Postgres tốt nhưng không phải lựa chọn chủ lưu vì có quan niệm phổ biến rằng các công nghệ hàng đợi khác cung cấp khả năng mở rộng tốt hơn
  • Các công ty như webapp.io đã chọn hàng đợi Postgres vì coi trọng sự đơn giản trong vận hành, khả năng bảo trì và tính quen thuộc hơn khả năng mở rộng
  • Các thành phần của công nghệ hàng đợi Postgres
    • Thông báo và lắng nghe công việc mới (pub/sub) cùng với loại trừ lẫn nhau (row locks)
    • Cả hai đều đã có từ Postgres 9.5, phát hành năm 2016
  • Bác bỏ quan niệm phổ biến trong ngành rằng việc dùng Postgres theo cách này là kiểu "hack", và khẳng định Postgres không phải là công nghệ hàng đợi hạng xoàng
  • Redis, Apache Kafka, RabbitMQ, Amazon SQS v.v. từ lâu đã được chọn làm công cụ hàng đợi để xử lý các tác vụ chạy lâu
  • Chỉ trích sự ám ảnh của ngành công nghệ với "quy mô", cũng như việc hy sinh sự đơn giản, tính dễ bảo trì và giảm gánh nặng nhận thức cho lập trình viên
  • Tác giả đề xuất rằng khi đưa ra quyết định kỹ thuật, nên cân nhắc những công nghệ đang dùng và đã hiểu rõ
  • Khuyến nghị chọn "công nghệ nhàm chán" đã được sử dụng và thấu hiểu sẵn
  • Giới thiệu khái niệm "xây sẵn lối thoát", nghĩa là mã ứng dụng xử lý công việc nên độc lập với hàng đợi
  • Tác giả kết luận bằng việc khuyến khích mọi người cân nhắc công nghệ hàng đợi Postgres và lấy "công nghệ nhàm chán" làm lựa chọn mặc định

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-25
Ý kiến trên Hacker News
  • Kafka được công nhận về sự đơn giản, tính bền vững và khả năng chịu lỗi, nhưng bản chất phân tán của nó có thể làm tăng độ phức tạp trong phần lớn trường hợp sử dụng.
  • Hàng đợi Postgres có thể thay thế hàng đợi Redis, nhưng không thể thay thế hàng đợi SQS.
  • Postgres đã được dùng để xử lý hơn 400 triệu sự kiện kể từ khi hệ thống đi vào hoạt động, và xử lý khoảng 1 triệu sự kiện mỗi ngày.
  • Sử dụng bảng thông thường với SELECT FOR UPDATE SKIP LOCKED là một cách tiếp cận đơn giản hoạt động trên mọi framework ORM/Query DSL.
  • Nhược điểm chính khi dùng LISTEN/NOTIFY để sử dụng PostgreSQL như một bus pub/sub là LISTEN là một tính năng cấp phiên, nên không tương thích với connection pooling ở cấp câu lệnh.
  • Việc dùng Postgres làm hàng đợi cho ứng dụng có lợi thế về tính giao dịch, nên các tác vụ bất đồng bộ được lên lịch sẽ hưởng lợi từ điều này.
  • Postgres có thể mở rộng cho hàng đợi, nhưng trên AWS, GCP, Azure thì việc thiết lập SQS hoặc stack hàng đợi khác sẽ đơn giản hơn và được xây dựng đúng theo mục đích.
  • Postgres đã chạy benchmark ở mức 1200 jobs/s trên instance CI của GitHub, và mở rộng lên 5000 jobs/s với các worker bổ sung.
  • Postgres dùng Oban của Elixir đã được sử dụng để xử lý riêng lẻ từ hàng trăm nghìn đến hàng triệu tác vụ mỗi ngày, nơi tính ngữ nghĩa giao dịch quanh các background job đã được chứng minh là tiện lợi.
  • Một triển khai đã xử lý 47M tác vụ nhấn mạnh lợi ích của lưu trữ bền vững với SKIP LOCKED cho VACUUM, tác vụ trì hoãn, retry, cập nhật trạng thái và các chỉ mục để triển khai những mẫu tốn kém như "ít nhất một lần".