집 >데이터 베이스 >MySQL 튜토리얼 >MySQL의 낙관적 잠금 및 비관적 잠금의 구체적인 구현
MySQL의 낙관적 잠금 및 비관적 잠금의 구체적인 구현
- WBOY앞으로
- 2022-09-07 14:23:172647검색
추천 학습: mysql 비디오 튜토리얼
많은 개발자는 MySQL의 낙관적 잠금과 비관적 잠금에 익숙하지 않을 수 있으며 구현 방법도 모릅니다. 이 기사에서는 두 잠금 장치의 차이점을 완전히 이해할 수 있도록 이 문제에 대한 실제 사례 데모를 제공합니다.
잠금 분류
MySQL의 중간 잠금은 범위에 따라 크게 테이블 잠금, 행 잠금, 페이지 잠금으로 구분됩니다. myisam 스토리지 엔진은 테이블 잠금만 지원하는 반면, InnoDB는 행 잠금뿐만 아니라 테이블 잠금도 어느 정도 지원합니다. 행위에 따라 공유 잠금(읽기 잠금), 배타적 잠금(쓰기 잠금), 의도 잠금으로 나눌 수 있습니다. 그들의 생각에 따르면 낙관적 잠금과 비관적 잠금으로 구분됩니다.
오늘의 기사에서는 낙관적 잠금과 비관적 잠금이 실제로 어떻게 작동하는지 보여줍니다.
테이블 구조
다음 SQL 문은 테이블의 구조입니다.
CREATE TABLE `demo`.`user` ( `id` int(10) UNSIGNED ZEROFILL NOT NULL AUTO_INCREMENT, `name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, `sex` tinyint(1) UNSIGNED NOT NULL DEFAULT 0, `email` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL, `mobile` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL, `version` int(1) NULL DEFAULT 1 COMMENT '数据版本号', PRIMARY KEY (`id`) USING BTREE ) ENGINE = InnoDB AUTO_INCREMENT = 8 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
시뮬레이트된 데이터 삽입:
BEGIN; INSERT INTO `user` VALUES (0000000001, '张三', 0, '18228937997@163.com', '18228937997', 1); INSERT INTO `user` VALUES (0000000002, '李四', 0, '1005349393@163.com', '15683202302', 1); INSERT INTO `user` VALUES (0000000003, '李四1', 0, '1005349393@163.com', '15683202302', 1); INSERT INTO `user` VALUES (0000000004, '李四2', 0, '1005349393@163.com', '15683202302', 1); INSERT INTO `user` VALUES (0000000005, '李四3', 0, '1005349393@163.com', '15683202302', 1); INSERT INTO `user` VALUES (0000000006, '李四4', 0, '1005349393@163.com', '15683202302', 1); INSERT INTO `user` VALUES (0000000007, '李四55', 0, '1005349393@163.com', '15683202302', 1); COMMIT;
테이블에 데이터.
mysql root@127.0.0.1:demo> select * from user; +----+--------+-----+---------------------+-------------+---------+ | id | name | sex | email | mobile | version | +----+--------+-----+---------------------+-------------+---------+ | 1 | 张三 | 0 | 18228937997@163.com | 18228937997 | 2 | | 2 | 李四 | 0 | 1005349393@163.com | 15683202302 | 1 | | 3 | 李四1 | 0 | 1005349393@163.com | 15683202302 | 1 | | 4 | 李四2 | 0 | 1005349393@163.com | 15683202302 | 1 | | 5 | 李四3 | 0 | 1005349393@163.com | 15683202302 | 1 | | 6 | 李四4 | 0 | 1005349393@163.com | 15683202302 | 1 | | 7 | 李四55 | 0 | 1005349393@163.com | 15683202302 | 1 | +----+--------+-----+---------------------+-------------+---------+ 7 rows in set Time: 0.011s
비관적 잠금
비관적 잠금, 상대적으로 부정적인 잠금 처리 방법입니다. 데이터 운용 시 직접 Lock을 확보하세요. 진행 중인 다른 트랜잭션은 잠금을 보유한 트랜잭션이 잠금을 해제할 때까지 기다립니다.
이 처리 방법은 데이터의 일관성을 최대한 보장할 수 있지만 잠금 시간 초과 및 낮은 동시성 등의 문제가 쉽게 발생할 수 있습니다. 먼저 트랜잭션 1을 시작하고 id=1로 데이터를 업데이트합니다. 이때 트랜잭션을 제출하지 않습니다.
mysql root@127.0.0.1:demo> begin; Query OK, 0 rows affected Time: 0.002s mysql root@127.0.0.1:demo> update `user` set name = '张三111111'where id = 1; Query OK, 1 row affected Time: 0.004s
그런 다음 트랜잭션 2를 시작하고 id=1로 데이터를 업데이트하여 이때 무슨 일이 일어날지 살펴보겠습니다.
mysql root@127.0.0.1:demo> begin; Query OK, 0 rows affected Time: 0.002s mysql root@127.0.0.1:demo> update `user` set sex = 1 where id = 1;
update 문을 실행한 후에는 대기 상태가 되어 SQL 문이 즉시 실행되지 않습니다. 이는 일단 트랜잭션이 커밋되지 않으면 id=1인 데이터에 해당하는 쓰기 잠금이 해제되기 때문입니다. 출시된.
효과는 다음과 같습니다.
위의 예를 통해 비관적 잠금의 구현 과정을 직관적으로 느낄 수 있습니다.
Optimistic lock
Optimistic lock은 데이터가 정상적인 상황에서는 충돌을 일으키지 않는다고 믿습니다. 데이터 충돌은 데이터가 수정될 때만 처리됩니다. 여기서 갈등은 어떻게 발견됩니까? 일반적인 방법은 데이터 행에 버전 번호나 타임스탬프와 같은 필드를 추가하는 것입니다. (이 글에서는 버전을 좋은 버전으로 사용하고, 같은 이유로 타임스탬프를 사용합니다.)
낙관적 잠금의 구현 원리:
- 트랜잭션이 데이터를 읽을 때 해당 버전 번호 필드를 읽는다고 가정합니다. 현재 버전 번호는 1입니다.
- 다른 트랜잭션도 동일한 읽기 작업을 수행합니다. 트랜잭션이 커밋되면 버전 번호는 +1이 되며, 이때 데이터 행의 버전 번호는 2입니다.
두 번째 트랜잭션에서 수정 작업을 수행할 때 비즈니스 데이터를 기반으로 조건이 만들어지며, where 조건으로 기본적으로 버전 번호가 추가됩니다. 이때 수정 문의 버전 번호 필드가 where 조건을 충족하지 않아 트랜잭션이 실행되지 않습니다. 이러한 방식으로 잠금 기능이 달성됩니다.
클라이언트 1:
mysql root@127.0.0.1:demo> select * from user where id = 1; +----+------------+-----+---------------------+-------------+---------+ | id | name | sex | email | mobile | version | +----+------------+-----+---------------------+-------------+---------+ | 1 | 张三111111 | 0 | 18228937997@163.com | 18228937997 | 1 | +----+------------+-----+---------------------+-------------+---------+ 1 row in set Time: 0.012s mysql root@127.0.0.1:demo> update `user` set name = '事务一', version = version + 1 where id = 1 and version = 1; Query OK, 1 row affected Time: 0.008s mysql root@127.0.0.1:demo> select * from user where id = 1; +----+--------+-----+---------------------+-------------+---------+ | id | name | sex | email | mobile | version | +----+--------+-----+---------------------+-------------+---------+ | 1 | 事务一 | 1 | 18228937997@163.com | 18228937997 | 2 | +----+--------+-----+---------------------+-------------+---------+ 1 row in set Time: 0.009s
업데이트 문 실행 순서는 클라이언트 2가 select를 실행한 이후에 이루어져야 합니다.
클라이언트 2:
mysql root@127.0.0.1:demo> select * from user where id = 1; +----+------------+-----+---------------------+-------------+---------+ | id | name | sex | email | mobile | version | +----+------------+-----+---------------------+-------------+---------+ | 1 | 张三111111 | 1 | 18228937997@163.com | 18228937997 | 1 | +----+------------+-----+---------------------+-------------+---------+ 1 row in set Time: 0.015s mysql root@127.0.0.1:demo> update `user` set name = '事务二', version = version + 1 where id = 1 and version = 1; Query OK, 0 rows affected Time: 0.003s mysql root@127.0.0.1:demo> select * from user where id = 1; +----+--------+-----+---------------------+-------------+---------+ | id | name | sex | email | mobile | version | +----+--------+-----+---------------------+-------------+---------+ | 1 | 事务一 | 1 | 18228937997@163.com | 18228937997 | 2 | +----+--------+-----+---------------------+-------------+---------+ 1 row in set Time: 0.012s
이때 업데이트로 반환된 구조에 따르면 영향을 받은 행의 개수가 0임을 알 수 있습니다. 동시에 선택 쿼리 이후 캐시백 데이터는 또한 거래 1의 데이터입니다.
적용 가능한 시나리오
비관적 잠금: 쓰기 작업이 빈번한 시나리오에 더 적합합니다. 읽기 작업이 많은 경우 읽을 때마다 잠금이 수행되므로 잠금 오버헤드가 많이 증가합니다. 그리고 시스템 처리량을 줄입니다.
낙관적 잠금: 읽기 작업이 더 자주 발생하는 경우 데이터 충돌 가능성이 높아집니다. 데이터 일관성을 보장하기 위해 애플리케이션 계층이 필요합니다. 지속적으로 데이터를 다시 획득해야 하므로 쿼리 작업 수가 많이 증가하고 시스템 처리량이 감소합니다.
요약
두 유형 모두 장점과 단점이 있습니다. 낙관적 잠금은 빈번한 읽기에 사용되고 비관적 잠금은 빈번한 쓰기에 사용됩니다.
낙관적 잠금은 쓰기 횟수가 상대적으로 적은 상황, 즉 충돌이 거의 발생하지 않는 상황에 적합합니다. 이렇게 하면 잠금 비용을 절약하고 시스템의 전체 처리량을 늘릴 수 있습니다. 그러나 충돌이 자주 발생하면 상위 계층 응용 프로그램이 계속 재시도하게 되어 실제로 성능이 저하되므로 이 경우 비관적 잠금을 사용하는 것이 더 적절합니다. 동일한 데이터 조각을 업데이트하는 경우가 많습니다. 즉, 충돌이 심각한 경우 비관적 잠금이 사용됩니다.
비관적 잠금은 강력한 일관성 시나리오에 더 적합하지만 효율성이 상대적으로 낮고 특히 읽기 동시성이 낮습니다. 낙관적 잠금은 읽기가 많고 쓰기가 적으며 동시성 충돌이 적은 시나리오에 적합합니다.
추천 학습: mysql 비디오 튜토리얼
위 내용은 MySQL의 낙관적 잠금 및 비관적 잠금의 구체적인 구현의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!