Александр Панков

Этот дедлок - проявление MVCC, механизма, чтобы несколько пользователей могли работать с БД одновременно.
Визуализировать эту ситуацию можно как перекрестные стрелки в зависимостях


Если мы говорим про postgres, то если ты обновил какую-то запись (кортеж), то неявно получаешь на нее (запись) блокировку. Когда кто-то другой хочет обновить эту же запись, то ждет ее освобождения.
В данном случае (визуализация), 1 процесс выполнял UPDATE X, Y а другой UPDATE Y, X, т.е. первый взял блокировку сначала на X потом на Y, а другой - сначала на Y потом на X. Первая блокировка успешна, но вторые нет - они уже заняты.
В данном случае, разрешить их нельзя, т.к. оба ждут пока один из них снимет блокировку, но этого не произойдет. Блокировка со строки снимется по окончании транзакции.

Совет про сортировку взят, чтобы привнести единообразие в работу. Грубо говоря, дедлок появляется, когда нет согласованности в работе. Если оба выполнят UPDATE X, Y (в таком порядке), то дедлока не будет т.к. один из них сможет взять все блокировки на строки успешно. Поведение второго будет уже зависеть от уровня сериализации:
- Read committed - обновит новые данные
- Другие (repeatable read, serializable) - ошибка выполнения
Это уже детали MVCC в postgres (read uncommitted нет)

Домен .local заменить на .loc

а как он задает приватное свойство?
типы свойств jmsyst.com/libs/serializer/master/reference/annota...
как вариант

final class Element
{
    /**
     * @XmlAttribute
     */
    private ?int $zone = null;
    public function __set(string $name, $value)
    {
           if ($name === 'zone' && $value === 0) {
                 $value = null;
           }
           $this->{$name} = $value;
    }
}

или

final class Element
{
    /**
     * @XmlAttribute
     */
    private ?int $zone = null;

    public function __get(string $name)
    {
           if ($name === 'zone' && $this->zone === 0) {
                 return null;
           }
           return $this->{$name};
    }
}

что такое dev суфикс (freetype и freetype-dev) и как понять какую версию ставить (я ставил методом тыка, когда получал ошибки и гуглил)

Dev суффикс означает, что в данном пакете присутствуют файлы, необходимые для компиляции кода, использующего устанавливаемую библиотеку. Устанавливать нужно обе версии. Обычная версия "freetype" содержит саму библиотеку в so файле, которую gd будет подключать в рантайме. Dev версия "freetype-dev" нужна для сборки самого gd, так как модуль собирается из исходников.

почему, например, для mycrypt мне сперва нужно загрузить именно libmcrypt-dev, потом через pecl скачать mcrypt, а потом через алиас docker-php-ext-enable включить (экспериментировал и не работает с другими сценариями), а если смотреть на opcache, тот тут сразу docker-php-ext-install и все, а xdebug еще один сценарий: pecl -> docker-php-ext-enable - почему все по разному, как это понять?

Для разных модулей требуются разные сторонние библиотеки. Для gd это freetype (для работы со шрифтами), libpng (для поддержки формата png), libjpeg-turbo (для поддержки jpeg). У opcache таких зависимостей нет, поэтому ничего дополнительно устанавливать не требуется.

в чем отличие этих сценариев установки расширений (что делает каждая команда, простыми словами)?

У php есть модули, которые поставляются с самим php. Например: zip, opcache, pdo_mysql, intl. Такие модули устанавливаются специально предусмотренным для этого скриптом docker-php-ext-install. Этот скрипт распаковывает исходники php, собирает запрошенные вами модули, копирует их в /usr/local/lib/php/extensions/no-debug-non-zts-20190902 (в других образах php путь может отличаться), прописывает загрузку модуля в ini и удаляет распакованные ранее исходники. То есть под капотом скрипт docker-php-ext-install вызывает скрипты docker-php-source, docker-php-ext-configure, docker-php-ext-enable.

А есть модули, которые хостятся отдельно на сайте pecl.php.net. Это официальный репозиторий, где хостятся всякие разные сторонние модули типа mcrypt, imagick, xdebug. Для их установки нужно использовать утилиту pecl. Так как pecl автоматически не включает модули в ini, из-за этого необходимо самому включать их при помощи скрипта docker-php-ext-enable.

нагуглил что
docker-php-source - создает /usr/src/php

Ещё распаковывает туда исходники самого php и поставляемых с ним модулей.

docker-php-ext-install - скачивает (ОТКУДА?)

Из архива /usr/src/php.tar.xz

docker-php-ext-configure- конфигурирует перед установкой (что это значит?)

Этот скрипт настраивает настройки, с которыми будет скомпилирован модуль. Например, тот же gd можно собрать без поддержки jpeg если сконфигурировать без опции --with-jpeg. Нужно ли запускать docker-php-ext-configure так же зависит от того, что написано в документации. Очень мало модулей требует предварительной конфигурации перед установкой. Мне на ум приходит только gd.

