Mối quan hệ giữa các kết nối JMS, phiên và nhà sản xuất/người tiêu dùng

Question

Tôi muốn gửi một loạt 20 nghìn tin nhắn JMS đến cùng một hàng đợi. Tôi đang chia nhiệm vụ bằng cách sử dụng 10 chủ đề, do đó, mỗi luồng sẽ xử lý 2k thư. Tôi không cần giao dịch.

Tôi đã tự hỏi nếu có một kết nối, một phiên, và 10 nhà sản xuất là cách đề nghị để đi hay không?

Nếu tôi có một nhà sản xuất được chia sẻ bởi tất cả các chủ đề thì sao? Các tin nhắn của tôi có bị hỏng hay nó sẽ được gửi đi đồng bộ (không có hiệu năng)? phương châm chung của quyết định có nên tạo một kết nối mới hoặc phiên làm việc nếu tôi luôn luôn kết nối với cùng một hàng đợi là

gì?

Cảm ơn bạn và xin lỗi vì đã yêu cầu rất nhiều cùng một lúc.

(Đây là một câu hỏi tương tự, nhưng nó đã không hoàn toàn trả lời những gì tôi đang tìm kiếm. Long lived JMS sessions. Is Keeping JMS connections/JMS sessions allways open a bad pratice?)

Answer 1

Có OK không nếu một số thư bị trùng lặp hoặc bị mất? Khi máy khách JMS kết nối với nhà môi giới JMS qua mạng, có ba giai đoạn cho bất kỳ cuộc gọi API nào.

1. Cuộc gọi API, bao gồm mọi dữ liệu tin nhắn, được truyền qua dây cho người môi giới.
2. Cuộc gọi API được thực hiện bởi người môi giới.
3. Mã kết quả và mọi dữ liệu tin nhắn được truyền lại cho khách hàng.

Hãy xem xét các nhà sản xuất trong một phút. Nếu kết nối bị hỏng trong bước đầu tiên thì nhà môi giới không bao giờ nhận được tin nhắn và ứng dụng sẽ cần phải gửi lại. Nếu kết nối bị hỏng ở bước thứ ba thì tin nhắn đã được gửi thành công và gửi lại sẽ tạo ra một thông báo trùng lặp. Các ứng dụng không thể nói sự khác biệt giữa những điều này và do đó, sự lựa chọn an toàn duy nhất là gửi lại tin nhắn về lỗi. Nếu phiên giao dịch được thông báo có thể được gửi lại một cách an toàn trong mọi trường hợp bởi vì nếu bản gốc đã được gửi cho người môi giới, nó sẽ được khôi phục.

Cân nhắc người tiêu dùng. Nếu kết nối bị mất ở bước thứ ba thì thông báo sẽ bị xóa khỏi hàng đợi nhưng không bao giờ được gửi lại cho máy khách. Nhưng nếu phiên giao dịch được thông báo thì sẽ được gửi lại khi ứng dụng kết nối lại.

Bên ngoài giao dịch có khả năng thư bị mất hoặc trùng lặp. Bên trong của một giao dịch cùng một cửa sổ của sự mơ hồ tồn tại nhưng nó là trên các cuộc gọi COMMIT chứ không phải là PUT hoặc GET. Với phiên giao dịch, bạn có thể gửi hoặc nhận tin nhắn hai lần nhưng không thể mất một lần.

Các JMS đặc tả công nhận cửa sổ này mơ hồ và cung cấp các hướng dẫn sau đây:

Nếu một thất bại xảy ra giữa lần một khách hàng cam kết công việc của mình trên một phiên và phương pháp cam kết lợi nhuận, khách hàng không thể xác định nếu giao dịch được thực hiện hoặc được khôi phục. Sự mơ hồ tương tự tồn tại khi xảy ra sự cố giữa số gửi không giao dịch của thông báo NGƯỜI DÙNG và trả lại từ phương thức gửi .

Nó tùy thuộc vào ứng dụng JMS để xử lý với sự mơ hồ này. Trong một số trường hợp, điều này có thể khiến khách hàng tạo ra các thông báo trùng lặp chức năng .

Thư được gửi lại do khôi phục phiên không được coi là một thông báo trùng lặp .

