socket.io scaling out solution socket.io 一直以來都是在 node.js 許多 module 當中,受人注目的一個項目,自己也不例外,從 socket.io 6 進展到目前 socket.io 9 都一直持續關注他的發展。 長期以來這種 Comet 連線模式的環境,最讓人質疑的部份有幾個, server extend (scaling issue) message lost *. user connection 首先拿 server exetend 來說,最簡單的解法,同時也是 socket.io 支援的模式, 設定 socket.io redis config 使用 load balancer like 的機制 將 socket.io 服務視為一個 Application 因此就可以如下圖,所表示 http://blog.davidmisshula.com/images/4.png 使用者透過連線到 load balancer 之後,透過 load balaner 將資源分散到每個不同的 Application 機器,每個機器最終將會去向同一個 DB (SQL/ NoSql) 機器取得 session, user, message … 資訊回到應用程式當中。 讓每個使用者的資訊不致於斷線,在這邊 socket.io 預設的使用方式就是採用 redis。 這種連線方式其實有幾篇文章已經說明的相當清楚, http://blog.cloudfoundry.com/2013/01/24/scaling-real-time-apps-on-cloud-foundry-using-node-js-and-redis/ http://blog.davidmisshula.com/blog/2013/02/04/configure-haproxy-to-scale-multiple-nodes-with-stickiness-and-ssl/ 這邊的方式都是採用如同上述表示的規劃架構,可以達到 socket.io scaling 的機制。 當然聰明的各位也想到了,有需求就會有解決方案,因此也有廠商提供了類似的解決方案, https://www.firebase.com/ ht...
熱血,是一輩子的事! Answer is there, dig it.