Không đăng ký # - vậy làm cách nào để chuyển tất cả tin nhắn vào cơ sở dữ liệu với Mosquitto?


16

Danh sách blog của HiveMQ trong phần "thực tiễn tốt nhất" không đăng ký ký tự đại diện đa cấp khi cố gắng chuyển tất cả thư vào cơ sở dữ liệu. Họ cho rằng ứng dụng khách đăng ký có thể không theo kịp tải tin nhắn cao và đề xuất sử dụng plugin môi giới để trực tiếp móc vào luồng tin nhắn thay thế.

Đôi khi, cần phải đăng ký tất cả các tin nhắn, được chuyển qua nhà môi giới, ví dụ như khi lưu tất cả chúng vào cơ sở dữ liệu. Điều này không nên được thực hiện bằng cách sử dụng máy khách MQTT và đăng ký ký tự đại diện đa cấp. Lý do là thường thì khách hàng đăng ký không thể xử lý tải các thư đang đến. Đặc biệt là nếu bạn có một thông lượng lớn. Giải pháp được đề xuất của chúng tôi là triển khai tiện ích mở rộng trong nhà môi giới MQTT, ví dụ: hệ thống plugin của HiveMQ cho phép bạn nối vào hành vi của HiveMQ và thêm một thói quen không đồng bộ để xử lý từng thông báo đến và duy trì nó vào cơ sở dữ liệu.

Có phải không

  • một hệ thống tương tự (tiện ích mở rộng / plugin) cho nhà môi giới mosquitto,
  • một phương pháp được đề xuất khác hoạt động với mosquitto, hoặc
  • bằng chứng hợp lý rằng phương pháp này hoàn toàn không cần thiết, tức là khách hàng đăng ký #có thể làm tốt?

/programming//q/31584613/3984613 không giải quyết triệt để câu hỏi này.

Câu trả lời:


12

một hệ thống tương tự (tiện ích mở rộng / plugin) cho nhà môi giới mosquitto

Theo như tôi biết thì không có plugin / tiện ích mở rộng cho nhà môi giới mosquitto (ít nhất là không có mã nguồn mở)

một phương pháp được đề xuất khác hoạt động với mosquitto

Vâng, tôi có thể nói theo kinh nghiệm của tôi với nhà môi giới Mosquitto và AWS IoT, bạn chỉ có thể đăng ký trực tiếp vào '#'

Bằng chứng hợp lý

