Комментарии 2
Спасибо, очень интересный и полезный кейс. С меня плюсик. Не могли бы вы раскрыть чуть более подробно механизм с локом? Как все поды в кубере понимают что сейчас лок установлен? Это фича самой симфони или кеша? Где хранится информация об этом? Что происходит при попытке писать в лок в другой поде, експшн?
Спасибо большое за комментарий!
По поводу механизма лока и куба. На уровне конфигурации компонента Symfony Lock настраивается хранилище (Memcached, PostgreSQL, Redis и т. д.), где лежит информация о локе, после чего мы создаем лок, который будет использовать сконфигурированное хранилище (https://github.com/Codesrc-public-ru/Examples/blob/main/Symphony%20Lock/ExternalServiceTokenProvider.php#L17).
В нашем случае используется кластерный Memcached, поэтому все поды понимают, есть в данный момент лок или нет.
По поводу поведения. Исключение при попытке взять занятый лок не бросается. В примере (https://github.com/Codesrc-public-ru/Examples/blob/main/Symphony%20Lock/ExternalServiceTokenProvider.php#L19) у нас просто блокируется выполнение и ожидается освобождение лока. Также у лока есть TTL на случай падения пода или других непредвиденных ситуаций - это позволяет избежать вечного дедлока.

Кэширование в Symfony: как мы сломали авторизацию и починили ее через Lock