socket.io與sticky-session, 多個socket.io執行個體帶來的問題

標籤：

websocket的出現使得從伺服器向瀏覽器推送資料更加容易。但是低版本的瀏覽器不支援websocket，這時socket.io出現了。

使用socket.io的應用在支援websocket的瀏覽器啟動並執行時候使用websocket，而在低版本的瀏覽器中則使用傳統的方式與伺服器互動（例如long-polling及其他的方式）。

long-polling的應用實現方式是這樣的，用戶端向伺服器端發起請求，伺服器端不會馬上返回，而是保持這個串連直到伺服器需要推送資訊給用戶端時，才返回給用戶端資料。用戶端接收到資料以後會再次發送一個請求，如此迴圈。

socket.io支援使用long-polling的用戶端，這個特點使得我們的網站在低版本的瀏覽器也能運行，但是這會給socket.io伺服器端程式帶來一個問題。

比如我們需要用socket.io編寫一個聊天程式，每當有一個新的使用者時，建立一個新串連，伺服器在記憶體中儲存當前的所有串連。當需要給所有使用者廣播資訊的時候，我們遍曆所有的串連，給每個串連寫資料。類似於：

//示意代碼var clients = []; //所有的使用者server.on(‘broadcast‘, function(){     for client in clients {        writeData(client, ‘hi‘);   }});

現在我們來考慮一下writeData這個方法要怎麼實現，因為要支援使用long-polling的用戶端，long-polling是由多次請求組成的，所以在兩次請求之間用戶端和伺服器端沒有串連，假如這時需要推送資料到用戶端，我們需要在伺服器端把要推送的資料臨時存下來，等待用戶端發起請求的時候，再把資料發送到用戶端。伺服器端代碼類似：

var long_polling_clients = [];  function writeData(client, data){      long_polling_clients.push([client, data]);}server.on(‘request‘, function(){    //從long_polling_clients取得client  //發送資料到用戶端});

當伺服器端只有一台伺服器的時候，程式沒有問題，用戶端發送的每次請求都串連到同一台伺服器。

但是當伺服器端有多台伺服器時，程式就有可能出錯。

假如C1用戶端先串連到A伺服器，並且伺服器需要推送訊息到用戶端，這個伺服器的會把要發送的訊息和對應的用戶端儲存起來，等待用戶端請求。

//A伺服器var long_polling_clients = [[用戶端1, 訊息]];  

下一次用戶端請求串連到了B伺服器，B伺服器並沒有向C1用戶端推送訊息，因此B伺服器的記憶體中沒有記錄C1用戶端，所以不會向C1用戶端寫資料，這樣程式就出錯了。

//B伺服器var long_polling_clients = []  

為瞭解決這個問題，最簡單的辦法是每次用戶端串連伺服器的時候都連同一台伺服器，這可以使用nginx這樣的工具來實現。

但是有時為了利用多核，我們會在伺服器上運行多個socket.io執行個體，每個執行個體都有自己的記憶體空間。這時候怎麼辦呢？我們需要用到sticky-session這個庫。

這個庫調用cluster建立了多個socket.io執行個體，並且總是把相同ip的請求發送到同一個socket.io執行個體。

當然我們可以選擇不把[用戶端，訊息]儲存在記憶體中，而是用其他儲存方式儲存例如redis，這樣多台伺服器，多個socket.io執行個體都可以共用資料。

 

原文連結: http://suyuan.me/socket-ioyu-sticky-session/

socket.io與sticky-session, 多個socket.io執行個體帶來的問題