Тимур Шемсединов

Передача хендлов сокетов в дочерние процессы тут находится во встроенной библиотеке cluster и скрыта от разработчика. Так же все процессы пишут и читают из редиса (см в коде вызовы incr/decr, zrem/zadd). Процессы подписываются на редисовские каналы (см в коде conn.on('message'...) и conn.on('subscribe'...) ). Код в этом репозитории уже три года не изменялся, масштабирование только на несколько процессов на одной машине, ничего уникального не написано, весь этот функционал сидит в редисе, будет тратиться много ресурсов, чтобы обеспечить межпроцессовое взаимодействие ноды с ним, даже не интересно смотреть эту реализацию. Это устаревший хлам, за три года нода уже изменилась, а как изменилась инфраструктура и возможности дополнительных пакетов...

Ничего сложного в этом нет, вот только рекомендую переместить переменные, или скорее это константы в /init/constants.js, а то ведь на /server/requests.js они каждый раз создаются и теряются. Например так:

application.constants = {
  'domain1.com': { field1: "value1", ... }
  'domain2.net': { field1: "value1", ... },
    ...
};

А в /server/requests.js их можно будет просто возвращать в зависимости от домена сайта:

module.exports = function(client, callback) {
  client.cache('10m');  // кешируем на 10 минут
  // отдаем нужный набр переменных для сайта
  callback(application.constants[client.host]);
};

Ну и в /config/hosts.js настраиваем все на одно приложение:
module.exports = [ '*' ];

Нет. Вам же нужно их обрабатывать, они же открытые TCP сокеты, в какую базу? У каждого сокета есть идентификатор и кусок памяти свой выделен на уровне операционной системы под буфер. Кроме того, из каждого сокета что-то приходит, и в него нужно что-то слать, это что тоже через базу делать? Похоже на то, что Вам нужно почитать про TCP/IP, про сокеты и про сетевое программирование хоть несколько статей, хоть бы на Хабре может. И Вам нужен cluster, чтобы распределить эти сокеты на несколько процессов, чтобы у одного действительно память не кончилась и чтобы занять другие ядра проца.

Кроме того, обратите внимание, что TCP - это не пакетно ориентированный протокол, а потоковый, т.е. если отправить 10кб данных одним разом, то они могут прийти одним разом, а могут подробиться как угодно, прийти за 4 раза, например, 1кб+3кб+4кб+2кб. Так же и склеиваться могут, если отправить подряд 5 фрагментов, то они могут склеиться в один. Более того, от одной посылки может отклеиться небольшая часть и приклеиться к следующей. Все, что TCP гарантирует, это то, что данные придут точно и в правильной последовательности.

Проблема в том, что Вы не проверяете, живо ли соединение, перед тем, как послать в него данные. Для нахождения проблемы не хватает глубины вывода стека, добавьте ключик при запуске ноды node --stack-trace-limit=1000 application.js и там будет видно и из какого места Вашего кода это вызывается. Нужно ловить ws.on('close', fn) и ws.on('error', fn) и удалять эти сокеты из множества, по которому Вы проходитесь в цикле и рассылаете, дополнительно можно и проверку поставить типа if (connection.readyState === WebSocket.OPEN) ...

Вообще всю жизнь так работало:

res.writeHead(200, {
  'Content-Type': 'text/event-stream; charset=UTF-8',
  'Cache-Control': 'no-cache',
  'Connection': 'keep-alive',
  'Access-Control-Allow-Credentials': true,
  'Access-Control-Allow-Origin': '*'
});

Но если не работает, то сделайте параметр в урле SSE обработчика https://[url-server]:8081/event?domain=[uri-client] и подставляйте не *, а для каждого свой свой домен.
Кроме того, постарайтесь вешать не на 8081, а все на 80, браузеры, фаерволы и разные шлюзы любят когда все на 80. Да и балансировку тогда будет сделать проще, хардварные балансировщики и специализированные сервисы балансировки любят 80.

Это тыбзинг контента называется, а культурно по-буржуйски кравлинг. Делать это можно при помощи HTTP запросов родной нодовской библиотекой http, или при помощи npm библиотеки request. Полученные страницы нужно парсисть и сохранять в нужном формате в БД. Для парсинга подойдут или регулярные выражения или библиотека типа cheerio Если это товары с четкой структурой, то логичнее использовать PostgreSQL, а если товары очень разные, то можно в документную базу их писать с произвольным набором полей, например, в MongoDB.

Не правильно понимаете. Если функции loadSettings и другие асинхронные, а они конечно асинхронные по своему смыслу, ведь это внешние запросы из базы или с веника, то писать нужно примерно так:

async.parallel([
    function (callback) {
        App.loadSettings(callback);
    },
    function (callback) {
        App.loadData(callback);
    },
    function(callback) {
        App.loadData2(callback);
    },
]);

И когда они завершаются, они должны уведомлять async вызовом этого самого callback

Вы уже сами почти все написали, только в Access-Control-Allow-Headers не добавили origin. Нужно:

res.setHeader('Access-Control-Allow-Origin', '*');
res.setHeader('Access-Control-Allow-Headers', 'origin, content-type, accept');

Но проблема может быть еще и не в этом, если Вы пробуете делать это локально и обращаетесь к localhost, то вот оно и не будет работать, эти заголовки будут игнорироваться браузером. Используйте локальный IP вместо localhost пишите 127.0.0.1

Добавьте параметр в selectDB(param1, callback) и вызывайте его вместо return results. Потом в этот самый новый параметр передавайте функцию, которая должна получать результат и она будет его получать в виде параметра. Рекомендуется делать не просто callback(results), а пробрасывать ошибку наверх, чтобы ее можно было обработать: callback(err, results). Тогда вызов будет выглядеть:

selectDB(param1, function(err, result) { /* тут будут доступны выбранные данные в result */ });

Кстати, может вот такая библиотека упростит Вам жизнь: https://www.npmjs.com/package/mysql-utilities
Статья по ней: habrahabr.ru/post/198738