В целом, официальная документация php вам поможет понять каким способом нужно устанавливать модули. Смотрим раздел requirements. Если написано "This extension is bundled with PHP", значит нужно устанавливать при помощи скрипта docker-php-ext-install. Если написано что-то вроде "This PECL extension is not bundled with PHP", значит нужно устанавливать через pecl.

Независимо от способа установки, нужно всегда устанавливать библиотеки, от которых зависят конкретные нужные вам модули. Например, в том же imagick написано "ImageMagick >= 6.2.4 is required". Это значит, что нужно установить библиотеку imagemagick. В вашем базовом образе на основе alpine 3.16 в репозиториях ОС присутствует версия 7.1.0, которая подходит под условие >= 6.2.4:

/var/www/html # apk info imagemagick
imagemagick-7.1.0.35-r0 description:
Collection of tools and libraries for many image formats

imagemagick-7.1.0.35-r0 webpage:
https://imagemagick.org/

imagemagick-7.1.0.35-r0 installed size:
4664 KiB

Для intl нужна "ICU library, version 4.0.0 or newer". Такая библиотека тоже присутствует в репозиториях альпины:

/var/www/html # apk info icu
icu-71.1-r2 description:
International Components for Unicode library

icu-71.1-r2 webpage:
https://icu.unicode.org/

icu-71.1-r2 installed size:
796 KiB

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

nginx

rewrite ^/catalog/razdel-1/(.*)$ https://foo.ru/catalog/NOVIY-RAZDEL/$1 permanent;

.htaccess

RewriteRule ^catalog/razdel-1/(.*)$ https://foo.ru/catalog/NOVIY-RAZDEL/$1 [R=301,L]

В альтернативу ответу который уже отмечен верным предложу вариант с Rich Domain Model.

Работайте не с отдельным Item, а с целым заказом.
Добавьте в сущность заказа метод changeItemQuantity(Item $item, integer $quantity)
И в нем помимо смены количества в том числе производите пересчет всего заказа.

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

у меня в голове
1) создаю сервис класс
2) инициалиирую его в конструкторе контроллера
3) в методе контроллера одной строкой меняю данные корзины
4) тут же ниже дергаю метод сервиса "обновить заказ"
но с другой стороны, другому программисту ничего не мешает взять обновить данные корзины
и все, не пересчитывать заказ... как обезопаситься от этого?

Вот чес слово, светлая голова! думаешь о другом программисте.
А всё просто, не надо в контроллере обновлять.
Сделай сервис класс, где будут методы обновления и перерасчёта.
И прямо там это делай.
Т.е. метод обновить данные корзины, в котором будет обновление и вызов метода этого же класса для перерасчёта заказа.
И не забудь всё это в одну транзакцию обернуть.

А дальше лирика уже...

но с другой стороны, другому программисту ничего не мешает взять обновить данные корзины

Но это всёравно ему заговнокодить не помешает.
Для того, чтоб не дать говнокодить нужно как минимум симфони там делать сложные тру структуры кода, которые писать в раз 10 дольше, чем сервис класс на ларавель. А ещё в 10 раз можно больше самому намудрить(если ты задал вопрос тут, на который я отвечаю, то тебе это пока рано).
А ещё чтоб всё тру-тру было, надо тесты прикрутить, что всё это ещё умножит на х3 по времени и тоже не даст гарантий:)

И самое главное, бизнес будет тебя просить как ты щас делаешь с риском что кто-то сделает баг и потом пофиксить его, чем делать всё по канонам в 10-30 раз дольше, дороже и увеличия очень сильно вход для программситов. Ну а баги там тоже будут, только намного более сложные и трудноловимые.
За мои 12 лет я понял, что надо делать как хочет бизнес, а это максимально простой, понятный код и иногда фиксить баги. И ВСЕГДА вычищать технический долг.

Направление мысли верное, но детали не совсем.

1. По домену все так.
2. Домен надо делегировать на DNS хостинг. Поэтому не покупайте домен в nicru, они оборзели уже давно и хотят за это деньги. Купите на 2домен.ру или где еще, где бесплатный DNS хостинг.
3. Да, создаете в админке DNS доменные имена третьего уровня (A записи) и в качестве дестинейшн указываете IP адрес VPC.
4,5. Можно и в докере, даже удобнее будет. Тем самым будете указывать proxy_pass по имени контейнера приложения, иначе столкнетесь с тем, что при пересоздании контейнеров придется менять адреса в конфиге nginx, т.е. porject1.domain.ru -> porject1_container_name:1000

Совершенно не изврат, это верный подход.

А зачем вам гит на vps? Должен быть какой-то один "источник правды".

Мне кажется что история должна быть такой: git server (github/gitlab/etc) -> local repository -> rsync to vps -> volume to docker

Соответственно, когда вы меняете ветку в локальном репозитории - rsync видит изменения файлов и синхронизирует их с vps, который ничего про гит не знает - для него это просто набор файлов.