저는 최근 트랜잭션을 활용한 주문 기반 프로젝트를 진행하고 있습니다. 우리 데이터베이스는 MySql을 사용하고 스토리지 엔진은 트랜잭션을 잘 지원하는 innoDB를 사용합니다. 이번 글에서는 사무와 관련된 지식에 대해 살펴보겠습니다.
왜 업무가 필요한가요?
거래는 주문 시스템, 뱅킹 시스템 등 다양한 시나리오에서 널리 사용됩니다. 다음과 같은 시나리오가 있는 경우: 사용자 A와 사용자 B는 은행의 예금자입니다. 이제 A는 B에게 500위안을 송금하려고 합니다. 그런 다음 다음 작업을 수행해야 합니다.
1. A의 계좌 잔액이 500위안 이상인지 확인하세요.
2. A 계좌에서 500위안 공제
3. B 계좌에 500위안 추가
정상적인 과정을 거쳐 A계좌에서 500이 차감되고 B계좌에 500이 추가되었습니다. 모두가 기뻐했습니다. A 계좌에서 돈이 차감된 후 시스템에 장애가 발생하면 어떻게 되나요? A는 500을 헛되이 잃었고, B는 자신이 받아야 할 500을 받지 못했습니다. 위의 경우에는 A가 돈을 빼는 것과 B가 돈을 추가하는 것이 동시에 성공하거나 동시에 실패한다는 전제조건이 숨겨져 있습니다. 그것이 바로 비즈니스에 필요한 것입니다.
거래란 무엇인가요?
거래를 정의하기보다는 거래의 특징을 이야기하는 것이 좋습니다. 우리 모두 알고 있듯이 거래는 4가지 ACID 특성을 충족해야 합니다.
1. A(원자성) 원자성. 거래의 실행은 나눌 수 없는 최소 단위로 간주됩니다. 트랜잭션의 작업은 성공적으로 실행되거나 모두 실패하여 롤백되어야 합니다.
2. C(일관성) 일관성. 트랜잭션 실행은 데이터베이스의 무결성 제약 조건을 위반해서는 안 됩니다. 위 예의 두 번째 작업을 실행한 후 시스템이 충돌하는 경우 A와 B의 총 금액이 변경되지 않음이 보장됩니다.
3. 나(격리) 격리. 일반적으로 트랜잭션 동작은 서로 영향을 주어서는 안 됩니다. 그러나 실제 상황에서는 격리 수준에 따라 트랜잭션 간의 상호 작용 정도가 영향을 받습니다. 자세한 내용은 기사의 뒷부분에서 설명하겠습니다.
4. D(내구성) 내구성. 트랜잭션이 커밋된 후에는 커밋된 트랜잭션을 디스크에 유지해야 합니다. 시스템이 충돌하더라도 제출된 데이터는 손실되어서는 안 됩니다.
4가지 트랜잭션 격리 수준
이전 기사에서 언급했듯이 트랜잭션 격리는 격리 수준에 영향을 받습니다. 그렇다면 트랜잭션의 격리 수준은 무엇입니까? 트랜잭션의 격리 수준은 트랜잭션 간의 가시성을 정의하는 트랜잭션의 "이기심" 정도라고 생각할 수 있습니다. 격리 수준은 다음과 같은 유형으로 구분됩니다.
1.커밋되지 않은 읽기(커밋되지 않은 읽기). RU 격리 수준에서는 트랜잭션 A에 의한 데이터 수정 사항이 커밋되지 않은 경우에도 트랜잭션 B에 표시됩니다. 이 문제를 더티 읽기(dirty reading)라고 합니다. 이는 격리 수준이 낮은 격리 수준으로, 실제 응용에서는 많은 문제를 일으킬 수 있으므로 일반적으로 널리 사용되지는 않습니다.
2.읽어 커밋되었습니다. RC 격리 수준에서는 더티 읽기 문제가 발생하지 않습니다. 트랜잭션 A가 데이터에 대해 수정한 내용은 제출 후 트랜잭션 B에 표시됩니다. 예를 들어 트랜잭션 B가 열리고 데이터 1을 읽은 다음 트랜잭션 A가 열리고 데이터가 2로 변경되어 제출되고 B가 읽습니다. 데이터를 다시 읽으면 최신 데이터를 읽습니다. 2. RC 격리 수준에서는 반복 불가능한 읽기 문제가 발생합니다. 이 격리 수준은 많은 데이터베이스의 기본 격리 수준입니다.
3.REPEATABLE READ(반복 읽기). RR 격리 수준에서는 반복 불가능한 읽기 문제가 없습니다. 트랜잭션 A에 의해 데이터에 대한 수정 사항이 제출된 후에는 트랜잭션 A 이전에 시작된 트랜잭션에 해당 내용이 표시되지 않습니다. 예를 들어 트랜잭션 B가 열리면 데이터 1을 읽은 다음 트랜잭션 A를 열고 데이터를 2로 변경하고 B는 데이터를 다시 읽지만 여전히 1만 읽을 수 있습니다. RR의 격리 수준에서는 팬텀 판독 문제가 발생합니다. 팬텀 읽기의 의미는 트랜잭션이 특정 범위의 값을 읽고 다른 트랜잭션이 이 범위에 새 레코드를 삽입하면 이전 트랜잭션이 이 범위의 값을 다시 읽고 새로 삽입된 데이터를 읽는다는 것입니다. Mysql의 기본 격리 수준은 RR이지만 mysql의 innoDB 엔진 갭 잠금은 팬텀 읽기 문제를 성공적으로 해결합니다.
4.SERIALIZABLE(직렬화 가능). 직렬화 가능은 가장 높은 격리 수준입니다. 이 격리 수준에서는 모든 작업이 순차적으로 실행됩니다. 이 격리 수준에서는 읽은 데이터의 모든 행이 잠기므로 잠금 획득 문제가 많이 발생하고 성능이 최악이 됩니다.
4가지 격리 수준에 대한 이해를 돕기 위해 다음 예를 참조하세요. 그림 1에서 볼 수 있듯이 트랜잭션 A와 트랜잭션 B가 차례로 열리고 데이터 1이 여러 번 업데이트됩니다. 4명의 악당이 서로 다른 시간에 거래를 시작합니다. 데이터 1에서 어떤 값을 볼 수 있나요?
사진 1
첫 번째 악당은 1~20 사이의 숫자를 읽을 수 있습니다. 커밋되지 않은 읽기의 격리 수준에서는 다른 트랜잭션에 의한 데이터 수정 사항도 현재 트랜잭션에서 볼 수 있습니다. 두 번째 악당은 1, 10, 20을 읽을 수 있습니다. 그는 다른 트랜잭션에 의해 제출된 데이터만 읽을 수 있습니다. 세 번째 악당이 읽는 데이터는 자신의 트랜잭션이 시작된 시간에 따라 달라집니다. 트랜잭션이 시작될 때 읽은 값은 트랜잭션이 커밋되기 전에 읽은 값이 됩니다. 네 번째 악당은 A 끝과 B 시작 사이에 켜져 있을 때만 데이터를 읽을 수 있습니다. 그러나 트랜잭션 A와 트랜잭션 B가 실행되는 동안에는 데이터를 읽을 수 없습니다. 데이터를 읽을 때 네 번째 악당을 잠가야 하기 때문에 트랜잭션 A와 B가 실행되는 동안 데이터의 쓰기 잠금이 점유되어 네 번째 악당이 잠금을 기다리게 됩니다.
그림 2에는 다양한 격리 수준에서 직면하는 문제가 나열되어 있습니다.
사진 2
분명히 격리 수준이 높을수록 리소스 소비(잠금)가 커지므로 동시성 성능이 낮아집니다. 정확하게 말하면 직렬화 가능 격리 수준에서는 동시성이 없습니다.
사진 3
MySql의 트랜잭션
트랜잭션 구현은 데이터베이스 스토리지 엔진을 기반으로 합니다. 스토리지 엔진마다 트랜잭션 지원 수준이 다릅니다. mysql에서 트랜잭션을 지원하는 스토리지 엔진에는 innoDB와 NDB가 있습니다. innoDB는 mysql의 기본 스토리지 엔진으로, 기본 격리 수준은 RR이며, RR의 격리 수준에서 한 단계 더 나아가 다중 버전 동시성 제어를 통해 반복 불가능한 읽기 문제를 해결합니다. MVCC, Multiversion Concurrency Control), 팬텀 읽기 문제를 해결하기 위해 gap lock(즉, 동시성 제어)을 사용합니다. 따라서 innoDB의 RR 격리 수준은 실제로 직렬화 수준의 효과를 달성하고 상대적으로 우수한 동시성 성능을 유지합니다.
트랜잭션의 격리는 잠금을 통해 달성되는 반면, 트랜잭션의 원자성, 일관성 및 내구성은 트랜잭션 로그를 통해 달성됩니다. 트랜잭션 로그에 관해서 제가 말해야 할 것은 다시 실행(redo)과 실행 취소(undo)입니다.
1.재실행 로그
innoDB 스토리지 엔진에서는 트랜잭션 로그가 redo 로그와 innoDB 스토리지 엔진의 로그 버퍼(InnoDB Log Buffer)를 통해 구현됩니다. 트랜잭션이 시작되면 트랜잭션의 작업이 먼저 스토리지 엔진의 로그 버퍼에 기록됩니다. 트랜잭션이 커밋되기 전에 이러한 버퍼링된 로그는 지속성을 위해 미리 디스크에 플러시되어야 합니다. 이를 DBA가 자주 호출합니다. "먼저 기록" "(미리 쓰기 로깅). 트랜잭션이 커밋된 후 버퍼 풀에 매핑된 데이터 파일이 천천히 디스크로 새로 고쳐집니다. 이때, 데이터베이스가 크래시되거나 다운된 경우, 복구를 위해 시스템을 재시작할 때, 리두 로그에 기록된 로그를 기반으로 데이터베이스를 크래시 이전 상태로 복원할 수 있다. 완료되지 않은 트랜잭션은 복구 전략에 따라 계속 제출되거나 롤백될 수 있습니다.
시스템 시작 시 Redo 로그를 위한 지속적인 저장 공간이 할당됩니다. Redo 로그는 순차 추가 방식으로 기록되며 순차 IO를 통해 성능을 향상시킵니다. 모든 트랜잭션은 리두 로그의 저장 공간을 공유합니다. 해당 리두 로그는 명령문의 실행 순서에 따라 교대로 함께 기록됩니다. 다음은 간단한 예입니다.
기록 1:
기록 2:
기록 3:
기록 4:
기록 5:
2.실행 취소
실행 취소 로그는 주로 트랜잭션 롤백을 담당합니다. 트랜잭션 실행 과정에서는 Redo 로그 외에 일정량의 Undo 로그도 기록됩니다. Undo 로그는 각 작업 이전의 데이터 상태를 기록하며, 트랜잭션 실행 중 롤백이 필요한 경우 Undo 로그를 기반으로 롤백 작업을 수행할 수 있습니다. 단일 트랜잭션의 롤백은 현재 트랜잭션에서 수행한 작업만 롤백하며 다른 트랜잭션에서 수행한 작업에는 영향을 주지 않습니다.
Undo+Redo 트랜잭션의 단순화된 과정은 다음과 같습니다
A와 B라는 두 개의 값이 있고 값이 1과 2라고 가정합니다
1. 거래 시작;
2. 로그를 실행 취소하려면 A=1을 기록하세요.
3. 업데이트 A = 3
4. 로그를 다시 실행하려면 A=3을 기록하세요.
5. 로그를 실행 취소하려면 B=2를 기록하세요.6. 업데이트 B = 4
7. 로그를 다시 실행하려면 레코드 B = 4입니다.
8. 디스크에 재실행 로그 플러시9. 커밋
1~8단계에서 시스템이 다운되고 트랜잭션이 커밋되지 않은 경우 트랜잭션은 디스크의 데이터에 아무런 영향을 미치지 않습니다. 8~9 사이로 다운되면 복구 후 롤백을 선택할 수도 있고, 이때 리두 로그가 지속되었기 때문에 트랜잭션 제출을 계속 완료하도록 선택할 수도 있습니다. 9 이후 시스템이 충돌하고 메모리 맵의 변경된 데이터가 디스크로 다시 플러시되지 않으면 시스템이 복구된 후 다시 실행 로그에 따라 데이터가 디스크로 다시 플러시될 수 있습니다.
그래서 redo 로그는 실제로 트랜잭션의 내구성과 일관성을 보장하는 반면, undo 로그는 트랜잭션의 원자성을 보장합니다. 분산거래 분산 트랜잭션을 구현하는 방법에는 여러 가지가 있습니다. innoDB에서 제공하는 기본 트랜잭션 지원을 사용하거나 메시지 대기열을 사용하여 분산 트랜잭션의 궁극적인 일관성을 달성할 수 있습니다. 여기서는 주로 innoDB의 분산 트랜잭션 지원에 대해 이야기합니다. 그림과 같이 mysql의 분산 트랜잭션 모델입니다. 모델은 애플리케이션(AP), 리소스 관리자(RM), 트랜잭션 관리자(TM)의 세 부분으로 나뉩니다. 애플리케이션은 거래의 경계를 정의하고 수행해야 할 거래를 지정합니다. 리소스 관리자는 트랜잭션에 액세스하는 방법을 제공합니다. 일반적으로 데이터베이스는 리소스 관리자입니다.
요약
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
