AT

2.После нового года решили опробовать socket.io -- понравилось то что он сразу в себе реализовывает и вебсокеты и long-polling, в один поток собрали решение без проблем.
Началось интересное когда пытались распараллеливать
пока решение не нашли, натыкались на людей с такими же проблемами , они использовали Reddis -- пока не очень хочется ставить его.
adamnengland.wordpress.com/2013/01/30/node-js-clus...

1.Раскидывали через cluster http сервер (свой long-polling, socket.io не использовали) на несколько потоков по количеству ядер в системе . Также была необходимость хранить данные в головном потоке и там их обрабатывать при необходимости. Cluster предоставляет возможность осуществлять связь между дочерними потоками и головным, делается эта следующим образом:
В головном потоке (master) устанавливаем событие message - которое ждет сообщения от дочерних потоков
всю логику разбиваем на 2 файла server.js (Master) и worker.js

var config = {
    numWorkers: require('os').cpus().length,
    refreshTime: 1000, // Milliseconds between data refreshes.
    waitTime: 90, //Время в секундах когда пользователь считается оффлайн
    worker: {
        port: XXXX,
        setNoDelay: true,
        mongoUrl: 'mongodb://XXX:XXXXXXXX@/tmp/mongodb-270XX.sock'
    }
};

тут храним натсройки, так удобней чтобы потом не рыться в коде елси нужно поправить

cluster.setupMaster({
    exec: "worker.js"      
});

говорим кластеру в каких файлах исполняемый код воркеров

for (var i = 0; i < config.numWorkers; i++)
    (function(worker) {
        worker.on('message', function(data) {
			switch(data.routeType){   // мы  в сообщениях преедавали  массив , routeType  -  переменная масисива которую мы ввели и в нашем случае она  обозначала какоето действие
                case 'act1':
                    //  Что то делаем, выполняем какойто код   массив  data  может  содержать еще какието элементы котоыре вы будете обрабатывать
                    break;
                case 'act1':
						// Второе действие
                    break;
				default:
					break;
			}
        });

        worker.on('exit', function(code, signal) {
            console.log('Worker died: ', worker.process.pid, code, signal);  //  Сообщаем в консоль что у нас подох один из потоков
        });
    })(cluster.fork({WORKER_CONFIG: JSON.stringify(config.worker)}));  //  Форкаем  потоки

worker.js -- код в потоках
var config = JSON.parse(process.env.WORKER_CONFIG || "{}"); -- таким образом можно получить в дочернем потоке какието насторйки из голвного

process.on('message', function(data){   // получаем сообщение от  головного потока 
		switch(data.routeType){
			case 'myMess1': 
				// Выполняем свой код
            break;
            case 'myMess2':
						// Второе действие
            break;
			default:
			break;
			}
}

отправляем сообщение в головной

var procMess = {
	routeType: 'myMess',
//..........  любые ваши данные которые нужно передать
};

process.send(procMess);	    // Отправка данных  в головной поток

Советую собрать у себя этот пример habrahabr.ru/post/123154 чтобы наглядно посмотреть как передаются сообщения из головного потока в воркеры и обратно.
Мы первую версию своего движка собрали по похожем принципу и тестировали под высокими нагрузками - проблем не было.

И эти данные (достаточно сложные js-объекты) нельзя поместить в БД

noSQL же. MongoDB например так и хранит все в виде JS-объектов.
Можете попробовать так же in-memory решение, например Redis.
БД в вашем случае потом при необходимости тоже можно будет расшардить для улучшения производительности.