Al

socket.io/docs/using-multiple-nodes

1. Задачи по времени нельзя запускать в мастере, если они свалятся, то свалится все, лучше запусать задачи в воркерах
2. Очень не рекомендую использовать библиотеку cluster, это один их худших кусков кода ноды, используйте child_process вместо cluster
3. Из воркера, который делает задачи по времени, информацию можно отправлять в мастер, а другие воркеры могут ее забирать, для этого есть IPC:
3.1. Для отправки сообщений из мастера в воркеры: https://nodejs.org/api/child_process.html#child_pr...
3.2. Для отправки воркеров в мастер: https://nodejs.org/api/process.html#process_proces...
4. Вместо IPC рекомендую использовать TCP сокеты, но если задача не требует больших нагрузок, то и IPC сгодится, он проще

тогда нужно заводить отдельный сторедж для соединений и добавлять их туда при каждом подключении. а связывать крон-джобу с express-сервером нужно через какой-то интерфейс. мне в голову приходит RabbitMQ

Здесь проблема в том, что для всех процессов свои глобальные переменные, а нужно их как-то обобщить, если один процесс что-то изменяет в глобальных переменных - то это изменение должно продублироваться для всех процессов.

Горизонтальное масштабирование в первую очередь предполагает возможность развернуть приложение на N количестве физически удаленных компьютеров. Соответственно вы не можете изменить что-то локально таким образом чтобы при этом оно продублировалось для всех процессов на всех удаленных машинах. Увы, но магии не существует. Чтобы это было возможным, требуется реализовать какой-нибудь механизм межпроцессного взаимодействия. Один из них вы уже назвали - использовать для этих целей redis.

Но ваша проблема в другом. В архитектуре. Её нет. Код выше - это спагетти-код. Поэтому вы думаете, что вам нужно это

если один процесс что-то изменяет в глобальных переменных - то это изменение должно продублироваться

В действительности если заняться рефакторингом кода, очень скоро может выясниться, что вам это было не так уж и нужно да и вроде как глобальные переменные были не особо нужны.

Вообще наличие большого количества глобальных переменных - это один из показателей плохого кода.

Вы можете продолжать городить костыли и накапливать технический долг сохраняя глобальное состояние в redis или прокидывать данные из дочерних процессов в мастер-процесс и наоборот (благо в node.js есть для этого инструменты), но все же лучше начать что-то изучать из области архитектурных решений в вебе (и в javascript в частности) и смотреть код других крупных проектов и желательно не только в javascript.

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

привести на строне mysql?

SELECT * FROM offers WHERE `name` = CONVERT(123, char)

хотя если не ошибаюсь то MySQL при запросе
select * from table where uid=123
не выдаст ошибку, а найдет записи. Правда если у Вас записи будут вида "123", "123abcd", "456" то он вернет две записи и "123" и "123abcd",

Можно ли писать на TypeScript под NodeJS? Вопрос о том, хорошая ли это практика?

Да, да

Смогу ли я использовать без особых проблем пакеты из npm, либо какие-то сторонние скрипты/классы написанные на js?

Если разобраться, для чего нужны .d.ts-файлы и как использовать typings, то проблем не будет.

Плюсы:
- свежие фичи из спецификаций ES
- статическая типизация, а, следовательно, все плюсы, которые она даёт. если в двух словах: часть ошибок будет отлавливаться ещё до запуска и, соответственно, нужно меньше тестов
- хорошая поддержка языка всякими редакторами. IDE от Jetbrains лучше будут выдавать подсказки. И даже простые редакторы кода, например Atom, Sublime, VS Code начнут выдавать нормальные подсказки, переходить по определениям в коде, выдавать сигнатуру методов, и т.д.

Минусы:
- Нужно понять, как правильно подключать обычные js-библиотеки к проекту. В целом, это не сложно, но многие не осиливают.
- Типы "существуют" только в compile-time. На выходе обычный JS со всей его динамической природой. Если код написан плохо (например, часто используется тип any), то typescript не поможет.

А про отладку я уже говорил: с ней проблем нет. Просто нужно подключить вот эту штуку, и всё будет нормально. VS Code точно умеет подключаться к нодовскому (и хромовскому) дебагеру и будет прыгать по исходникам, а не по скомпилированной каше.

Попробуйте заюзать более низкоуровневую библиотеку, на которой базируется connect-multiparty. Там как-раз есть progress :)

https://github.com/andrewrk/node-multiparty

var form = new multiparty.Form();
form.on('progress', function(bytesReceived, bytesExpected) {
   socket.emit('received', (bytesReceived / bytesExpected).toFixed(2) * 100);
});

Можно так попробовать:

var foo(err){
   alert(err)
};
window.addEventListener('error', function (e) {
    var error = e.error;
   foo(error);
});