Thứ nhất, sơ đồ của bạn giả định rằng các cân bằng tải là hành động như một (TCP) Proxy, mà không phải là luôn luôn như vậy. Thường trực tiếp định tuyến (hoặc Direct Server Return) được sử dụng, hoặc đích NAT được thực hiện. Trong cả hai trường hợp, kết nối giữa máy chủ phụ trợ và máy khách là trực tiếp. Vì vậy, trong trường hợp này về cơ bản nó là bắt tay TCP được phân phối giữa các máy chủ phụ trợ. Xem sau để biết thêm:
Rõ ràng TCP proxy vẫn tồn tại (HAProxy là một), trong trường hợp proxy quản lý cả hai mặt của connecton, vì vậy ứng dụng của bạn sẽ cần để có thể xác định khách hàng bằng IP/Port đến (mà sẽ xảy ra được từ proxy chứ không phải là khách hàng). Proxy sẽ xử lý việc nhận lại tin nhắn cho khách hàng. Dù bằng cách nào, nó đi xuống để thiết kế ứng dụng như tôi sẽ tưởng tượng bit khó có một cửa hàng phiên chung (một cơ sở dữ liệu của một số loại, hoặc key => giá trị lưu trữ như Redis), để khi máy chủ ứng dụng của bạn nói "Tôi cần phải gửi một tin nhắn đến Frank" nó có thể xác định máy chủ phụ trợ Frank được kết nối với (từ DB), và báo hiệu rằng máy chủ để gửi tin nhắn. Bạn làm giảm vấn đề kết nối (từ cùng một máy khách) di chuyển xung quanh các máy chủ phụ trợ khác nhau bằng các kết nối liên tục (tất cả các bộ cân bằng tải có thể làm điều này), hoặc bằng cách sử dụng một cái gì đó thực sự tồn tại như một websocket.
Đây có thể là sự đơn giản hóa quá mức vì tôi không có kinh nghiệm với phần mềm trò chuyện. Rõ ràng các máy chủ DB có thể được phân phối giữa một số máy, cho khả năng chịu lỗi và cân bằng tải.
Nguồn
2012-01-19 11:21:06
Cân bằng tải trong bố cục song song như bạn trình bày nó có một số vấn đề khi bạn nhận thấy. Lấy IRC thay cho một ví dụ, trong đó có một bố trí cây (điều này hỗ trợ đồng bộ hóa và đơn giản hóa việc gửi tin nhắn cho tất cả mọi người), và khối lượng dữ liệu đi qua cây không phải là tất cả những gì nhiều, theo e.g. freenode ops, mặc dù gần 80 nghìn người dùng của họ. –