У меня очень специфические потребности для драйвера сеанса, потому что я буду внедрять логин на основе API с помощью pingbacks (спецификация API), и мне нужно очень индивидуальное поведение драйвера сеанса. Включение взаимодействия с базой данных / memcached в одно и то же время. Проект – «не спрашивайте, не говорите», что-то вещь xD, но в любом случае любая помощь будет глубоко оценена.
Я знаю, что laravel 4 поддерживает подобные вещи. Они поддерживают создателей, но есть точно 0 документации о том, как это сделать. Больше не существует метода «Session :: extend» для использования в global.php: /
В основном вы можете продлить / заменить любой класс Laravel, просто создав свой собственный, а затем заменив его в app / config / app.php.
From Dayle: «В Laravel 4 компоненты (базовые классы) загружаются с использованием ProviderInterfaces, они перечислены в конфигурациях приложений. Если вы меняете поставщика на свой собственный поставщик (для расширенного класса), ваш код будет использовать не только ваш код новый модуль, но ядро Laravel также будет использовать эти изменения ».
Интересно, какое конкретное поведение вам нужно. Но я должен напомнить вам, что использование сеанса такое же, как использование любого другого общего ресурса, поэтому должны применяться все принципы, особенно защита от одновременной записи.
PHP выполняет довольно хорошую работу по внедрению стандартов с хранилищем файлов, а также с хранилищем Memcache. Всякий раз, когда дело доходит до пользовательского чтения и сохранения сеанса, блокировка против одновременного доступа обычно игнорируется и забывается. С другой стороны, блокировка сеанса будет сериализовать выполнение нескольких параллельных запросов, и это не лучшая вещь для приложений Web 2.0 с возможным несколькими одновременными запросами Ajax на идентификатор сеанса.
Мне жаль это говорить, но Ларавель делает довольно плохую работу в этом отношении. Даже драйвер файла вообще не блокирует, даже если он пытается сохранить данные. То, что они не могут реализовать, заключается в том, что блокировка должна быть установлена до того, как они будут считывать данные. В противном случае одни и те же данные считываются дважды и изменяются дважды по-разному и записываются дважды – но тогда первое изменение теряется.
Эта проблема параллелизма будет очень тяжелой для отладки, поскольку она, вероятно, не будет возникать при использовании традиционного приложения веб-страницы без Ajax или Ajax, который будет использоваться только для чтения.
Поэтому я бы рекомендовал не использовать текущие драйверы сеанса Laravel. Они делают довольно плохую работу, записывая файлы сеанса (мой первый вопрос: зачем им нужно повторно записывать файлы в первую очередь – в PHP уже есть рабочий код, который, вероятно, также быстрее, потому что он написан в C, а не PHP), и то же самое верно для всего, о чем они пишут.
Обновить:
Сначала я посмотрел на неправильный исходный код. Как уже упоминалось в комментариях, Laravel 3 полностью нарушен в этом отношении, даже с файлами, поскольку он не использует собственный обработчик хранения сеанса PHP, но реализует его собственный.
Laravel 4 использовал этот макет и до бета-версии 4, и был идентично сломан. Это произошло только недавно, когда произошла серьезная переделка, которая использует Symfony / HTTP-Foundation вместо своих собственных. Таким образом, Laravel 4 не несет ответственности за какие-либо сбои сейчас, Symfony.
Symfony делает немного лучшую работу, потому что на самом деле есть драйвер хранения сеанса, который использует собственные функции PHP для сохранения сеансов в файлах. Стойка регистрации приветствия! \ Symfony \ Component \ HttpFoundation \ Session \ Storage \ Handler \ NativeFileSessionHandler делает вызов ini_set() files session.save_handler в files .
Любой другой обработчик хранилища (за исключением NullSessionHandler, по очевидным причинам) реализует загрузку и сохранение данных самостоятельно без какой-либо блокировки.
Давайте рассмотрим пример, который может быть легко исправлен: MemcachedSessionHandler . Если вы посмотрите на это, вы видите практически любой код в методах open() и close() , но это именно то, где должна происходить блокировка. Единственный активный код – в read() и write() (и destroy() ), который напрямую разговаривает с объектом клиента Memcached. Поэтому можно с уверенностью предположить, что я не заметил места, где происходит блокировка, – нет!
Memcached фактически предоставляет собственный обработчик сохранения сеанса для PHP. См. http://php.net/manual/en/memcached.sessions.php
Легкое исправление было бы главным образом скопировать NativeFileSessionHandler и просто установить session.save_handler = memcached и session.save_path кластера Memcache, который вы хотите использовать. Обработчик сохранения реализует правильную блокировку.
Существует открытая проблема, сообщающая именно об этом: https://github.com/symfony/symfony/issues/4976 Он открыт в течение 10 месяцев, что говорит мне, что большинство разработчиков предпочитают невероятно быструю сессионную операцию чтения с одновременными запросами, чем обеспечить надлежащую фиксацию.
Итак, Laravel 4 сделал что-то правильное, чтобы избавиться от собственной реализации багги-кода (у меня нет чувства, что они видели эту ошибку в то время), но теперь наследуют ошибки кода Symfony.
Что ты должен делать:
Zend Server предлагает Zend Session Cluster. Он работает в среде, с которой я работаю. Он прозрачен для PHP и имеет блокировку. Он записывает данные на жесткий диск и предлагает высокую доступность. Я бы подумал, что это довольно приличный набор функций. Думаю об этом.
У собственного обработчика сеанса Memcached также есть блокировка. Я считаю, что у него нет поддержки высокой доступности, и, конечно, любые данные, хранящиеся на узле, который идет вниз, теряются. В конце концов, это всего лишь очень быстрый кеш, а не надежное хранилище.
Для любого другого хранилища вам нужно выяснить, как вы можете получить блокировку атомарно. Или заниматься параллельной записью.
Например, MySQL предлагает заблокировать набор данных с помощью SELECT * FROM sesstable WHERE id = sessID FOR UPDATE . Redis также предлагает механизм блокировки с SET .
Если блокировка не является тем, что вы хотите сделать, другой вариант – попытаться очистить, если произойдет параллельная запись. CouchDB позволяет создавать конфликтующие записи, а именно клиентское приложение разрешает их – база данных будет обеспечивать доступ ко всем различным версиям. Также Memcached предлагает Memcached::cas (сравнение и своп), который будет писать только в том случае, если уже сохраненное значение не изменилось. Снова прочитайте сохраненное значение при сбое, попытайтесь объединиться с текущим набором данных и повторите попытку.