Эти данные хранятся в базе данных или Redis. Из-за большого количества пользователей даже поиск в Redis может быть довольно дорогостоящим. Если все эти данные будут сохранены в Session, то во время активности группы (предположим, что любое действие, связанное с текущим чатом, например, сообщение в группе, считается активностью группы; если в течение 20 минут не было никаких действий, группа считается неактивной), операции, требующие использования этих данных, могут быть напрямую извлечены из памяти текущего сервиса Session без удалённого запроса к Redis. Это значительно сократит время отклика и существенно снизит стоимость обработки, а сокращение времени обработки и снижение стоимости обслуживания приведут к значительному повышению качества каждого запроса на обслуживание и увеличению параллелизма на одном сервере.

• Предварительным условием для сокращения запросов к хранилищу и сохранения данных, связанных с группой, в Session является обеспечение целостности данных в Session. Как обеспечить целостность данных в Session здесь подробно не рассматривается, но можно дать две подсказки:

  1. Все операции, связанные с одной и той же группой, выполняются одним и тем же узлом службы.
  2. Операции записи данных, связанных с группами, сначала отправляют запрос на запись в систему хранения (Redis или очередь сообщений, база данных слишком медленная и требует асинхронной записи), и после успешного ответа системы хранения немедленно обновляют только что записанные данные в Session. Как гарантировать, что все операции, связанные с одной группой, будут выполняться одним и тем же узлом сервиса? Это легко реализовать с помощью микросервисной системы, построенной с использованием Nebula, просто вызывая функцию SendOriented() класса Actor.

• Группа легко создаёт параллелизм. Когда два члена неактивной группы случайно отправляют сообщения или проверяют информацию о группе одновременно, и оба запроса случайно направляются к одному и тому же узлу службы, текущий узел не имеет соответствующего Session для этой группы. В этом случае многократная загрузка Session может привести к снижению производительности. Многократная загрузка данных Session не является разумной и противоречит принципу проектирования Session. Поскольку служба на основе Nebula полностью асинхронная, нет необходимости блокировать другие запросы и ждать завершения загрузки данных одного запроса, что снижает параллелизм. Кроме того, поскольку запросы «одновременно» достигают цели, на самом деле существует определённый порядок следования между запросами, и между ними могут быть микросекундные или даже более мелкие временные различия. Вот где используются четыре метода защиты членов Session: IsReady(), SetReady(), IsLoading() и SetLoading():

  • Первый шаг: Запрос A обнаруживает, что Session группы отсутствует на текущем узле службы, и создаёт новый Session группы.
  • Второй шаг: Создаётся новый StepA, который выполняет StepA->Emit() для отправки запроса данных в хранилище и одновременно вызывает SetLoading() в Session, чтобы установить индикатор загрузки данных Session.
  • Третий шаг: Запрос B обнаруживает существующий Session группы, создаёт новый StepB и выполняет StepB->Emit(). Вызывается IsReady(this) в Session, и если IsReady(this) возвращает true, обработка запроса B продолжается нормально; если IsReady(this) возвращает false, вызывается IsLoading(), и если IsLoading() возвращает true, StepB->Emit() возвращает CMD_STATUS_RUNNING; если IsLoading() возвращает false, StepB->Emit() отправляет запрос данных в хранилище и одновременно вызывает SetLoading() в Session для установки индикатора загрузки данных Session.
  • Четвёртый шаг: После успешного получения ответа на запрос данных от хранилища StepA->Callback() вызывается фреймворком. В функции обратного вызова StepA->Callback() данные сначала сохраняются в Session группы и вызывается SetReady() этого Session группы. Затем продолжается обработка запроса A (например, создаётся новый StepA2 и выполняется StepA2->Emit()).
  • Пятый шаг: StepB->Callback() также вызывается фреймворком после получения данных. StepA->Callback() передаёт те же параметры StepB->Callback(), потому что, если IsLoading() вернёт false, данные будут загружены StepB->Emit(), и StepB->Callback() получит те же параметры, что и StepA->Callback().

• В этих шагах есть только один запрос на загрузку данных, отправленный в систему хранения. После получения ответа от системы хранения фреймворк вызывает обратный вызов для каждого ожидающего одного и того же набора данных Step, одновременно заполняя данные Session группы. Последующие запросы могут напрямую получать данные из Session группы без необходимости отправлять дополнительные запросы в систему хранения.

• Диаграмма процесса или временная диаграмма, иллюстрирующая сценарий применения Session для групп, была бы более понятной, но она не предоставлена.