Автоматичний реліз блокування

Блокування автоматично випускаються, коли руйнуються їх обʼєкти блокування. Це деталь реалізації, яка буде важливою при використанні загальних блокувань між процесами. У прикладі нижче, 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().

$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 = [
    'gcProbablity' => 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);

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

PostgreSqlStore

PostgreSqlStore використовує консультативні блокування, надані PostgreSQL. Воно вимагає зʼєднання PDO, зʼєднання Doctrine DBAL, або Імʼя джерела даних (DSN). Воно підтримує нативне блокування, а також загальні блокування:

1
2
3
4
5

use Symfony\Component\Lock\Store\PostgreSqlStore;

// PDO, зʼєднання Doctrine DBAL або 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 або \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-семафора для створення блокувань:

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 або машина, на якій він розташований, перезапускається, кожне блокування буде втрачене, без сповіщення поточних процесів.

Заключення

Зміна конфігурації сховищ повинна проводитися дуже обережно. Наприклад, під час запуску нової версії. Процеси з новою конфігурацією не повинні починатися в той час, як старі процеси зі старою конфігурацією все ще тривають.