使用Redis商店擴展Engine.IO（與Socket.IO對比）

Question

關於這個主題有幾個問題，但沒有一個問題可以解決。

我正在使用帶有redis-store的Socket.IO，而我正在為流量增加做准備。 我的托管公司說，“你需要使用Engine.IO而不是Socket.IO，因為它的效率更高”，所以我很想弄明白這意味着什么。

像這樣的問題似乎有相互矛盾的答案：

• Socket.IO構建於Engine.IO之上
• Engine.IO增強了Socket.IO降級的地方
• Socket.IO 1.0將是第一個在Engine.IO上運行的版本

所以我看待它的方式：

• Socket.IO 0.9降級
• Engine.IO增強了
• Socket.IO 1.0將使用Engine.IO
• 如果要在多個實例上運行Engine.IO，則必須自己編寫redis存儲

但隨后Engine.IO稱其“負載平衡器友好”，但對redis一無所知。 它必須有某種外店，對吧？ 但如果它有多個傳輸和商店，那么Socket.IO有什么意義呢？

然后我看到Socket.IO 可能會被拋棄，而知名公司也會轉向 Primus 。

如何擴展Engine.IO？ 我自己要寫店嗎？

Answer 1

只是想分享我上周學到的東西，但希望其他人出現並明確回答這個問題，這樣我就可以給他們一張支票。

1）永遠不要使用Socket.IO（截至0.9.16）

我的主人告訴我使用Engine.IO（或其他任何東西）是正確的。 Socket.IO有很多重大問題，最糟糕的是它會意外地DDoS你的服務器 。 我親身體驗過這個客戶端相對較少，它完全禁用了我的服務器，直到我可以重寫Socket.IO。 我縮放到25+無人機以吸收這一擊，這無所謂。 單個客戶端每秒可以發送1000個請求。

2）其他發動機沒有Redis商店

Socket.IO允許您通過放入Redis商店來跨節點進行廣播。 據我所知，Engine.IO，Primus和SockJS不提供此功能。 因此，當這些引擎聲稱“負載均衡器”友好時，並不意味着您可以跨節點進行廣播。 我開始認為這實際上是一件好事。 使用redis編寫pub / sub相對容易，並且將它分離出來一直很好。

我最終使用Primus和Engine.IO ，然后使用redis pub / sub在節點之間共享事件。 我花了大約5個小時來刪除Socket.IO，連接Primus，寫下pub / sub，然后上線。 到目前為止，這是一次更好的體驗。

更新：

結束Engine.IO也進入重新連接循環（每秒幾次），所以我最終使用了SockJS。 它給了我最好的連接性和穩定性， Primus現在處理重新連接 （SockJS沒有做到）。

Answer 2

我同意應該避免使用Socket.IO直到v1.0發布，這是錯誤的，在我的測試中，Engine.IO表現得更好（ https://medium.com/node-js-javascript/b63bfca0539 ）。 Primus絕對是一個不錯的選擇：也許你現在會使用Engine.IO但是當你發布Socket.IO 1.0時你會想要切換到它。

我用Engine.IO和Redis以及Pub / Sub結構實現了一個類似的程序，它看起來非常優雅。 以下代碼將連接的客戶端訂閱到房間/頻道。

io.on('connection', function (socket) {
  var observerRedisClient = redis.createClient();
  observerRedisClient.subscribe(resourceId, redis.print);

  observerRedisClient.on('message', function(channel, message) {
      socket.send(message);
  });
});

如果您更新該頻道，即。 保存一些數據並發布，然后所有訂閱的客戶端都將收到它。

redisClient.set(key, value, redis.print);
redisClient.publish(key, value);

如果您有興趣，代碼是開源的： https ： //github.com/denizozger/node-engine.io-server

Answer 3

好吧，正如你自己提到的，我應該看看Primus。 使用HAProxy實現縮放。 作為底層通信，您仍然可以使用Socket.io，還可以使用engine.io。 通過使用Primus，您可以嘗試使用不同的庫。 有一篇關於在http://pusher.com/docs/server_libraries上擴展Redis的有趣文章。