Хранение php-сессий в Redis с блокировками

[@akzhan]

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

А так вы специально занижаете производительность системы за счет ненужных блокировок.

[@ololoepepe]

Если менять нужно по одному значению за раз, а получать все скопом, то лучше воспользоваться Set-ом, и, соответственно, hset, hgetall.

[@zerkms]

Реализацию, в которой есть sleep, чисто технически называть «спинлоком» уже нельзя.

[@zerkms]

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

К чему это я: если приходится синхронизировать объект для данных, для которых синхронизация не нужна, то может выбрать абстракцию/хранилище, которые больше подойдут для задачи? В приведённом примере просто работа с redis, минуя прокладку в виде «сессий» проблему «решила бы». Точнее, в этом случае «проблема» даже не существовала бы как класс.

[@dmitry-suffi]

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

[@Fortop]

Теоретически сессии в пхп это механизм хранения состояния для пользователя, чтобы решить вопрос stateless http.

Какие ещё гонки в этом случае? Поведение, когда конкретный пользователь генерирует 100 одновременных http запросов, которым требуется общее состояние — неадекватно.

С большой долей вероятности у вас это должны быть или разные пользователи.
Или это у вас не состояние, а данные, которые должны быть в БД

[@romy4]

Например, пользователь открыл в двух вкладках приложение, которое запоминает историю посещений. Какая из историй более правильная?

[@Fortop]

Никаких гонок в этом случае не возникает.
Сессия справляется.

Основная «сложность» это определить как себя должно вести приложение.

Например тот же гугл ведёт историю пользователя в разрезе устройств, но она доступна отовсюду с устройств этого пользователя

[@r0ocket]

Автор, а можете объяснить цель использования lua? Ведь одно условие можно и на php реализовать.

[@http3]

Хм.
Это все сессии, кроме файловых, по умолчанию неблокируемы?