Автоматический выпуск блокировки

Блокировки автоматически выпускаются, когда разрушаются их объекты блокировки. Это деталь реализация, которая будет важна при использовании общих блокировок между процессами. В примере ниже, pcntl_fork() создает два процесса, а блокировка будет автоматически выпущена, как только будет закончен один из процессов:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// ...
$lock = $factory->createLock('report-generation', 3600);
if (!$lock->acquire()) {
    return;
}

$pid = pcntl_fork();
if (-1 === $pid) {
    // Невозможно выполнить ветвление
    exit(1);
} elseif ($pid) {
    // Родительский процесс
    sleep(30);
} else {
    // Дочерний процесс
    echo 'The lock will be released now.';
    exit(0);
}
// ...

Чтобы отключить это поведение, установите false в третьем аргументе LockFactory::createLock(). Это заставит получать блокировку на 3600 секунд, или пока не будет вызван Lock::release():

1
2
3
4
5

$lock = $factory->createLock(
    'pdf-creation',
    3600, // ttl
    false // autoRelease
);

FlockStore

FlockStore использует файловую систему на локальном компьютере для создания блокировок. Он не поддерживает истечение срока, но блокировка автоматически выпускается, когда объект блокировки выходит из области, и освобождается сборщиком мусора (например, когда заканчивается PHP процесс):

1
2
3
4
5

use Symfony\Component\Lock\Store\FlockStore;

// аргумент - это путь каталога, где создаются блокировки
// если он не задан, внутренне используется sys_get_temp_dir().
$store = new FlockStore('/var/stores');

MemcachedStore

MemcachedStore сохраняет блокировки на сервере Memcached, он требует подключения Memcached, реализующего класс \Memcached. Это хранилище не поддерживает блокировку, и ожидает TTL (Time To Live - время жизни), чтобы избежать затянутых блокировок:

1
2
3
4
5
6

use Symfony\Component\Lock\Store\MemcachedStore;

$memcached = new \Memcached();
$memcached->addServer('localhost', 11211);

$store = new MemcachedStore($memcached);

MongoDbStore

MongoDbStore сохраняет блокировки на сервере MongoDB >=2.2, оно требует \MongoDB\Collection или \MongoDB\Client из mongodb/mongodb или строки соединения MongoDB. Это хранилище не поддерживает блокировку и ожидает срока истечения, чтобы избежать устаревших блокировок:

1
2
3
4
5
6
7
8
9
10
11

use Symfony\Component\Lock\Store\MongoDbStore;

$mongo = 'mongodb://localhost/database?collection=lock';
$options = [
    'gcProbability' => 0.001,
    'database' => 'myapp',
    'collection' => 'lock',
    'uriOptions' => [],
    'driverOptions' => [],
];
$store = new MongoDbStore($mongo, $options);

MongoDbStore приниает следующие $options (в зависимости от типа первого параметра):

Когда первый параметр:

MongoDB\Collection:

• $options['database'] игнорируется
• $options['collection'] игнорируется

MongoDB\Client:

• $options['database'] обязательна
• $options['collection'] обязательна

Строка соединения MongoDB:

• используется $options['database'], иначе - /path из DSN, как минимум одна - обязательна
• используется $options['collection'], иначе - ?collection= из DSN, как минимум одна - обязательна

PdoStore

PdoStore сохраняет блокировки в базе данных SQL. Оно требует соединения PDO, соединения Doctrine DBAL, или Имя источника данных (DSN). Это хранилище не поддерживает блокировку, и ожидает срока действия, чтобы избежать устаревших блокировок:

1
2
3
4
5

use Symfony\Component\Lock\Store\PdoStore;

// PDO, соединение Doctrine DBAL или DSN для ленивого соединения через PDO
$databaseConnectionOrDSN = 'mysql:host=127.0.0.1;dbname=app';
$store = new PdoStore($databaseConnectionOrDSN, ['db_username' => 'myuser', 'db_password' => 'mypassword']);

