Bối rối khi bạn sử dụng JMS (hoặc hàng đợi nói chung) so với cơ sở dữ liệu

Question

Khi bạn lưu trữ thư trong hàng đợi, không phải là thông tin siêu dữ liệu để ai kéo từ hàng đợi biết cách xử lý dữ liệu? thông tin thực tế trong hàng đợi không phải lúc nào cũng giữ tất cả thông tin.

Giả sử bạn có một ứng dụng như Twitter, bất cứ khi nào ai đó đăng tin nhắn, bạn vẫn cần lưu trữ văn bản tin nhắn thực sự trong cơ sở dữ liệu chính xác?

Hàng đợi sẽ được sử dụng nhiều hơn để phát sóng cho những người đăng ký khác mà một tin nhắn mới đã đến và sau đó các dịch vụ đó có thể thực hiện thêm hành động.

Hoặc bạn có thể lưu trữ văn bản tweet trong hàng đợi không? (hoặc bạn CÓ THỂ, nhưng điều đó sẽ ngớ ngẩn?)

Có thể một thông điệp hàng đợi có các trường trạng thái, người đăng ký có thể thay đổi khi họ xử lý một phần của luồng công việc không? (hoặc bạn sẽ làm điều đó trong db?)

Chỉ cố gắng làm rõ một số khi bạn sử dụng hàng đợi so với db.

Answer 1

Khi một quá trình muốn dữ liệu trang trại và xử lý dữ liệu mà ra đến một quá trình (có thể trên một máy chủ khác nhau), có 2 chiến lược:

1. Stuff tất cả dữ liệu của bạn vào mục hàng đợi và cho phép ứng dụng nhận lo lắng về việc lưu trữ nó trong cơ sở dữ liệu, trong số đó với bất kỳ xử lý nào khác.

2. Cập nhật cơ sở dữ liệu của bạn và sau đó xếp hàng một thông điệp nhỏ đến quy trình khác chỉ để thông báo rằng có dữ liệu mới cần được xoa bóp.

Có một số yếu tố có thể được sử dụng để quyết định mà chiến lược:

• Nếu cơ sở dữ liệu của bạn là hoàn toàn ACID (một hy vọng) nhưng hệ thống xếp hàng của bạn (QS) không phải là , dữ liệu của bạn sẽ an toàn hơn trong DB. Ngay cả khi thông báo hàng đợi bị mất trong một sự cố máy chủ, bạn có thể chạy một tập lệnh để xử lý dữ liệu chưa xử lý được tìm thấy trong DB. Đây có thể là trường hợp cho tùy chọn 2.

• Nếu dữ liệu của bạn khá lớn (ví dụ: 1 MB trở lên) thì có thể sẽ tàn nhẫn để gánh nặng QS của bạn với nó. Nếu nó liên tục, bạn sẽ kết thúc bằng văn bản dữ liệu hai lần, trước tiên là của pers của QS và sau đó là DB. Điều này có thể kéo theo hiệu suất và ảnh hưởng bạn đến tùy chọn 1.

• Nếu DB của bạn chậm hoặc thậm chí không thể truy cập vào giao diện người dùng của ứng dụng, thì tùy chọn 1.

• Nếu quy trình thứ hai của bạn sẽ làm điều gì đó với dữ liệu nhưng không lưu trữ dữ liệu trong DB, thì tùy chọn 1 có thể là cách để thực hiện.

Không thể nghĩ ra thêm nữa, nhưng tôi hy vọng bạn sẽ có ý tưởng.

Answer 2

Tôi nghĩ rằng ví dụ twitter của bạn là tốt. Bạn muốn cơ sở dữ liệu cho dữ liệu dài hạn. Sẽ không có nhiều điểm trong việc đưa tweet vào tin nhắn vì nó phải đi vào cơ sở dữ liệu. Tuy nhiên, nếu bạn đang chạy một phòng chat thì bạn có thể tiếp tục và đặt thông điệp vào hàng đợi JMS vì bạn không lưu trữ nó lâu dài ở bất cứ đâu.

Nó không phải là bạn không thể đặt các tweet trong JMS nó là bạn cần phải đặt nó trong anyways cơ sở dữ liệu.

Answer 3

Tôi khuyên bạn nên xem cuốn sách của Gregor Hophe, Enterprise Integration Patterns, giải thích nhiều mẫu khác nhau cho phương pháp tiếp cận dựa trên thông điệp.

Answer 4

Nói chung, hàng đợi được sử dụng để 'làm mịn' tốc độ xuất bản so với tỷ lệ tiêu thụ, bằng cách đệm các yêu cầu đến không thể xử lý ngay lập tức. Hàng đợi thường được hỗ trợ bởi một số loại lưu trữ không bay hơi (chẳng hạn như bảng cơ sở dữ liệu). Vì vậy, sự khác biệt không phải là quá rõ ràng.

Sử dụng cơ sở dữ liệu khi bạn muốn thực hiện nhiều tìm kiếm đối với 'hàng đợi' hoặc cung cấp báo cáo chi tiết.

Answer 5

Tôi sẽ sử dụng hàng đợi bất cứ khi nào bạn có thể sử dụng mẫu "lửa và quên". Trong ví dụ Twitter của bạn, tôi sẽ sử dụng hàng đợi để đăng thông báo từ máy khách. Bộ xử lý hàng đợi sau đó có thể lưu nó vào cơ sở dữ liệu khi nó đến được nó.

Nếu bạn yêu cầu một số loại trạng thái thành công/lỗi ngay lập tức, thì hàng đợi tin nhắn không dành cho bạn.

Answer 6

Chúng tôi đã sử dụng JMS rộng rãi ở công việc cuối cùng của mình, nơi chúng tôi chuyển dữ liệu từ máy này sang máy khác. Cuối cùng, cả hai chúng tôi đều gửi và lưu trữ dữ liệu cùng một lúc; tuy nhiên, chúng tôi đã lưu trữ ít dữ liệu hơn chúng tôi đã gửi. Chúng tôi có rất nhiều siêu dữ liệu xung quanh giá trị thực.

Chúng tôi đã sử dụng JMS đơn giản như một dịch vụ nhắn tin và nó hoạt động rất tốt cho điều đó. Tuy nhiên, bạn không muốn sử dụng JMS để lưu trữ dữ liệu của bạn vì nó không có sự kiên trì (ngoài việc có thể đăng nhập và phát lại các tin nhắn có lẽ).

Một trong những lợi thế chính mà JMS cung cấp cho bạn là khả năng gửi tin nhắn của bạn theo thứ tự chính xác và phù hợp và đảm bảo mọi người nhận được chúng theo thứ tự đó. Điều này giúp việc đồng bộ hóa dễ dàng vì phần lớn xử lý tin nhắn được thực hiện cho bạn.

Answer 7

Sự hiểu biết của tôi là Twitter sẽ sử dụng cả DB và JMS chung. Đầu tiên khi các tweets được viết, nó sẽ lưu trữ nó trong cơ sở dữ liệu và đây là cách nó sẽ hiển thị trong bảng tin. Tuy nhiên vì đây là mô hình nhà xuất bản/người đăng ký khi các mẩu tin được xuất bản, nó sẽ được gửi tới người đăng ký. Vì vậy, cả hai mục sẽ được sử dụng.