Tôi đã được yêu cầu thiết kế và triển khai hệ thống để nhận khối lượng lớn dữ liệu cảm biến tự động từ một số lượng lớn thiết bị. Dữ liệu này sẽ được tạo ra đều đặn và được gửi đến máy chủ dưới dạng xml trong bài đăng http. Các thiết bị sẽ tiếp tục gửi lại cùng một dữ liệu nếu chúng không nhận được một xác nhận cụ thể từ máy chủ. Một số xử lý có khả năng nặng nề của dữ liệu này sẽ cần phải xảy ra trước khi nó được chèn vào một số bảng trong cơ sở dữ liệu chính thông qua một giao dịch, và thêm một số điểm dữ liệu sẽ cần phải được enqueued để được chuyển hướng đến các url bên ngoài khác.Những cạm bẫy tiềm năng trong việc sử dụng hàng đợi JMS?
Tôi đang lập kế hoạch sử dụng máy chủ ứng dụng Java (nghiêng về phía GlassFish) với một servlet để nhận dữ liệu đến. Tôi muốn thực hiện một số loại cơ chế xếp hàng để lưu trữ dữ liệu tạm thời để phản hồi trở lại cảm biến không phụ thuộc vào tất cả xử lý trung gian. Các hàng đợi độc lập riêng biệt cũng là một yêu cầu đối với phần dữ liệu hướng lại. Sau khi thực hiện một số nghiên cứu, hai tùy chọn chính có vẻ là:
1) Cài đặt cơ sở dữ liệu trên máy chủ ứng dụng và sử dụng bảng cho các hàng đợi khác nhau. Các hàng đợi sẽ được xử lý bởi một ứng dụng Java, hoặc đang chạy trong máy chủ ứng dụng hoặc độc lập như là dịch vụ riêng của nó.
2) Sử dụng giải pháp JMS được cơ sở dữ liệu hỗ trợ để triển khai hàng đợi.
Tôi không quen thuộc với JMS nhưng từ những gì tôi đã đọc nó có vẻ là giải pháp tốt hơn trong trường hợp này. Yêu cầu chính là không có dữ liệu cảm biến nào bị mất hoặc bị mất khỏi hàng đợi trước khi được xử lý và nó được xử lý nhiều hay ít tuần tự. Chúng tôi cũng muốn làm cho nó dễ dàng để ngăn chặn việc xử lý một số hàng đợi vào những thời điểm nhất định nhưng vẫn có họ tích lũy dữ liệu và cho những tin nhắn này không bao giờ tự động hết hạn.
Với chiến lược 1 rõ ràng với tôi cách đáp ứng các yêu cầu này nhưng nó có thể kém mạnh mẽ và có thể mở rộng và phức tạp hơn để phát triển so với chiến lược 2, vì tôi cần phải viết mã đa luồng của riêng mình để xử lý hàng đợi độc lập khác nhau. Tôi tự hỏi những gì tiềm năng cạm bẫy có thể được trong việc sử dụng hàng đợi JMS cho mục đích này kể từ khi tôi đã không bao giờ làm việc với họ trước.
Tính toàn vẹn dữ liệu là một vấn đề lớn vì vậy tôi cần đảm bảo rằng JMS có thể đảm bảo không mất dữ liệu trong trường hợp khởi động lại máy chủ, mất điện hoặc nếu hàng đợi rất lớn vì lý do nào đó. Ví dụ, một vấn đề có thể hoàn thành giao dịch với cơ sở dữ liệu chính trong một khoảng thời gian có khả năng gây ra JVM hết bộ nhớ, sự cố và mất tất cả dữ liệu tích lũy? (Đây sẽ là kịch bản ác mộng).
Ngoài ra, tôi đã tự hỏi liệu có cách nào để tạm dừng xử lý hàng đợi JMS thông qua công cụ quản trị máy chủ ứng dụng hay không dễ dàng xem nội dung trong hàng đợi (tôi sẽ đặt một đối tượng sẽ là thông điệp xml cộng với một số dữ liệu khác, bao gồm cả dấu thời gian nhận được, vv) Tôi đã đọc một vài bài viết ở đây mà đối phó với các vấn đề liên quan nhưng muốn nhận được một số thông tin phản hồi trực tiếp. Về cơ bản tôi muốn biết các trường hợp (nếu có), nơi JMS không phải là một giải pháp xếp hàng thích hợp và nếu đây là một trong những trường hợp đó. Bất cứ lời khuyên nào cũng đươc đánh giá cao.
Không phải là một anh chàng Java chút nào, nhưng điều này không hàm ý chờ đợi một hàng đợi trả lời cho kết quả phản hồi? Điều này có vẻ như là một thỏa thuận-breaker nếu giao thức khách hàng của bạn là HTTP. Điều này sẽ không phải buộc một sợi? – Bob77
Có hai kịch bản xếp hàng riêng biệt mà tôi phải giải quyết. Một là một hàng đợi đến cơ sở dữ liệu chính, đó sẽ là một kết nối thông qua một hồ bơi kết nối jdbc. Đây là những gì servlet sẽ ghi vào. Cái còn lại sẽ chứa một tập hợp con của dữ liệu này, sẽ được đưa vào hàng đợi riêng biệt này sau khi được xử lý thành công trong hàng đợi chính. Người tiêu dùng của hàng đợi này sẽ gửi tin nhắn qua http đến một trang web khác. Điều này có nghĩa là đáp ứng servlet ban đầu sẽ được phân cách bởi hai hàng đợi từ kết quả của bài đăng http đến trang web của bên thứ ba. – user256447