xfg

subsetofmultiset Бегло посмотрел код. Видно сразу что имеется определенное представление о слоистой/чистой/луковой архитектуре, возможно даже читал что-то из книг Эванса/Вернона по DDD и PoEAA от Мартина Фаулера, ну или как минимум какие-то статьи базирующиеся на информации из этих книг.

Довольно толково сделано. Единственное это то, что доменные сущности без поведения получились, состояние - есть, поведения - нет. Например следовало пету добавить метод любить человека, туда поместить бизнес-правила и если они все соблюдаются то создавать и возвращать из этого метода объект LovesHumanRelation и тому подобное. А так получилась что называется анемичная модель.

Но это всё можно быстро рассказать такому кандидату, дать почитать соответствующие главы из книг и будет реально толковый специалист. С такими знаниями не то что джуны, даже те кто сеньорами себя мнят ничерта подобного не знают. Одни ифоделы приходят (if-else-if-else).

Я так понял, для техлида то что ты написал получилось слишком сложно. Он походу хотел чтобы ты написал всё используя подход transaction script и готово, как это делают кнопкодавы.

Для меня, человек который вас не нанял - кретин. Показать бы ему что к нам приходит на собеседования за 100к.

У вас на сервере должен быть запущен постоянно работающий процесс, чтобы обрабатывать входящие запросы от клиентов. На PHP как правило пишут скрипты, которые не висят постоянно в памяти, а выполняются и умирают раз за разом. В таких условиях нужен посредник в виде постоянно работающего процесса. Поэтому вы используете apache, nginx, etc или пользуетесь встроенным php -S localhost:8080 mysite/index.php

В node.js можно несколько иначе. Скрипты висят в памяти. Чтобы с ними как-то взаимодействовать по сети, вы должны позаботиться об этом самостоятельно и реализовать некий протокол взаимодействия с вашей программой поверх tcp. Это может быть популярный и всем известный http протокол или что-то менее известное или даже придуманное вами.

Поскольку http протокол довольно популярен, то в node.js предоставили готовую реализацию в виде http модуля, который позволяет написать http сервер в несколько строк.

Строго говоря, вы это всё можете делать на любом языке, который умеет работать с сетью и PHP здесь не является исключением. Например вот одна из реализаций http сервера на PHP https://github.com/reactphp/http

Поискать таск менеджер с возможностью отложенной обработки задач. Например kue умеет отложенные задачи ставить в очередь https://github.com/Automattic/kue#delayed-jobs и затем написать обработчик этих задач, который будет что-то делать, например отправлять данные пользователю через сокет. Можно поискать альтернативы kue работающие напрямую с памятью, если не хотите раздувать стек технологий редисом. Но более-менее популярных альтернатив я не встречал.

WebAssembly это низкоуровневый язык программирования. Никто на нем в здравом уме не будет писать. Это почти тоже самое, как пытаться писать веб с помощью ассемблера. В него просто будут компилировать код с других языков, сейчас пока только C и C++, позже будут и другие. Он нужен, чтобы ускорить клиент-сайд, поскольку javascript медленный для всяких там 3D игр и всего такого. В общем походу скоро php захватит и клиент :)

Кроме того, эта идея уже была ранее реализована в asm.js от компании Mozilla. Разработчики сделали на C++ демку 3d игры скомилировали её в asm.js, общественность немного поигралась и всё заглохло. Революции не произошло.

Смотрим исходный код библиотеки socket.io-redis, находим там метод Redis#broadcast, внутри метода мы видим, что прежде чем сделать publish в редис канал, там вызывается метод Adapter#broadcast. Отлично, идем смотреть Adapter#broadcast и если отбросить всё лишнее мы увидим суть

if (rooms.length) {
   /*...*/
} else {
  for (var id in self.sids) {
    /*...*/
  }
}

Как видно, socket.io может отправить данные либо в какую-то комнату/комнаты, либо всем клиентам, которые к нему подключены. Увы, но отправить данные конкретному пользователю как видно из кода нельзя.

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

Для больших фулл реалтаймовых сайтов с базами данных пока беда, они почти все работают по принципу request response, как и веб до появления вебсокетов. Приходится хаки писать или делать дикий polling базы. Из нового поколения баз данных сейчас есть только rethinkdb, крутой проект, но еще довольно сырой. Как только пробуешь делать что-то посерьезнее, чем примеры из документации, выясняется что этого он еще не умеет, разработчики конечно обещают это всё добавить, так что ждем.

Есть еще такой фреймворк Meteor, но он мне вообще не нравится, раньше просто доставал обновления из mongo через обычный polling базы и называл это всё крутым фреймворком для реалтайм сайтов. Потом они переделали и стали слушать обновления через oplog, который нужен для репликаций в mongo, но не для всех запросов это работает, для некоторых все равно выходом является только polling и в этот oplog сыпятся апдейты со всех баз данных и всё такое. Ну а хули, костыль есть костыль. Ну и вообще штука дико монолитная, хуже чем sails.js.

Кароче пока нет нормальной инфраструктуры, чтобы писать большие фулл реалтаймовые сайты. Ну а в PHP вообще ничего нет, даже уровня Meteor, PHP застрял в схеме request-response. Попробуй найди там что-то получше, чем мизерная Ratchet библиотека для работы с вебсокетами. На ней пока к сожалению весь реалтайм в PHP и заканчивается.

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

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

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

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

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

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

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

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

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

Для очередей можно использовать kue. Работает поверх redis, который многие итак используют для масштабирования приложения по нескольким физически удаленным серверам, кеширования и всего прочего.

Конфиг можно подключать в индексном файле и отдавать каждой копии приложения.

const Application = require('path/to/Application');
const config = require('path/to/config');

if (cluster.isMaster) {
  for (var i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  new Application(config).run();
}

Про сокеты не совсем понял. Приложение пытается куда-то приконектиться и выступает в роли клиента или приложение пытается поднять свой сокет сервер ?