Как блокировки базы данных и веб-сервер взаимодействуют в отношении сеансов базы данных?

Этот вопрос имеет широкую область, например, веб-серверы, серверы баз данных, php-приложения и т. д., и поэтому я сомневаюсь, что это относится к stackoverflow, однако, поскольку этот вопрос поможет нам в том, как написать код приложения, я решил задать его здесь.

У меня путаница в том, как сеансы базы данных и веб-серверы работают вместе. Если я прав, когда выполняется соединение для клиента, для этого соединения будет создан ТОЛЬКО один сеанс, который будет продолжаться до тех пор, пока соединение не будет отключено или оно будет повторно подключено из-за длительного отсутствия активности.

Теперь, если мы рассмотрим веб-сервер, в частности Apache 2.4, на котором выполняется приложение PHP 7.2 (на виртуальном хосте) с базой данных, поддерживаемой MariaDB 10.3.10 (на Fedora 28, если это вообще имеет значение), я предполагаю следующий сценарий (пожалуйста, исправьте мне если я не прав)

  • Для каждого веб-приложения прямо сейчас мы используем Laravel, только одно соединение с базой данных будет выполнено, как только первый запрос попадет на URL-адреса, которые он обслуживает.
  • Впоследствии он будет иметь только одну сессию базы данных для этого. Когда запрос обслуживается, соединения остаются активными для повторного использования другими запросами, которые получает приложение. Это означает, что, скорее всего, если приложение непрерывно получает веб-запросы 24 x 7, соединение также будет поддерживаться в рабочем состоянии и будет отключено только после перезапуска mysqld или httpd, что может не произойти даже через несколько месяцев.
  • Поскольку все пользователи приложения, скажем, около 20 пользователей одновременно, используют одни и те же серверы Apache и файлы приложений Laravel (я полагаю, я могу назвать это экземпляром приложения), все 20 пользователей будут обслуживаться через одно и то же соединение с базой данных. и сеанс базы данных.

Если все упомянутые выше варианты использования верны, то концепция блокировки базы данных кажется очень запутанной. Допустим, мы выпустим эксклюзивную блокировку, например, lock tables t1 write;он будет блокировать чтение и запись других сеансов, чтобы избежать грязных операций чтения и записи для одновременных сеансов. Однако, поскольку все 20 пользователей используют один и тот же сеанс и соединение одновременно, мы не получим необходимую безопасность параллелизма из механизма блокировки базы данных.

Вопросы:

  1. Как блокировка базы данных, явно исключительная блокировка, работают с точки зрения веб-приложений?
  2. Будет ли каждый веб-запрос, полученный в приложении Laravel, создавать новое соединение и сеанс, или будет повторно использоваться ТОЛЬКО одно соединение и сеанс?
  3. Будет ли каждое соединение с базой данных иметь только и только ОДИН сеанс одновременно?
  4. Будет ли эта команда отображать текущие активные сеансы или соединения show status wherevariable_name= 'Threads_connected'? Если он показывает текущие активные соединения, как мы можем получить текущие активные сеансы базы данных?

1

Решение

Apache не имеет ничего общего с сессиями в этом сценарии (в основном). Соединения с базой данных и сеансы обрабатываются самим php.

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

При включенном пуле соединений поток, обслуживающий запрос, запросит соединение из пула с менеджером процессов (будь то fpm или же mod_php) и он вернет имеется в наличии соединение из пула, но все равно будет по крайней мере столько же сеансов, сколько одновременных запросов (если вы не нажмете ни на один из max_ Пределы). общая справка более подробно, но в качестве основного момента:

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

Даже имея доступный пул соединений, менеджер должен выполнить некоторые операции очистки, прежде чем возвращать соединение клиенту. Одной из таких операций является разблокировка таблицы.

Вы можете обратиться к ссылка на соединения а также ссылка на постоянные соединения из mysqli расширение для получения дополнительной информации.

Однако режим работы, который вы описываете, когда несколько клиентских сеансов совместно используют соединение, возможен (и является экспериментальным) и имеет больше недостатков. Это известно как мультиплексирование сеансов.

1

Другие решения

Других решений пока нет …