Таблица, где хранятся значения, создается автоматически при первом вызове к методу save(). Вы также можете создать эту таблицу ясно, вызвав метод createTable() в вашем коде.

DoctrineDbalStore

DoctrineDbalStore сохраняет блокировки в базе данных SQL. Оно идентично PdoStore, но требует соединения Doctrine DBAL или Doctrine DBAL URL. Это хранилище не поддерживает блокировку и ожидает TTL, чтобы избежать заглохших блокировок:

1
2
3
4
5

use Symfony\Component\Lock\Store\DoctrineDbalStore;

// соединение Doctrine DBAL или DSN
$connectionOrURL = 'mysql://myuser:mypassword@127.0.0.1/app';
$store = new DoctrineDbalStore($connectionOrURL);

Таблица, где хранятся значения, будет автоматически сгенерирована, когда вы запустите команду:

1

$ php bin/console make:migration

Если вы предпочитаете создавать таблицу самостоятельно и она ещё не была создана, вы можете создать эту таблицу явным образом, вызвав createTable(). Вы также можете добавить эту таблицу в свою схему, вызвав configureSchema() в вашем коде.

Если таблица не была создана ранее, то она будет создана автоматически при первом вызове метода save().

PostgreSqlStore

PostgreSqlStore использует консультативные блокировки, предоставленные PostgreSQL. Оно требует соединения PDO или Имя источника данных (DSN). Оно поддерживает нативную блокировку, а также общие блокировки:

1
2
3
4
5

use Symfony\Component\Lock\Store\PostgreSqlStore;

// PDO или экземпляр DSN для ленивого соединения через PDO
$databaseConnectionOrDSN = 'postgresql://myuser:mypassword@localhost:5634/lock';
$store = new PostgreSqlStore($databaseConnectionOrDSN);

В отличие от PdoStore, PostgreSqlStore не нуждается в таблице для хранения блокировок, и не имеет срока истечения действия.

DoctrineDbalPostgreSqlStore

DoctrineDbalPostgreSqlStore использует консультативные блокировки, предоставленные PostgreSQL. Оно идентично PostgreSqlStore, но требует соединения Doctrine DBAL или Doctrine DBAL URL. Поддерживает нативные блокировки, а также общие блокировки:

1
2
3
4
5

use Symfony\Component\Lock\Store\DoctrineDbalPostgreSqlStore;

// соединение Doctrine или DSN
$databaseConnectionOrDSN = 'postgresql+advisory://myuser:mypassword@127.0.0.1:5634/lock';
$store = new DoctrineDbalPostgreSqlStore($databaseConnectionOrDSN);

В отличие от DoctrineDbalStore, DoctrineDbalPostgreSqlStore не нуждается в таблице, чтобы хранить блокировки, и не имеет срока окончания действия.

RedisStore

RedisStore сохраняет блокировки на сервере Redis, он требует подключения Redis, реализующего классы \Redis, \RedisArray, \RedisCluster, \Relay\Relay или \Predis. Это хранилище не поддерживает блокировку, и ожидает TTL, чтобы избежать затянутых блокировок:

1
2
3
4
5
6

use Symfony\Component\Lock\Store\RedisStore;

$redis = new \Redis();
$redis->connect('localhost');

$store = new RedisStore($redis);

SemaphoreStore

SemaphoreStore использует функции PHP semaphore для создания блокировок:

1
2
3

use Symfony\Component\Lock\Store\SemaphoreStore;

$store = new SemaphoreStore();

CombinedStore

CombinedStore создан для приложений Высокой Доступности, так как он синхронно управляет несколькими хранилищами (например, несколькими серверами Redis). Когда блокировка обнаружена, он перенаправляет вызов ко всем управляемым хранилищам, и собирает их ответы. Если простое большинство хранилищ обнаружили блокировку, то она считается обнаруженной; иначе - нет:

