2013-03-19 29 views
19

Tôi đang làm việc trên một dự án với Node.js liên quan đến một máy chủ (để đơn giản, hãy tưởng tượng máy chủ này như một máy chủ trò chuyện phải chuyển tiếp tin nhắn từ một số máy khách đến các máy khách khác) . Tôi cần vì lý do QoS mà máy chủ này luôn có thể truy cập được, vì vậy tôi nghĩ sử dụng phân cụm để chia tải cân bằng giữa các máy chủ khác nhau (các máy vật lý khác nhau) và để chắc chắn rằng nếu máy chủ bị hỏng, máy chủ khác sẽ sẵn sàng phục vụ yêu cầu .Node.js Multi Server Clustering

Câu hỏi của tôi là: loại tiếp cận phân tán này có thể có trong Node.js không?

Tôi đã đọc về mô-đun "cụm", nhưng, từ những gì tôi hiểu, có vẻ như chỉ quy mô trên các bộ xử lý đa trên cùng một máy.

+0

Vui lòng gắn thẻ cẩn thận hơn. Đây không phải là [tag: cluster-analysis] (aka: clustering; một kỹ thuật khai thác dữ liệu). –

+0

Nhìn vào sharding trong MongoDB - https://docs.mongodb.com/manual/sharding/ bạn có thể phân phát theo vị trí hoặc bởi một số thuộc tính khác, múi giờ, nhóm xã hội hoặc phòng trò chuyện. –

Trả lời

29

Có thể thực hiện được.

Đây không phải là tài sản của NodeJS mà là kiến ​​trúc bạn thiết kế cho ứng dụng của bạn, điều này sẽ xác định xem bạn có thể làm điều đó hay không.

Vấn đề chính của bạn sẽ luôn là chia sẻ trạng thái trên các phiên bản của bạn, vì vậy bạn có 4 máy chủ trò chuyện ABCD và bạn có LoadBalancer L để truyền các kết nối trên 4 máy chủ, sau đó khi A tắt, và bạn kết nối lại tất cả Kết nối của A với các phiên bản còn lại, làm cách nào để đảm bảo rằng trạng thái của phòng chat giống nhau trên BC và D?

Một cách là để mã ứng dụng hoàn toàn không trạng thái và đẩy tất cả dữ liệu vào cơ sở dữ liệu bộ nhớ được phân phối, như mongoDb hoặc Redis. Bạn muốn cơ sở dữ liệu được phân phối trong trường hợp một trong các cá thể cơ sở dữ liệu đi xuống.

Bây giờ, vấn đề cuối cùng của bạn là LoadBalancer. Nếu điều đó đi xuống, toàn bộ hệ thống của bạn bị hỏng.

Vì vậy, để tạo một câu chuyện dài ngắn; Có, bạn có thể làm điều đó, nhưng bạn cần phải thực hiện một số quyết định khó khăn về nơi mà các điểm tiềm năng của bạn sẽ thất bại. Nếu bạn không muốn có một điểm thất bại nào, bạn sẽ cần một thiết lập phức tạp và tốn kém.

+0

cách khác để chia sẻ trạng thái giữa nhiều máy chủ là gì, nếu Redis trở thành nút cổ chai thì sao? –

+0

Nhìn vào sharding trong MongoDB - https://docs.mongodb.com/manual/sharding/ bạn có thể phân chia theo vị trí hoặc bởi một số thuộc tính khác, múi giờ, nhóm xã hội hoặc phòng trò chuyện. –

5

Đề xuất của tôi là bạn tận dụng các cụm độc lập để chia sẻ trạng thái. Nói cách khác, có một cụm API nơi các máy chủ không 'nói chuyện với nhau, nhưng thay vào đó chia sẻ một cá thể/cụm Redis chung và chia sẻ một cụm MongoDB chung. Điều này cho phép bạn chia sẻ phiên, biến và bạn có thể tận dụng khả năng pub/sub của Redis để tránh cần bất kỳ tin đồn nào trong cụm API của bạn.

Đối với Trò chuyện cụ thể, nếu bạn sử dụng Redis với Socket.IO làm ứng dụng khách, sau đó bất cứ khi nào bạn phát sóng tới sảnh, nó sẽ sử dụng redis đằng sau hậu trường để truyền phát thông điệp đó tới sảnh đó. máy chủ. Ngoài ra, điều này tạo ra một mức độ chịu lỗi khác như bất kỳ máy chủ nào có thể quản lý kết nối lại socket và socket.io sẽ tự động kết nối lại với cụm API nếu kết nối bị hỏng, tất cả trong khi vẫn duy trì trạng thái thông qua Redis.