Как я могу предотвратить параллелизм при записи и чтении из моей БД?
У меня есть таблица с информацией для входа и регистрации пользователя. Поэтому, когда два пользователя последовательно пытаются добавить свои данные:
-
Будут ли обновляться и конфликты записи, и таблица?
-
Использование потоков для этих записей — плохая идея. Что касается каждой записи, будет создан новый поток, и он будет забивать сервер. Является ли сервер ответственным за управление им самостоятельно?
-
Является ли блокировка стола хорошей идеей?
Мой бэкэнд работает на PHP / Apache с MySQL (InnoDB) для базы данных.
Решение
Реляционные базы данных разработаны, чтобы избежать таких условий. Вам не нужно беспокоиться о них, если вы не разрабатываете свою собственную реляционную базу данных с нуля.
Короче говоря, просто знайте: каждый раз, когда начинается запись, происходит блокировка на уровне строки. Если другая транзакция хочет выполнить запись в эту же строку, она должна ждать, пока первая транзакция не снимет блокировку. Это фундаментальная часть реляционных баз данных. Вам не нужно добавлять блокировку, потому что они уже подумали об этом 🙂
Вы можете прочитать больше о том, как MySQL выполняет блокировки, чтобы избежать взаимоблокировок и других ошибок транзакций. Вот.
Другие решения
Если вы действительно параноики по этому поводу или, возможно, вы делаете несколько вещей, когда регистрируете пользователя и хотите, чтобы это было сделано атомарно, вы можете захотеть взглянуть на использование транзакций в MySQL. Здесь есть достойный отзыв о сделках http://www.mysqltutorial.org/mysql-transaction.aspx
BEGIN;
do related reads/writes to the data
COMMIT;
Внутри этой «транзакции» соединение видит согласованное представление данных и не позволяет кому-либо еще вмешиваться в это представление.
Есть исключения. Основным является
BEGIN
SELECT ... FOR UPDATE;
fiddle with the values SELECTed
UPDATE ...; -- and change those values
COMMIT;
SELECT .. FOR UPDATE объявляет, что не должно быть подделано. Если другое соединение хочет связываться с теми же строками, ему придется подождать, пока ваш COMMIT, в это время он может обнаружить, что все изменилось, и ему нужно будет сделать что-то другое. Но, в целом, это позволяет избежать «тупика», когда две транзакции так сильно наступают друг на друга, что приходится «откатываться» назад.
С помощью таких методов «параллелизм» предотвращается лишь кратко и относительно точно. То есть, если два соединения работают с разные строки, и то и другое можно продолжить — нет необходимости «предотвращать параллелизм».
detector