1
2
3
4
5
6
7
8
9
10
11
12
13

use Symfony\Component\Lock\Strategy\ConsensusStrategy;
use Symfony\Component\Lock\Store\CombinedStore;
use Symfony\Component\Lock\Strategy\ConsensusStrategy;

$stores = [];
foreach (['server1', 'server2', 'server3'] as $server) {
    $redis= new \Redis();
    $redis->connect($server);

    $stores[] = new RedisStore($redis);
}

$store = new CombinedStore($stores, new ConsensusStrategy());

Вместо простой стратегии простого большинства (ConsensusStrategy) можно использовать UnanimousStrategy для запроса обнаружения блокировки во всех хранилищах:

1
2
3
4

use Symfony\Component\Lock\Store\CombinedStore;
use Symfony\Component\Lock\Strategy\UnanimousStrategy;

$store = new CombinedStore($stores, new UnanimousStrategy());

ZookeeperStore

ZookeeperStore сохраняет блокировки на сервере ZooKeeper. Оно требует соединения ZooKeeper, релизующего класс \Zookeeper. Это хранилище не поддерживает блокировку и истечение действия, но блокировка автоматически выпускается, когда заканчивается PHP процесс:

1
2
3
4
5
6
7

use Symfony\Component\Lock\Store\ZookeeperStore;

$zookeeper = new \Zookeeper('localhost:2181');
// использовать следующее, чтобы определить кластер высокой доступности:
// $zookeeper = new \Zookeeper('localhost1:2181,localhost2:2181,localhost3:2181');

$store = new ZookeeperStore($zookeeper);

Удалённые хранилища

Удалённые хранилища (MemcachedStore , MongoDbStore , PdoStore , PostgreSqlStore , RedisStore и ZookeeperStore ) используют уникальный токен, чтобы распознаьт настоящего владельца блокировки. Этот токен хранится в объекте Key и используется внутренне Lock.

Каждый одновременный процесс должен хранить Lock на одном и том же сервере. Иначе, разные машину могут позволять двум разным процессам получать один и тот же Lock.

Хранилища с истечением срока

Хранилища с истечением срока (MemcachedStore , MongoDbStore , PdoStore и RedisStore ) гарантируют, что блокировка будет получена только в течение определенного временного промежутка. Если выполнение задачи занимает больше времени, то блокировка может быть выпущена хранилищем и получена кем-то другим.

Lock предоставляет несколько методов для проверки здоровья. Метод isExpired() проверяет, закончилось ли время существования, а метод getRemainingLifetime() возвращает оставшееся время существования в секундах.

Используя методы выше, более обширный код будет:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// ...
$lock = $factory->createLock('invoice-publication', 30);

if (!$lock->acquire()) {
    return;
}
while (!$finished) {
    if ($lock->getRemainingLifetime() <= 5) {
        if ($lock->isExpired()) {
            // блокировка была утеряна, выполнить откат или отправить уведомление
            throw new \RuntimeException('Lock lost during the overall process');
        }

        $lock->refresh();
    }

    // Выполнить задачу, длительность которой ДОЛЖНА быть менее 5 минут
}

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

FlockStore

Используя файловую систему, это Store надежно, если одновременные процессы использует один и тот же физический каталог для хранения блокировок.

Процессы должны выполняться на одной машине, виртуальной машине или контейнере. Будьте осторожны при обновлении сервиса Kubernetes или Swarm, так как на короткий период времени, два контейнера могут работать параллельно.

Абсолютный путь к каталогу должен оставаться одним и тем же. Будьте осторожны с символьными ссылками, которые могут измениться в любое время: Capistrano и зеленый/синий запуск часто используют этот фокус. Будьте осторожны, когда путь к этому каталогу изменяется между двумя запусками.

Некоторые файловые системы (вроде некоторых типов NFS) не поддерживают блокировку.

