Filgavrilov, базовые конструкции — это синтаксис. А jquery — это сленг, придется попыхтеть недельку.
Вот, например, "замыкания" не относятся к синтаксису, а в jquery полно их применений.
Частенько придется адаптировать код из интернета, а для этого могут понадобиться расширенные знания js.
Вот и облик русского туриста — прокричал что-то из словарика, а ответ не понимает.
Дмитрий, разработчик должен уметь объяснять, устно и письменно. Иногда получается так, что неверные окончания слов коверкают смысл фраз, и приходится сначала распознавать изначальный посыл. Но мы же разработчики, а не телепаты.
API в виде протокола обмена — между серверами постоянное соединение логичнее держать.
Запросы на поиск пользователей по идентификатору надо свести к минимуму. Тем более, что о видимости между пользователями обычно должно быть уже известно сокет-серверам после вычислений "попадания". И гадать, куда обращаться к пользователю не придётся — хранимые на сокет-серверах списки о пользователях ведь с такой меткой и предусматриваются.
Да, подключающиеся пользователи запоминаются на сокет-сервере и на головном. И (повторю) при надобности осведомляются остальные "заинтересованные" в ходе вычислений сокет-серверы. Привязка сокет-сервера и пользователя по идентификаторам есть "корень" такого взаимодействия.
Ещё нужно много продумать о вычислениях "попаданий", какие данные понадобятся головному серверу, где вычислять получится быстрее, прочие неочевидности.
По поводу "кэша" на пользователей. Как-то особенно их запоминать по-моему незачем, если отвалится сокет-сервер или один из "воркеров" на нём, то и отвалятся пользователи, они будут сами реконнектиться к любому другому серверу. На головном сервере нужно будет как-то разрешать последующие нестыковки, но здесь уже полноценное хранилище будет.
теоретическая прикидка
На головном сервере есть некоторые сведения о всех пользователях и метках с указанием, какому сокет-серверу они принадлежат. Головной сервер сообщает сокет-серверам, какой из них обладает интересующими их пользователями и метками. Так сокет-серверы о пользователях и метках будут общаться между собой. Сообщение от одного пользователя до другого пойдет или через общий сокет-сервер, или через два сокет-сервера, которые уже будут знать об этих двух пользователях.
Стоит подумать над тем, есть ли в логике приложения прямые запросы от пользователей друг к другу, которые невозможно предсказать, такие запросы будут проходить через головной сервер и порождать поиск.
Конечно, всё обрушится, когда пользователи и метки все вместе окажутся внутри какой-то минимальной зоны.
Вычисления критериев на "попадание" придется как-то разделить. Например, распределить пользователей и метки по зонам, по степени удалённости зон исключать вычисления.
1. непонятна схема взаимодействия "микросервисов", почему возник такой вопрос, почему нельзя на сокет-сервере держать пользователей?
2. циклы можно подкрутить, если возлагать обмен на низкоуровневые потоки и события, для миллиона клиентов поднимаются несколько серверов с группировкой и балансировкой.
(^|\}\s*)типа "начало строки или предшествующая фигурная скобка", переносы убрать, заменить на \s