Параллелизм и Node.js?

Question

[EpicUsaMan]

Каждый процесс имеет кэш данных из базы о пользователях (Почему? Набор данных о пользователе содержит целое море статистики, которую в реалтайме считать очень невыгодно и не продуктивно с точки зрения написания кода)

Таким образом worker-ы и master должны синхронизировать данные между собой.
Они это делают между собой посредством метода update, который передает данные в master, сравнивает их используя timestamp для строк и разницу для числового типа и вносит измененные данные в базу, после чего рассылает объединенный обьект другим worker-ам.

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

Плюс, какие подводные камни можно словить с таким подходом.

Answer 1

[index0h]

Жуть какая. Ваш сервис будет деградировать с повышением нагрузки И повышением количества воркеров.

А теперь вопрос, как быть с массивами?

Наверное заюзать мютексы, которых нет.

Нода - это однопоточная штука, не надо эмулировать многопоточность. Вам же это еще и поддерживать.

Вполне нормальный кейс:
Кэш хранить в Redis, или чем-то типа того, ну а сервисы на ноде уже stateless.
Да, в такой схеме вы потеряете на издержках сети, зато получите простоту в горизонтальном масштабировании.

з.ы. посмотрите в сторону golang

Comments

[Михаил]

Для мьютексов есть либа. Да и для многопоточности есть napa.js

[index0h]

Михаил как решить задачу инструментом, который для него не подходит? Правильно, менять инструмент))

[EpicUsaMan]

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

Но там не менее. Переписывать на Go опять же таки то, что работает, а тем более в целом на незнакомый мне язык. Ну вряд ли разумное решение.

Node.js хорошо работает параллельно, не считая socket.io.

Да и в целом, вон там завезли SharedArrayBuffer и Atomics.