[Hỏi] Scale NodeJS server dùng cho on-demand services ?



  • Hiện tại mình đang làm 1 startup project dạng on-demand service như Uber: khi có user request (1 request = 20s) thì mình sẽ phải tìm user khác thích hợp để match với user đó, khi match rồi thì mới return response về.

    Hiện tại cách mình làm là dùng long-polling với EventEmitter! Mình có 2 API: Request API và Accept API! Khi Request API được gọi thì mình sẽ giữ request đó và listen 1 event tương ứng, khi nhận được event thì mới response về ! Khi có 1 user nào đó gọi Accept API thì mình sẽ match với 1 request bất kỳ rồi sẽ emit event phù hợp request đó. Nhưng hiện tại mình đang không biết cách đó có tối ưu hay ko, vì mình cần build server support khoảng 100k user cùng lúc! Các bạn có kinh nghiệm mong chỉ giúp. Cảm ơn



  • Hi Luân,
    Mình chưa dùng long-polling, nhưng mình nghĩ client là app mobile thì có thể dùng push notification, khi có Request API về server thì đưa request(kèm devicetoken) này vào 1 queue, khi có Accept API thì vào queue trên lấy ra request phù hợp và dựa vào devicetoken để push về device tương ứng. Mình chỉ chia sẽ theo quan điểm cá nhân, ko biết có phù hợp với bạn ko :)

    NHAN NGUYEN

    0


  • Hi bạn @nguyenquynhan , cảm ơn ý kiến của bạn :) Mình cũng từng làm cách như bạn r, chỉ khác là vì mình trả về dùng websocket chứ ko dùng push thôi :) Cách đó mình thấy ok, không phải giữ connection quá nhiều trên server, nhưng do leader bên mình làm bên iOS không thích cách đó, chỉ muốn request và nhận response đều bằng API hết, vậy mới mệt :smiley:



  • Vậy làm theo teamlead đi bạn, dù sao teamlead có kinh nghiệm hơn và là người quyết định, nhưng bạn nhớ hỏi teamlead đưa ra những compare giữa 2 cách và tại sao chọn cách đó :)

    NHAN NGUYEN

    0


  • Hi okay, thanks bạn :) Để mình xem và test thử xem handle được bao nhiêu



  • @Luân Nguyễn : giữ request của bạn ở đây là thế nào ?. Nếu vẫn duy trì kết nối thì hệ thống chạy nặng lắm . Ý tưởng của cái này thì cũng shortpolling cho lành :| . Khi người dùng request lên bạn tạo cho họ 1 cái kênh. Cứ 3 giây lại bắn 1 request lên tiếp xem cái kênh đó có tin mới chưa( nếu có tin rồi thì đóng kênh đó lại ) . Khả năng mở rộng dễ dàng hơn nhiều :D



  • Mình cũng từng làm cách như bạn r, chỉ khác là vì mình trả về dùng websocket chứ ko dùng push thôi :) Cách đó mình thấy ok, không phải giữ connection quá nhiều trên server, nhưng do leader bên mình làm bên iOS không thích cách đó, chỉ muốn request và nhận response đều bằng API hết, vậy mới mệt :smiley:

    Mình nghĩ vấn đề thực sự nằm ở trưởng nhóm của bạn.

    Long Polling không phải là một công nghệ mới. Nó thực chất chỉ là một giải pháp không chính thống (hacky solution) để giải quyết vấn đề giao tiếp 2 chiều (bidirectional communication) do HTTP chỉ có thể giao tiếp 1 chiều. Long Polling AJAX khởi tạo kết nối HTTP và giữ kết nối tồn tại trong một khoảng thời gian để chờ phản hồi. Chính vì lẽ đó mà việc xử lý bằng Long Polling thường tốn CPU, độ trễ cao (high latency), phức tạp và kém trong việc xử lý nhiều client (scaling).

    WebSocket được thiết kế để xử lý thời gian thực (realtime) và thay thế các giải pháp giao tiếp 2 chiều không chính thống hiện tại, trong đó có Long Polling. Khi thực hiện một kết nối bằng giao thức HTTP, các dữ liệu như headers, cookies và các dữ liệu khởi tạo khác, được gửi kèm ở mỗi kết nối. Trong khi đó, WebSocket được xây dựng trên nền tảng giao thức TCP và chỉ thực hiện khởi tạo kết nối một lần duy nhất trong một phiên sử dụng. Điều này giúp WebSocket giảm tối đa độ trễ do khởi tạo kết nối (latency) và loại bỏ hầu hết các dữ liệu HTTP không cần thiết. Ngoài ra, với WebSocket, sau khi kết nối được khởi tạo thành công, client hoặc server có thể gửi phản hồi ở bất cứ một thời điểm nào mà không cần phải chờ đợi tín hiệu từ bên còn lại. Khả năng này mang lại sự vượt trội cho WebSocket so với Long Polling ở cả việc giảm độ trễ của phản hồi lẫn CPU cycle cần thiết. Hơn nữa, ở thời điểm hiện tại, WebSocket là giải pháp tốt nhất để xử lý một lượng lớn client.

    Để kết luận, mình khẳng định là không có lí do gì để sử dụng Long Polling thay cho WebSocket.

    Bạn có thể tham khảo thêm ở các đường link chính thức dưới đây:
    [1] http://www.websocket.org/quantum.html
    [2] http://stackoverflow.com/questions/10028770/html5-websocket-vs-long-polling-vs-ajax-vs-webrtc-vs-server-sent-events
    [3] http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet



  • @Quốc-Cường Cảm ơn bạn! Đúng như bạn nói, duy trì kết nối thì mình test khoảng 1000 concurrent request thì server ko handle nổi! Nên mình nghĩ sẽ thuyết phục leader dùng WebSocket :)



  • @tresdin Cảm ơn bạn! Um ban đầu mình dùng Websocket vì mình cũng nghĩ kiểu long-polling không phù hợp với production, không scale up được với nhiều client. Và giờ thì mình chắc chắn là chỉ dùng Websocket là best solution thôi :)


Log in to reply