Sau khi xem câu hỏi này, tôi hơi tò mò muốn biết giới hạn thông lượng và tìm hiểu xem có cần một hệ thống mở rộng không. Vì vậy, tôi thiết lập như sau:

  • 100 hàm AWS Lambda hoạt động như các thiết bị đầu cuối ảo để gửi một số dữ liệu ngẫu nhiên tới Cổng (ví dụ EC2 t2.nanoRAM 500MB)
  • Cứ sau 60 giây, các chức năng được kích hoạt để xuất bản dữ liệu tới cổng vào các chủ đề khác nhau (lambdatoec2 / {Var biếnTopicNumberFrom1-100}
  • Ví dụ EC2 đang chạy Mosquitto 1.4.10

Đến bây giờ, tôi thấy rằng không có vấn đề gì khi đăng ký # mà không có bất kỳ hệ thống mở rộng nào. Nhưng một lần nữa tôi vẫn phải kiểm tra vài kịch bản trường hợp cạnh (tôi sẽ cập nhật câu trả lời một khi tôi sẽ kiểm tra chúng).


Câu trả lời "đúng" là thử nghiệm. Nếu có thể chứng minh rằng hiệu suất hệ thống của bạn bị ảnh hưởng bất lợi bằng cách thêm người đăng ký vào #, thì hãy cấu hình lại nhà môi giới để không cho phép đăng ký #. Tôi đã đưa ra câu trả lời này vì @bravokeyl đã làm chính xác điều đó.
John Deters

11

Cuộc thảo luận về danh sách gửi thư openHAB này dường như cho thấy không có vấn đề gì với việc sử dụng #như một thuê bao để nhận tất cả các tin nhắn:

Trong khi xử lý sự cố các thiết bị MQTT, đôi khi tôi ước mình có thể thấy tất cả các tin nhắn MQTT mà nhà môi giới Mosquitto nhìn thấy, thay vì một chủ đề cụ thể. Có cách nào để làm việc này không?

Ai đó đã trả lời câu hỏi này cho bạn trong danh sách Mosquitto; sử dụng ký tự đại diện. (#)

Câu hỏi Stack Overflow này cũng gợi ý phương pháp tương tự:

Đăng ký # cung cấp cho bạn đăng ký vào mọi thứ trừ các chủ đề bắt đầu bằng $ (dù sao đây cũng là các chủ đề kiểm soát).

Tất nhiên, tốt hơn là bạn nên biết những gì bạn đang đăng ký trước, và lưu ý rằng một số cấu hình của nhà môi giới có thể không cho phép đăng ký # một cách rõ ràng.

Như Bence Kaulics đã chỉ ra , thông số kỹ thuật nêu rõ #là hợp lệ:

Bình luận không quy tắc

  • Tên # # hợp lệ và sẽ nhận được mọi tin nhắn ứng dụng

Thành thật mà nói, tôi tranh luận liệu tuyên bố ban đầu có thực sự có ý nghĩa gì không:

Lý do là thường thì khách hàng đăng ký không thể xử lý tải các thư đang đến.

Nếu đó là trường hợp, làm thế nào các nhà môi giới có thể xử lý các tin nhắn ở nơi đầu tiên? Chừng nào khách hàng của bạn có đặc tính hiệu suất tương tự như môi giới, tôi mạnh mẽ nghi ngờ nó sẽ có thể áp đảo các khách hàng, bởi vì đó là mức độ giao thông cũng sẽ lấn át người môi giới và nguyên nhân đó để sụp đổ đầu tiên.

Tóm lại, yêu cầu HiveMQ dường như không được hỗ trợ bởi nhiều bằng chứng từ các nguồn khác và, khi bạn xem xét ý nghĩa thực sự của nó, nó có vẻ không hợp lý lắm.


10

Tôi nghĩ điều quan trọng là phải xem xét rằng có nhiều trường hợp sử dụng khác nhau cho các nhà môi giới MQTT, như với bất kỳ phần mềm nào.

Xử lý tin nhắn trò chuyện cho một tỷ người dùng (nhiều người dùng, tỷ lệ tin nhắn tương đối thấp trên mỗi người dùng) khác với một hệ thống có ít khách hàng nhưng tốc độ tin nhắn cao và cả hai đều khác với hệ thống tự động hóa gia đình (ít khách hàng, tốc độ tin nhắn thấp) .

HiveMQ đang suy nghĩ về các ứng dụng tốc độ tin nhắn / ứng dụng khách rất cao - trong trường hợp đó, khả năng của nhà môi giới gần như chắc chắn vượt xa khả năng của khách hàng.

Nếu bạn muốn đăng ký #trong hệ thống tự động hóa nhà của bạn thì điều đó thực sự không có khả năng gây ra vấn đề. Bạn có thể kiểm tra và xem liệu nhà môi giới có sử dụng CPU quá mức trong mọi trường hợp không.

Như trong các câu trả lời khác, đăng ký #sẽ cung cấp cho bạn tất cả các chủ đề 'bình thường', đó là bất cứ điều gì không bắt đầu bằng a $. Tôi giải thích spec như nói rằng mỗi chủ đề bắt đầu với $một cây toàn bộ riêng biệt của riêng mình, vì vậy bạn phải đăng ký $SYS/#, $whatever/#để có được tất cả mọi thứ . Bạn rất có thể không muốn làm điều đó cho một ứng dụng bình thường.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.