Thiết kế/Kiến trúc: kết nối web-socket một kết nối với nhiều kết nối

Question

Trong khi thiết kế kiến ​​trúc máy khách/máy chủ, có lợi thế nào để ghép nhiều kết nối WEBSOCKET từ cùng một tiến trình với máy chủ (nghĩa là chia sẻ một kết nối) hay không Kết nối WEBSOCKET trên mỗi luồng/phiên trong máy khách (như thường được thực hiện khi kết nối với máy chủ lưu trữ hoặc máy chủ cơ sở dữ liệu.)

Tôi biết về chi phí kết nối với mỗi kết nối (ví dụ RAM ...). Nhưng mong đợi có ít nhất 1K-10K ở mức tối đa ở mỗi phía khách hàng.

---

trường hợp sử dụng cụ thể: Cho phép giả định, tôi có một máy chủ từ xa với nhiều phiên ở một bên, và ở phía bên kia tôi có nhiều khách hàng, mỗi khách hàng sẽ kết nối với một phiên khác nhau thông qua máy chủ WebSocket. Trong máy chủ từ xa, có 2 cách để thực hiện: (1) mỗi phiên tạo kết nối websocket riêng (2) tất cả các phiên sẽ sử dụng cùng một kết nối websocket.

Từ quan điểm kết nối, tôi thích giải pháp chia sẻ (một kết nối websocket cho tất cả các phiên), vì máy chủ websocket bị giới hạn bởi #of kết nối có sẵn (lưu máy chủ/nhân rộng). Tuy nhiên, từ lưu lượng truy cập/tốc độ dữ liệu/điểm thực hiện, nếu một phiên sẽ gửi rất nhiều gói nhỏ thông qua kết nối, thì nếu chúng ta sử dụng một kết nối chia sẻ, chúng ta sẽ không thể sử dụng băng thông (tải trọng.). .../thu gom vài gói nhỏ thành một hoặc chia gói lớn thành gói nhỏ), bởi vì chúng tôi có thể gửi các gói khác nhau cho các khách hàng khác nhau từ các phiên khác nhau, trong trường hợp này, chúng tôi sẽ không thu được vài gói (gói nhỏ vì chúng có đích đến khác nhau và từ các nguồn khác nhau !!, trừ khi chúng ta sẽ tạo "kết nối ảo" để quản lý từng dữ liệu phiên để tối đa hóa tốc độ, nhưng điều này sẽ tạo ra nhiều phức tạp thực hiện !!!

Có ý kiến ​​nào khác không?

Cảm ơn, JB.

Answer 1

Tôi nghĩ bạn nên cân nhắc việc sử dụng một nhóm kết nối có giới hạn, giống như chúng làm với kiến ​​trúc kết nối cơ sở dữ liệu.

Một giải pháp khác mà tôi sẽ xem xét là trung gian cơ sở dữ liệu Pub/Sub như Redis. Điều này cho phép bạn sử dụng các giải pháp hiện có cũng như khả năng mở rộng dễ dàng hơn.

Với sự hiểu biết tốt nhất của tôi, cả hai đều có một kết nối duy nhất và sử dụng vô số các kết nối đều có vấn đề.

Ví dụ: một kết nối chỉ có thể gửi một tin nhắn mỗi lần. Một thông điệp đủ lớn có thể chặn kết nối ... bạn có đang di chuyển dữ liệu lớn không?

Nhiều kết nối có thể gây ra phí tổn có thể rất tốn kém cũng như mang lại nhiều cơ hội hơn cho các lỗi. Hãy xem xét những điều sau đây:

1. Tạo kết nối mới là rất tốn kém, sử dụng băng thông, bị chậm trễ mạng lâu hơn và đòi hỏi phải có nguồn lực địa phương và điều này là chính xác những gì WebSockets cho phép chúng ta tránh.

2. Bạn sẽ gặp phải sự cố về khả năng mở rộng. Ví dụ, Heroku giới hạn các kết nối websocket đến 600 cho mỗi máy chủ, hoặc ít nhất họ đã làm như vậy một thời gian ngắn (và tôi nghĩ nó hợp lý) ... Làm thế nào bạn sẽ kết nối tất cả các máy chủ với nhau để lưu trữ dữ liệu?

3. Hãy nhớ rằng mọi hệ điều hành đều có giới hạn tệp mở và ổ cắm web sử dụng kiến ​​trúc IO (mỗi tệp là 'tệp mở', để các ổ cắm web là tài nguyên hạn chế).

Về lưu lượng/tốc độ dữ liệu/hiệu suất, đây là câu hỏi về kiến ​​trúc máy chủ ... nhưng tôi tin rằng bạn sẽ thấy tăng tốc nhẹ bằng cách sử dụng một kết nối (hoặc một nhóm nhỏ kết nối). Điều quan trọng cần nhớ là không có bất kỳ tác vụ đa tác vụ nào hiệu quả khi bạn cần gửi các gói TCP/IP.

Ngoài ra, với số lượng kết nối hạn chế (ngay cả với một kết nối), bạn sẽ có thể hưởng lợi từ tính năng nối gói của hệ điều hành, cho phép bạn gửi một số khung websocket trên một gói TCP/IP (trừ khi bạn liên tục tuôn ra ổ cắm TCP/IP). Bạn sẽ thực sự lãng phí băng thông nhiều hơn với nhiều kết nối hơn - thậm chí bỏ qua băng thông được sử dụng để mở mỗi kết nối mới.

Chỉ 5 xu của tôi, tất cả chúng ta sẽ nghĩ khác nhau, tôi chắc chắn.

Chúc may mắn!