Khả năng mở rộng Websocket, mối quan tâm phát sóng

Question

Nếu bạn có yêu cầu phức tạp được thiết lập với nhiều người dùng (& máy chủ) cơ sở hạ tầng websocket của bạn (máy chủ) sẽ mở rộng như thế nào, đặc biệt là khi phát sóng?

Tất nhiên, phát sóng không phải là một phần của bất kỳ thông số kỹ thuật websocket nào nhưng nó có ngay cả trong các ví dụ trò chuyện cơ bản (a.k.a. hello world for websocket).

Giải pháp phía khách hàng (yêu cầu dữ liệu mới) vẫn có khả năng mở rộng hơn giải pháp phía máy chủ (phát sóng) với độ trễ thấp của websockets và tính chất tương đối rẻ (http headerless).

Edit:

OK, chỉ cần nghĩ rằng bạn muốn thay thế tất cả các mã ajax của bạn với việc triển khai WebSocket trong đó có thể có nghĩa là rất nhiều kết nối trong rất nhiều hoàn cảnh khác nhau. Điều này cho biết thêm phức tạp rất lớn cho hệ thống của bạn nếu bạn muốn theo dõi mọi tình huống có thể phát sóng.

Đề xuất cấp thấp (mạng/luồng vv) cũng là một phần của vấn đề không phải giải pháp, vì điều này có nghĩa là bạn phải mã hóa một máy chủ đặc biệt không giống như các máy chủ http chung.

Hơn nữa, phát sóng mang đến một số loại trạng thái có tính chất nhà nước cho bảng không thể dễ dàng mở rộng. Hãy suy nghĩ về việc thêm nhiều máy chủ hơn và cân bằng tải.

Answer 1

Scaling giải pháp web thời gian thực có thể là một vấn đề phức tạp nhưng một trong đó các dịch vụ như Pusher (những người tôi làm việc cho) đã được giải quyết, và một trong đó có chắc chắn hầu hết các giải pháp định nghĩa cho self hosted realtime web solutions - các PubSub paradigm cũng được hiểu và đã được giải quyết nhiều thời gian và để giải quyết vấn đề ở đó cần phải có một số trạng thái (ai đang đăng ký vào cái gì). Mô hình này được sử dụng trong việc phát sóng các loại kịch bản mà bạn đang nói đến.

công nghệ web thời gian thực đã được xây dựng với một lượng lớn kết nối đồng thời trong tâm trí - nhiều từ mặt đất lên. Nếu bạn muốn tạo giải pháp có thể mở rộng, bạn có thể sử dụng máy chủ web thời gian thực hiện có hỗ trợ WebSockets, giống như cách bạn sẽ quyết định triển khai Máy chủ HTTP của riêng mình mà bạn không muốn triển khai máy chủ của riêng mình hỗ trợ WebSockets từ đầu.

Máy chủ web chuyên dụng trong thời gian thực cũng cho phép bạn tách biệt logic ứng dụng khỏi cơ chế giao tiếp thời gian thực của bạn (tách mối quan tâm). Ứng dụng của bạn có thể cần duy trì một số trạng thái nhưng công nghệ thời gian thực giao dịch với quản lý đăng ký và kết nối.Làm thế nào giao tiếp giữa ứng dụng và công nghệ web thời gian thực đạt được là tùy thuộc vào bạn nhưng hàng đợi thông báo thường được sử dụng và cụ thể là redis rất phổ biến trong không gian này.

Việc bỏ phiếu HTTP có thể dễ hiểu hơn - bạn có thể duy trì trạng thái phi trạng thái và với mỗi yêu cầu thăm dò HTTP bạn chỉ định chính xác những gì bạn đang tìm kiếm. Nhưng nó chắc chắn nhất có nghĩa là bạn sẽ cần phải bắt đầu mở rộng quy mô sớm hơn (thêm nhiều tài nguyên hơn để xử lý tải).

Bỏ phiếu WebSocket là thứ mà tôi chưa xem xét trước đây và tôi không nghĩ rằng tôi đã từng thấy nó được đề xuất ở bất kỳ đâu trước đó; ý tưởng rằng khách hàng nên nói "Tôi đã sẵn sàng cho bộ dữ liệu tiếp theo của tôi và đây là những gì tôi muốn" là một điều thú vị. WebSockets thường lấy một bước nhảy vọt từ mô hình yêu cầu/phản hồi nhưng có thể có các tình huống mà hiệu quả của WebSockets tăng lên và yêu cầu/phản hồi bằng cách sử dụng chúng có thể có một số lợi ích. Khung ứng dụng SocketStream có thể đáng xem vì nó có thể có liên quan; sau khi tải ứng dụng ban đầu, tất cả các giao tiếp được thực hiện qua WebSockets, nghĩa là chức năng yêu cầu/phản hồi cơ bản của sự kiện sử dụng WebSockets.

Tuy nhiên, vì chúng ta đang nói về dữ liệu phát sóng chúng ta cần phải quay trở lại với mô hình PubSub nơi nó có ý nghĩa nhiều hơn nữa để có đăng ký hoạt động và khi dữ liệu mới có sẵn dữ liệu mới được phân phối đến những đăng ký đang hoạt động (được đẩy). Tất cả các ứng dụng của bạn cần biết là nếu có bất kỳ đăng ký hoạt động nào hay không để quyết định có xuất bản dữ liệu hay không. Vấn đề đó đã được giải quyết.

Answer 2

Ý tưởng về websockets là bạn giữ kết nối liên tục với từng khách hàng. Khi có dữ liệu mới mà bạn muốn gửi cho mọi khách hàng, bạn đã biết ai là tất cả khách hàng, vì vậy bạn chỉ cần gửi nó.

Có vẻ như bạn muốn mỗi khách hàng liên tục gửi yêu cầu đến máy chủ để có dữ liệu mới. Tại sao? Dường như điều đó sẽ lãng phí băng thông của mọi người và tôi không biết tại sao bạn nghĩ nó sẽ có khả năng mở rộng hơn. Có thể bạn có thể thêm chi tiết hơn cho câu hỏi của mình như loại thông tin bạn đang phát sóng, tần suất, số lượng byte, số lượng khách hàng, v.v.

Tại sao không chỉ xem xét kết nối websocket mở giống như yêu cầu thường trực từ khách hàng để có thêm dữ liệu?