máy chủ đẩy cho hàng triệu kết nối đồng thời

Question

Tôi đang xây dựng một hệ thống phân tán bao gồm hàng triệu khách hàng, tất cả cần phải giữ kết nối mở (mong muốn HTTP) để chờ lệnh từ máy chủ (đang chạy ở nơi khác) . Tải tin nhắn/commmands sẽ không được rất cao, có thể một tin nhắn/giây/1000 khách hàng có nghĩa là nó sẽ là 1000 msg/sec @ 1 triệu khách hàng. => về cơ bản nó là về các kết nối đồng thời.

Các yêu cầu cũng đơn giản. Một cách nhắn tin (máy chủ-> khách hàng), chỉ có 1 khách hàng cho mỗi "kênh".

Tôi khá cởi mở về mặt công nghệ (xmpp/websockets/comet/...). Tôi đang sử dụng Google App Engine làm máy chủ nhưng "kênh" của họ sẽ không hoạt động đối với tôi một cách không may (hạn ngạch quá thấp và không có ứng dụng khách Java). XMPP là một lựa chọn nhưng khá đắt. Cho đến nay tôi đã sử dụng URL Fetch & pubnub, nhưng họ chỉ bắt đầu tính phí cho các kết nối (thời gian lớn).

Vì vậy:

1. Có ai biết của một dịch vụ trên mạng có thể làm điều đó cho tôi trong một cách hợp lý? Hầu hết tôi đã tìm thấy giới hạn hoặc phí rất nhiều cho các kết nối.

2. Bất kỳ trải nghiệm nào khi tự mình triển khai máy chủ như vậy? Tôi đã thực sự làm điều đó và nó hoạt động khá tốt (dựa trên Tomcat & NIO) nhưng tôi chưa có thời gian để thực sự thiết lập một môi trường kiểm tra tải lớn (một phần vì đây vẫn là một giải pháp dự phòng, tôi thích một máy chủ msg đã được khắc phục sự cố). Bất kỳ trải nghiệm nào về số lượng người dùng bạn nhận được trên mỗi GB? Bất kỳ giới hạn cứng?

Kiến trúc của tôi cũng cho phép chia nhỏ các máy chủ msg, nhưng tôi muốn tối đa hóa các kết nối đồng thời vì xử lý thông tin trên CPU ở mức tối thiểu.

Answer 1

Trong khi đó, tôi đã triển khai máy chủ thư của riêng mình bằng cách sử dụng netty.io. Netty sử dụng Java NIO và quy mô rất tốt. Đối với các kết nối không hoạt động, tôi nhận được dung lượng bộ nhớ 500 byte cho mỗi kết nối. Tôi đang thực hiện chỉ chuyển tiếp tin nhắn rất đơn giản (không có bộ nhớ đệm, lưu trữ hoặc các công cụ ưa thích khác) nhưng với điều đó dễ dàng nhận được 1000 - 1500 msg/giây (mỗi nửa KB) trên cá thể amazon nhỏ (1ECU/1.6GB).

Nếu không, bạn có thể giới thiệu spire.io (họ không tính phí cho kết nối nhưng có giá cao hơn cho mỗi tin nhắn) hoặc pubnub (họ tính phí cho kết nối nhưng rẻ hơn cho mỗi tin nhắn).

Answer 2

Bạn phải tìm hiểu thêm về kiến ​​trúc tạo môi trường như vậy. Trước hết, nếu bạn sẽ tự viết quản lý ổ cắm, thì đừng sử dụng Thread per Client Socket. Sử dụng các phương thức không đồng bộ để nhận và gửi dữ liệu. WebSockets có thể quá nặng nếu thư của bạn nhỏ. Bởi vì nó thực hiện khung, mà phải được áp dụng cho mỗi thông điệp cho mỗi socket riêng lẻ (bộ nhớ đệm có thể được sử dụng cho các phiên bản khác nhau của giao thức WebSockets), làm cho chúng chậm hơn để xử lý cả hai hướng: để nhận và gửi, đặc biệt là vì mặt nạ dữ liệu .

Có thể tạo hàng triệu ổ cắm, nhưng chỉ có hầu hết các công nghệ tiên tiến có khả năng làm như vậy. Erlang có thể xử lý hàng triệu kết nối và có khả năng mở rộng. Nếu bạn muốn có hàng triệu kết nối bằng cách sử dụng các công nghệ cấp cao hơn, thì bạn cần phải suy nghĩ về việc phân cụm những gì bạn đang cố gắng thực hiện.

Ví dụ: sử dụng máy chủ cổng sẽ theo dõi tất cả các máy chủ xử lý. Và có dữ liệu của chúng (IP, cổng, tải (nếu nó sẽ là một mạng nội bộ, tường lửa và cổng chuyển tiếp có thể có ích tại đây) Phần mềm máy khách kết nối với máy chủ cổng đó, máy chủ cổng sẽ kiểm tra máy chủ được tải ít nhất và gửi ip và Khách hàng tạo kết nối trực tiếp đến máy chủ đang hoạt động bằng cách sử dụng địa chỉ được cung cấp Bằng cách đó bạn sẽ có cổng cũng có thể xử lý ủy quyền và không giữ kết nối lâu, vì vậy một trong số đó có thể là đủ.

Điều này rất liên quan đến nhu cầu của bạn và có thể không phù hợp với các giải pháp của bạn.