Tôi vừa đọc bài viết này , và tôi bối rối.
Hãy tưởng tượng 1 ứng dụng web và 1 ứng dụng riêng biệt đóng vai trò là "công nhân", cả hai đều chia sẻ cùng một cơ sở dữ liệu .
Ồ, tôi đã nói "chia sẻ" .. nhưng bài báo cảnh báo về điều gì? :
Thứ tư, chia sẻ cơ sở dữ liệu giữa các ứng dụng (hoặc dịch vụ) là một điều xấu. Thật quá hấp dẫn khi đặt trạng thái chia sẻ vô định hình vào đó và trước khi bạn biết nó sẽ có một con quái vật cực kỳ ghép đôi.
=> không đồng ý. Có một số trường hợp các ứng dụng riêng biệt vẫn là một phần của cùng một đơn vị, và do đó, khái niệm "vấn đề khớp nối" không có ý nghĩa gì trong trường hợp này.
Hãy tiếp tục: Ứng dụng web xử lý các yêu cầu HTTP của máy khách và có thể cập nhật bất cứ lúc nào một số tổng hợp (thuật ngữ DDD), tạo ra các sự kiện miền tương ứng.
Mục tiêu của công nhân sẽ là xử lý các sự kiện miền đó bằng cách xử lý các công việc cần thiết.
Điểm mấu chốt là:
Làm thế nào dữ liệu sự kiện nên được truyền cho công nhân?
Giải pháp đầu tiên, như bài viết đã đọc quảng bá, sẽ là sử dụng RabbitMQ, là một phần mềm trung gian hướng thông điệp tuyệt vời.
Quy trình làm việc sẽ đơn giản:
Bất cứ khi nào web dyno tạo ra một sự kiện, nó sẽ xuất bản nó thông qua RabbitMQ, nơi cung cấp cho nhân viên.
Hạn chế là không có gì đảm bảo tính nhất quán ngay lập tức giữa cam kết của bản cập nhật tổng hợp và xuất bản sự kiện, mà không xử lý các lỗi gửi tiềm năng ... hoặc các sự cố phần cứng; đó là một vấn đề chính khác
Ví dụ: Có thể một sự kiện đã được xuất bản mà không thành công trong bản cập nhật tổng hợp ... dẫn đến một sự kiện thể hiện sự thể hiện sai của mô hình miền.
Bạn có thể lập luận rằng XA toàn cầu (cam kết hai pha) tồn tại, nhưng đó không phải là giải pháp phù hợp với tất cả các cơ sở dữ liệu hoặc phần mềm trung gian.
Vì vậy, những gì có thể là một giải pháp tốt để đảm bảo tính nhất quán ngay lập tức này? :
IMO, lưu trữ sự kiện trong cơ sở dữ liệu, trong cùng một giao dịch cục bộ như cập nhật tổng hợp.
Một bộ lập lịch không đồng bộ đơn giản sẽ được tạo và chịu trách nhiệm truy vấn các sự kiện chưa được công bố hiện tại từ cơ sở dữ liệu và gửi chúng đến RabbitMQ, từ đó đưa vào công nhân.
Nhưng tại sao cần một bộ lập lịch bổ sung trong webapp và nhân tiện: tại sao cần RabbitMQ trong trường hợp này?
Theo giải pháp này, có vẻ như logic, rằng RabbitMQ có thể không cần thiết, đặc biệt là vì cơ sở dữ liệu được chia sẻ.
Thật vậy, bất kể trường hợp nào, chúng tôi thấy rằng tính nhất quán ngay lập tức liên quan đến việc bỏ phiếu từ cơ sở dữ liệu.
Vì vậy, tại sao công nhân sẽ không chịu trách nhiệm trực tiếp cho cuộc bỏ phiếu này?
Do đó, tôi tự hỏi tại sao rất nhiều bài viết trên web chỉ trích việc xếp hàng cơ sở dữ liệu khó khăn, trong khi quảng bá phần mềm trung gian hướng thông báo.
Trích đoạn của bài viết:
Đơn giản, sử dụng công cụ phù hợp cho công việc: kịch bản này đang khóc cho một hệ thống nhắn tin. Nó giải quyết tất cả các vấn đề được mô tả ở trên; không bỏ phiếu, gửi tin nhắn hiệu quả, không cần xóa tin nhắn đã hoàn thành khỏi hàng đợi và không có trạng thái chia sẻ.
Và nhất quán ngay lập tức, bỏ qua?
Tóm lại, có vẻ như bất kể trường hợp nào, có nghĩa là cơ sở dữ liệu được chia sẻ hay không, chúng ta cần bỏ phiếu cơ sở dữ liệu .
Tôi đã bỏ lỡ một số khái niệm quan trọng?
Cảm ơn