Файлы в файловой системе могут быть удалены во время операции по техническому обслуживанию. Например, чтобы очистить каталог /tmp, или после перезагрузки машины, когда каталог использует tmpfs. Это не проблема, если блокировка выпущена, когда процесс закончен, но это проблема, если Lock используется повторно между запросами.

MemcachedStore

Memcached работает путем сохранения объектов в памяти. Это означает, что используя MemcachedStore , блокировки не сохраняются, и могут по ошибке исчезнуть в любое время.

Если сервис Memcached или хостинг машины перезагружается, каждая блокировка будет утеряна без уведомления текущих процессов.

По умолчанию Memcached использует механизм LRU для удаления старых записей, когда сервису необходимо пространство для добавления новых объектов.

Когда сервис Memcached общий и используется множеством образом, блокировки могут быть удалены по ошибке. Например, некоторая реализация метода PSR-6 clear() использует метод Memcached flush(), который сбрасывает и удаляет все.

MongoDbStore

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

1
2
3
4

db.lock.createIndex(
    { "expires_at": 1 },
    { "expireAfterSeconds": 0 }
)

Как вариант, можно единождя вызвать метод MongoDbStore::createTtlIndex(int $expireAfterSeconds = 0), чтобы создать индекс срока действия во время настройки базы данных. Прочтите больше о Дате истечения срока из коллекций, путем установки TTL в MongoDB.

writeConcern и readConcern не указаны MongoDbStore, означая, что будут действовать настройки коллекции. readPreference является primary для всех запросов. Прочтите больше о Семантике набора реплик для чтения и записи в MongoDB.

PdoStore

PdoStore полагается на свойства ACID движка SQL.

Для того, чтобы сбросить старые блокировки, это хранилище использует текущие дату и время, чтобы определить справочник даты истечения срока. Этот механизм полагается на все узлы сервера, чтобы иметь синхронизированные часы.

PostgreSqlStore

PdoStore полагается на свойства Консультативных болкировок базы данных PostgreSQL. Это означает, что используя PostgreSqlStore , блокировки будут автоматически выпущены в конце сессии в случае, если клиент не сможет произвести разблокирование по каким-то причинам.

Если сервис PostgreSQL, или машина на которой он размещен, перезапускается, каждая блокировка будет утеряна, без уведомления текущих процессов.

Если TCP-соединение утеряно, PostgreSQL может выпустить блокировки без уведомления об этом приложения.

RedisStore

Redis работает, сохраняя объекты в памяти. Это означает, что используя RedisStore , болкировки не сохраняются и могут по ошибке изчезнуть в любое время.

Если сервис Redis, или машина на которой он размещен, перезапускается, каждая блокировка будет утеряна, без уведомления текущих процессов.

Когда сервис Redis общий и спользуется для нескольких применений, блокировки могут быть удалены по ошибке.

CombinedStore

Combined хранилище позволяет хранить блокировки по нескольким бэкендам. Распространенная ошибка - думать, что механизм блокировок будет более надежным. Это не так. CombinedStore в лучшем случае будет настолько надежен, насколько наименее надежный из всех управляемых хранилищ. Как только одно из управляемых хранилищ вернет ошибочную информацию, CombinedStore не будет надежным.

SemaphoreStore

Семафоры обрабатываются уровнем Ядра. Для того, чтобы быть надежными, процессы должны работать на одной и той же машине, виртуальной машине или контейнером. Будьте осторожны обновляя сервисы Kubernetes или Swarm, так как на короткий период времени, два контейнера могут работать параллельно.

ZookeeperStore

ZookeeperStore работает путем содержания блокировок в виде эфемерных узлов на сервере. Это означает, что используя ZookeeperStore , блокировки будут автоматически выпущены в конце сессии, если клиент не сможет произвести разблокировку по каким-то причинам.

Если сервис ZooKeeper, или машина на которой он размещен, перезапускается, каждая блокировка будет утеряна, без уведомления текущих процессов.

Итог

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