Обнаружена блокировка сессий в PHP

Отсутствие блокировок в phpredis - это скорее баг, чем фича.

Вот народ просит как раз добавить блокировки

https://github.com/phpredis/phpredis/issues/37

alexeyymanikin, могли бы вы пояснить, почему вы считаете, что этим нужно гордиться и как у вас происходит разделение двух и более клиентов хостинга, использующих redis?

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

Сессии в php в своем стандарте очень примитивны, просто пишет в файл, а так в большинстве случаев достаточно сложить их в БД, главное реализовать очистку протухших сессий, но редис тоже вполне пойдет. Либо не дергать session_start для каждого хита.

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

Так оно и в Редисе должно держать лок на сессию все время. Пока сессия открыта, в нее писать по идее не должно. Иначе коррапшн будет.

Многое зависит от кейса, в сессию многое не складывают, авторизацию, какую то юзерскую инфу и тогда получается что в сессию вы пишите при авторизации, для чего вам постоянно писать и каким должен быть кейс чтоб побить данные при одновременном чтении и записи сессии одного юзера?

Вы же в стандарте тут блочите сессию не в момент записи в неё, а в момент открытия, то есть когда вызван session_start и до момента session_write_close. В этот промежуток вы можете ничего не делать с сессией, но у вас например какой нибудь ajax запрос ресурсоемкий повесит все остальные ajax запросы на странице при это никак не работая с сессией вообще. Тут корапшен как вы говорите будет только в одном случае, если ваш кейс пишет в чужие сессии, ну или чистит чужие сессии, ну вообщем при воздействии из вне. Я работаю на достаточно больших ИМ и хз, какой кейс может побить сессию в редисе если честно. Ну а скорости конечно прибавляется, так как сессия используется на каждом хите и не мучается дисковая подсистема, хотя можно под сессии выделить и виртуальную папочку в оперативке, кому как интереснее.

Мы используем не стандартный хандлер redis - а свой. В случае если редис не доступен сессии работают с файлами. Так же добавили модуль который пишет в лог где, на какой строке, какой URL вызывался и сколько времени была блокировка. Не могу сказать, что это было сложно сделать - но в момент внедрения проблем мы получили не мало.

теперь как устроенно разделение. У каждого пользователя в docker работает свой экземпляр redis со своим настройками памяти, конфигами. Работает от имени суб-пользователя привязанного к основному пользователю (для сбора статистики стандартными средствами)

далее в iptables прописываем правила, их для каждого пользователя может быть много

Там два правила для локальных подключений и для внешних - это можно все настроить с панели управления. И получается, фактически когда пользователь стучится на 127.0.0.1:6379 его запрос перенаправляется внутрь контейнера, другие запросы внутрь контейнера попасть не могут.

Это позволяет поднимать приватные экземпляры redis, memcache, sphinx, mysql, postgress - да в принципе всего чего угодно в рамках виртуального хостинга.

Если честно я с HostCMS не разу не работал, в код не лазил, подсказать по этому вопросу не могу. Блокировки - это не к хостингу это больше к PHP. Только мы решили сообщать об этой проблеме, так как иногда это помогает.

---------- Добавлено 27.10.2017 в 04:59 ----------

пс. надеюсь пользователь aalangow не сильно обидеться что я указал его логин в примере...

Эх ПХП, ПХП... По идее если в редисе лок не ставиться на всю сессию на весь период, то скрипт выполняется в бекграунде до конца и пишет в сессию кривые данные, когда пользователь от злости обновил страницу и его новый скрипт пишет уже другие данные, на основании других записей, называется race condition, для этого и используются локи/семафоры/спины/мъютексы, в случае с файлами это как раз эксклюзивный лок на файл (который на самом деле не эксклюзивный на многих ОС), в случае с редисом - это (по идее) лок на запись в БД. В БД лок должен вестись сессионно и это отличает его от ФС, т.к. в ФС нет сессий, в БД пользователь сделал рефреш страницы, старая страница закрыла соединение с БД и соответственно транзакция откатилась, однако в случае скрипта пишущего в бекграунде Redis ничем не поможет, т.к. транзакция все равно будет завершаться, неважно сделал ли пользователь рефреш или нет.

Такой принцип работы мало отличается от ZFS (также существует транзакция, лок всего лишь запись в БД) и возможно BTRFS (не знаком), так что на новых ФС это дело не нужно (если только для кластеризации).

кто то мне из beget та походу за сообщение /ru/forum/comment/15306445

минусунул ((((

Вы себе льстите.