Xây dựng dịch vụ web có tính sẵn sàng cao mà không cần cơ sở dữ liệu

 (blog.screenshotbot.io)
1 điểm bởi GN⁺ 2024-08-11 | 1 bình luận | Chia sẻ qua WhatsApp

Xây dựng dịch vụ web có tính sẵn sàng cao mà không cần cơ sở dữ liệu

Khám phá

  • Với một startup mới, thông thường sẽ chọn các web framework như Rails, Django, Node cùng với các cơ sở dữ liệu như MySQL, PostgreSQL, MongoDB
  • Nhưng nếu có thể gộp dịch vụ web và instance cơ sở dữ liệu thành một thì sao? Có thể tiếp cận theo cách lưu toàn bộ dữ liệu trong RAM
  • Khi dùng RAM làm cơ sở dữ liệu, không còn cần tuần tự hóa dữ liệu bằng truy vấn SQL
  • Chỉ mục có thể được triển khai bằng bảng băm trong bộ nhớ
  • Tác vụ nền có thể được xử lý bằng các luồng bên trong một tiến trình lớn
  • Nếu tiến trình bị crash, có thể khôi phục bằng cách chụp snapshot RAM định kỳ và ghi các thay đổi xuống đĩa

Mở rộng

  • Khi xuất hiện khách hàng yêu cầu tính sẵn sàng cao, có thể sao chép máy chủ bằng thuật toán đồng thuận Raft
  • Nếu máy chủ leader gặp sự cố, một leader mới sẽ được bầu để xử lý yêu cầu
  • Theo cách này, có thể triển khai rolling deployment mà không cần khởi động lại máy chủ

Tách ra

  • Khi số lượng khách hàng lớn tăng lên, có thể phân chia dịch vụ web bằng sharding để xử lý
  • Cung cấp cụm chuyên dụng cho từng khách hàng doanh nghiệp
  • Điểm nghẽn chính có thể là hiệu năng của commit thread

Stack của chúng tôi

  • Dùng Common Lisp: hỗ trợ đa luồng rất tốt và phù hợp cho hot reloading mã
  • Dùng bknr.datastore và bknr.cluster: sử dụng thư viện Braft của Baidu để triển khai Raft
  • Dùng EFS để lưu tệp hình ảnh: dễ xử lý lỗi và kiểm thử hơn S3

Tóm tắt

  • Kiến trúc này phù hợp với các startup mới, và khi dùng Common Lisp thì nhiều công cụ đã sẵn có
  • Xin cảm ơn những đóng góp của bknr.datastore, Braft và Raft

Tổng hợp của GN⁺

  • Bài viết này giới thiệu một kiến trúc mới để xây dựng dịch vụ web có tính sẵn sàng cao mà không cần cơ sở dữ liệu
  • Dùng RAM làm cơ sở dữ liệu và đảm bảo tính sẵn sàng cao thông qua thuật toán đồng thuận Raft
  • Sử dụng Common Lisp để hỗ trợ đa luồng và hot reloading mã
  • Kiến trúc này phù hợp với các startup mới, cho phép phát triển và gỡ lỗi nhanh
  • Các dự án có chức năng tương tự gồm Redis và Memcached

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-08-11
Ý kiến trên Hacker News

  • Việc tự tạo transaction log thay vì dùng SQLite là khá kỳ lạ

    • Nếu dữ liệu vừa trên một máy chủ, tốt nhất cứ chạy cơ sở dữ liệu trên chính máy chủ đó
    • Nếu dữ liệu vừa trong RAM, dùng ramdisk và sao chép sang bộ nhớ lưu trữ bền vững bằng các công cụ tiêu chuẩn sẽ đơn giản hơn

  • Việc tự xây dựng cơ sở dữ liệu in-memory thay vì dùng MySQL, Postgres, Redis, MongoDB, v.v. là rất phức tạp

    • Phải tuần tự hóa transaction và ghi chúng xuống đĩa
    • Phải đồng bộ transaction log giữa các web server và cập nhật cơ sở dữ liệu in-memory
    • Phải viết thuật toán giải quyết xung đột
    • Phải shard web server theo từng tenant và viết một tầng load balancing

  • Không muốn học những khía cạnh cơ bản của MySQL hay Postgres là một sự lãng phí thời gian

    • Khi chạy trên nhà cung cấp cloud công cộng, có thể giải quyết vấn đề đồng thời bằng tinh chỉnh mặc định
    • Thêm 10 triệu hàng không phải là vấn đề lớn
    • Khôn ngoan hơn là chờ đến khi tình hình thực sự tệ hơn rồi mới giải quyết

  • Đây là kiến trúc tương tự Nomad, Consul và Vault của HashiCorp

    • Trải nghiệm nhà phát triển tốt
    • Có thể thiết lập trạng thái in-memory theo ý muốn
    • Không phù hợp với các startup mới
    • Việc nâng cấp đặc biệt khó khăn

  • Có một hiểu lầm rằng RAM rất rẻ

    • Hiệu năng SSD và vCPU đã cải thiện đáng kể, nhưng giá RAM không giảm nhiều
    • Giá DRAM biến động theo chu kỳ và chỉ gần đây mới rẻ hơn đôi chút

  • Đã từng thấy một dự án dùng thư mục hệ thống tệp làm bảng và file JSON làm hàng

    • Đã cân nhắc Redis, Mongo, Postgres nhưng cuối cùng lại tự xây cơ sở dữ liệu
    • Dùng những token mang tính đột phá để xây cơ sở dữ liệu là không hiệu quả

  • Dùng cơ sở dữ liệu quan hệ ổn định hơn

    • Có sẵn các tính năng dư thừa, transaction log, sao lưu và khôi phục
    • Trong hầu hết trường hợp, nên dùng cơ sở dữ liệu

  • Đã tự triển khai một tầng đồng thuận Raft để tránh thứ gì đó phức tạp hơn

    • Có thể dùng Redis sẽ đơn giản hơn

  • Các ứng dụng desktop và mobile hiện đại thường dùng cơ sở dữ liệu như SQLite

    • Việc lưu trữ và truy vấn dữ liệu quan hệ rất hữu ích

  • Tự xây dựng cơ sở dữ liệu in-memory không hề đơn giản hơn việc cài Postgres hay SQLite

    • Viết SQL dễ hơn viết mã xử lý đồng thời nhiều