Các phiên JMS phải luôn được giao dịch ngoại trừ trường hợp thật sự mất thông báo. Nếu các phiên được giao dịch thì bạn cần phiên và kết nối cho mỗi luồng do mô hình chuỗi JMS.

Bất kỳ lời khuyên nào về tác động hiệu suất sẽ là nhà cung cấp cụ thể nhưng trong các thông báo liên tục nói chung bên ngoài điểm đồng bộ hóa được cứng vào đĩa trước khi trả về cuộc gọi API. Nhưng cuộc gọi được giao dịch có thể trở lại trước khi thông báo liên tục được ghi vào đĩa miễn là thông báo được duy trì trước khi COMMIT trả về. Nếu nhà cung cấp tối ưu hóa dựa trên điều này, sau đó nó là nhiều hơn nữa performant để viết một số tin nhắn vào đĩa và sau đó cam kết chúng theo lô. Điều này cho phép các nhà môi giới để tối ưu hóa ghi và đĩa tuôn ra bởi khối đĩa chứ không phải là cho mỗi tin nhắn. Số lượng tin nhắn được đặt trong giao dịch giảm theo kích thước của tin nhắn và vượt quá một kích thước tin nhắn nào đó sẽ giảm xuống một.

Nếu thư 20k của bạn tương đối nhỏ (được đo bằng k và không phải mb) thì bạn có thể muốn sử dụng phiên giao dịch cho mỗi chuỗi và điều chỉnh khoảng thời gian cam kết.

Answer 2

Trong Connections lý thuyết là thread-safe nhưng tất cả những người khác thì không, vì vậy bạn nên tạo một phiên mỗi chủ đề.

Thực tế, nó phụ thuộc vào việc triển khai JMS bạn đang sử dụng.

Answer 3

Trong hầu hết các tình huống đó là đủ để làm việc với các phiên một kết nối và nhiều, sử dụng một phiên cho mỗi thread. Trong một số môi trường mà bạn có thể đạt được hiệu suất bổ sung bằng cách sử dụng nhiều kết nối:

Một số hệ thống tin nhắn ủng hộ một chế độ cluster, nơi kết nối được loadbalanced đến các nút khác nhau. Với nhiều kết nối, bạn có thể sử dụng hiệu suất của nhiều nút trong kịch bản này. (Tất nhiên điều này chỉ giúp đỡ, khi nút cổ chai ở bên cạnh nhà môi giới tin nhắn).

Giải pháp tốt nhất sẽ cho chúng ta một hồ bơi của các kết nối, và cung cấp cho các quản trị viên một số tùy chọn để cấu hình các hành vi trong lĩnh vực cụ thể.

Answer 4

I was wondering if having one connection, one session, and 10 producers 
is the recommended way to go or not? 

Chắc chắn nhưng điểm cần lưu ý ở đây là bạn đang sử dụng chỉ một chuỗi duy nhất mà bạn tạo trong khi tạo đối tượng Phiên. Tất cả 10 nhà sản xuất đều bị ràng buộc với đối tượng phiên này và do đó cùng một chủ đề.

How about if I had one producer shared by all the threads? Would my messages 
be corrupt or would it be sent out synchronized (giving no performance gain)? 

Ý tưởng tồi tôi sẽ nói. Thông số kỹ thuật của JMS nói rõ ràng Phiên không được chia sẻ bởi nhiều hơn một chuỗi. Nó không phải là chủ đề an toàn.

What's the general guideline of deciding whether to create a new connection 
or session if I'm always connecting to the same queue? 

Nếu hệ thống của bạn hỗ trợ đa luồng thì bạn có thể tạo nhiều phiên (mỗi phiên tương ứng với một chuỗi) từ một kết nối. Mỗi phiên có thể có nhiều nhà sản xuất/người tiêu dùng nhưng tất cả những điều này không được chia sẻ giữa các chủ đề.

Answer 5

Từ những gì tôi điều tra chủ đề này, một phiên có nghĩa là một chuỗi. Điều này dựa trên thông số kỹ thuật của JMS. Nếu bạn muốn nhiều luồng (nhiều nhà sản xuất/người tiêu dùng), nhiều phiên cần phải được tạo, một kết nối là tốt.