< /p>
안녕하세요, 저는 항상 가장 통속적인 말로 핵심을 이해하는 지식점을 가지고 있습니다. 저는 모든 어려움이' 기초 지식' 의 깔개를 빼놓을 수 없다고 생각합니다. 현재 SpringBoot 장기 시리즈 자습서가 진행 중입니다. 입문부터 고급까지 편폭이 더 많습니다 ~
"큰사람은 우회할 수 있습니다 ~"
< P > < P > Springboot 의 기본 부분을 배우기 전에, 기본적인 사용에 대한 초보적인 인식을 가지고 있으며, 다음 몇 가지 내용은 고급 사용에 도움이 될 것이며, 먼저 기본 미들웨어의 사용과 일부 장면의 응용에 대해 설명하겠습니다. 아마 이런 기술들은 들어보신 적이 없으셔도 상관없습니다. 한 걸음 한 걸음 더 나아가겠습니다. 인내심을 가지고 보면 반드시 수확이 있을 것이다 ~지난 호에서 SpringBoot 에서 요청을 가로막는 방법을 배웠고, 이번 호에서는 MyBatis 에서 트랜잭션 관리 방법을 배우게 될 것이다. 마찬가지로, 우리는 Springboot 에 통합되었다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 인내명언) 최근 github 가 벽에 붙을 수 있기 때문에 나는 소스 코드를 국내 gitee 에 올려놓았고, 이 섹션에서는 여전히 이전 기간의 코드 < /p>
를 사용하여 그 기본 개념을 먼저 알아보겠습니다. 사실, 문제는 여기에 우리가 언급 한 mybatis 일뿐만 아니라 실제로 데이터베이스에 존재합니다. 사무는 문자 그대로 빵을 굽는 것과 같다. 몇 가지 단계를 거쳐 고객에게 완전한 빵을 제공한다. 즉 중간에 착오가 생기면 되돌려야 한다는 것이다. (윌리엄 셰익스피어, 햄릿, 지혜명언) 이 예를 들기에는 적절하지 않을 수도 있으니 우리 업무 중의 한 장면을 더 들어 주세요. 사용자가 상품을 구입하고, 먼저 주문을 하고, 주문을 마친 후 지불하고, 지불이 성공한 후 주문이 지불 성공 상태로 이동하고, 성공 페이지로 점프하는 일련의 작업은 트랜잭션이거나 성공 또는 실패입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) < /p>
위의 예를 통해 대략적인 이해를 얻은 후 그 기본 개념을 살펴 보겠습니다. < /p>
다음은 SQL 이 트랜잭션 작업을 수행하는 방법을 보여 줍니다. 다음은 < /p>
트랜잭션 작업이 없는 경우를 비교한 예입니다. < /p>
이전 시나리오를 예로 들어 사용자가 잔액을 줄이고 주문 상태를 성공으로 변경하겠습니다. 우리 프로그램이 위의 두 개의 SQL 을 실행했을 때 문제가 있다고 생각하십니까? 이것은 분명히 일을 얻어낼 수 있을 것이다, 이것은 남에게 속아 죽으면 안 된다. 문장은 잘못 보고하지 않았지만 논리가 틀렸다. 잔액이 음수가 되었기 때문이다. 이는 돈이 없는 백성이 아니다. 사용자가 너에게 돌진해 줄 것을 기대하고 있는가. (윌리엄 셰익스피어, 햄릿, 지혜명언) 그리고 주문서도 성공했습니다. 동시대일 때 얼마를 내야 하나요, 보내주실 건가요, 안 보내실 건가요? 사용자에게 시스템 문제를 알려주시겠습니까? 사장은 보고 울어서 죽었다. < /p>
따라서 절차상의 오류 (SQL 실행 오류) 와 논리적 오류 모두 다음 작업을 수행할 수 없으므로 트랜잭션이 특히 중요합니다. 그럼 SQL 은 어떻게 트랜잭션을 제출할까요? < /p>
위는 단지 예시일 뿐, 생성 중에는 mybatis 로 조작해야 한다.
< /p>
SpringBoot 에서 트랜잭션을 수행하는 것은 간단합니다. 먼저 트랜잭션 @EnableTransactionManagement 를 열고 시작 클래스에 < /p>
컨트롤러 메서드 추가:
실행이 실패할 때: < /p>
롤백 작업을 수동으로 수행했습니까? 때때로 우리는 항상 예외로 판단할 수 없고, < /p>
위의 메서드 transactionaspectsupport.currenttransactionstatus (). setrollbacks 를 통해 논리적으로 판단해야 한다 바로 이것을 하는 것이다. < /p>
사실 이 절은 거의 끝나가고 있습니다. 좀 더 말씀드리겠습니다. 사실 이 내용 이론 지식점은 여전히 많이 있습니다. 이것도 면접에서 물어보는 것을 더 좋아합니다. 왜냐하면 여기는 정말 여러분 스스로 이해하고 공부하고, 코드를 쓰면 누구나 할 수 있기 때문입니다. 하지만 모든 사람이 잘 말하고 명확하게 말하는 것은 아닙니다. 왜냐하면 < /p>
때때로 고객 피드백은 bug 이고, 피드백은 당신 쪽에 있습니다. 제가 다 좋다고 말씀하실 수 있을 겁니다. 우리가 현지이기 때문에, 온라인으로 달리는 것이 아니라, 현지에서 너 혼자 다 끝냈기 때문에 문제없다고 생각한다. 하지만 온라인은 많은 사용자들이 사용하고 있으며, 여러 사용자가 사용할 때 동시 문제가 발생하기 때문에 인터페이스 테스트 시 테스트 환경의 압력을 가해 합격한 후 온라인상에 올라야 하는 이유입니다. < /p>
그렇다면 동시 규모가 클 때 우리 데이터베이스에 어떤 문제가 발생할 수 있습니까? < /p>
자, 먼저 분실된 업데이트가 무엇인지 하나씩 말씀드리겠습니다. < /p>
한 트랜잭션이 다른 트랜잭션이 제출한 업데이트 데이터를 덮어쓰는 것을 누락된 업데이트라고 합니다. 여기에 두 가지 손실이 있다고 언급했는데, 여러분이 좀 더 직관적으로 느낄 수 있도록 저축과 인출을 예로 들어 보겠습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 돈명언) < /p>
첫 번째 손실 < /p>
먼저 역할, 트랜잭션 a, 트랜잭션 b, 계정 c 를 할당합니다. 먼저 A 는 C 에 대한 계좌 조회를 하고, 잔액은 5000, B 는 A 에 대한 조회이며, 잔액은 5000 입니다. 이때 잔액은 똑같이 문제가 없습니다. 이어 B 가 C 에 대한 저축 작업을 하고 1000 을 예금하고 B 제출 업무를 마쳤다. 이때 A 는 C 를 향해 돈을 인출하고, 1000 을 취하고, 또한 사무를 제출하고 있다. (윌리엄 셰익스피어, C, C, C, C, C, C, C) 그럼 여러분께 여쭤보세요. C 는 아직 얼마인가요? < /p>
마지막으로 A 가 계좌를 조사해 보니 4000 개에 불과했고 1000 이 빠진 것으로 나타났다. < /p>
아래에서 우리는 A 쪽에 압력을 가하고, 두 번째는 사실 위와 반대되는 것입니다. 상황은 어떻습니까? 우선 A, B 는 이전과 마찬가지로 C 를 조사했고 잔액은 5000 이었다. 이때, A 는 C 에 대해 인출 작업을 하고, 1000 을 취하고, 트랜잭션을 제출하고, B 는 A 에 대해 저금 작업을 하고, 1000 을 저축하고, 트랜잭션을 제출한다. 마지막으로 B 가 조사한 결과 계정에 6000, C 가 너무 기뻤고, 1000
위의 두 가지 상황이 모두 업데이트 분실에 해당되는 경우 < /p>
한 트랜잭션이 다른 트랜잭션을 읽고 아직 제출되지 않은 데이터를 더러운 읽기라고 합니다.
또한 위의 예를 들어보겠습니다. < /p>
이것은 좀 더 잘 이해됩니다. 트랜잭션 A 와 B, 트랜잭션 A 가 C 를 인출하고, 1000 을 취하고, 잔액이 4000 이 남았는데, 이 때 B 는 C 를 조회해 잔액을 4000 으로 읽습니다. 이때 문제가 발생했다. A 는 아직 제출되지 않은 거래이기 때문에 A 는 계좌 C 인출 작업을 롤백하고 이어서 1000 을 예금한 다음 거래를 제출했고, 이때 잔액은 6000 이었다. B 가 읽은 데이터는 4000 이므로 더러운 읽기 < /p>
한 트랜잭션이 다른 트랜잭션이 제출되기 전의 데이터와 제출된 업데이트 데이터입니다. 같은 위의 측면을 예로 들자면, 이것은 모두 이해하기 어려울 수 있습니다. < /p>
우선 트랜잭션 A 와 B, A 가 먼저 C 잔액을 조회한 후 5,000, B 조회C, 잔액 5,000, 이어서 A 가 C 에 대해 인출작업을 수행하고, 1000 을 취하고, 거래를 제출한다. 당신은, 괜 찮 아 요, 1000 과 4000, 아무 문제가 걸릴 생각할 수 있습니다. 문제 없어? 두 번 반복해서 읽었는데 결과가 일치하지 않는 것은 분명 문제가 있을 것이다. < /p>
트랜잭션은 작업 중 두 가지 쿼리를 수행합니다. 두 번째 쿼리의 결과에는 첫 번째 쿼리에 나타나지 않거나 첫 번째 쿼리에 나타나는 데이터가 없습니다. 이것은 약간 추상적이고, 마찬가지로, 위의 측면은 예 < /p>
트랜잭션 A 와 B, B 쿼리 C, 잔액 5000, A 가 C 에서 로그오프하고, 트랜잭션을 제출했습니다. 이때 B 가 다시 C 를 조회해 C 가 없어졌다는 것을 알게 되었습니다. B 트랜잭션이 두 번 질의했는데 결과가 확실히 일치하지 않았습니다. < /p>
위의 몇 가지 예를 통해 동시에서 발생할 수 있는 트랜잭션 문제를 소개하고, 트랜잭션의 특징을 요약하며, ACID
라고 하는 네 가지 특징이 있습니다.
여러 동시 트랜잭션이 동시에 데이터를 읽고 수정할 수 있도록 하는 기능으로, 격리를 통해 여러 트랜잭션이 동시에 실행될 때 교차 실행으로 인한 데이터 불일치를 방지할 수 있습니다. < /p>
트랜잭션 시작 전과 트랜잭션 종료 후 데이터베이스 무결성이 < /p>
트랜잭션 (transaction) 의 모든 작업을 손상시키지 않았습니다. 모두 완료되거나 모두 완료되지 않았습니다 < /p>
때때로 우리 시스템은 사용자를 구분해야 합니다. 즉, 서로 다른 사용자 역할이 서로 다른 리소스에 액세스할 수 있습니다. 예를 들어, 관리자는 백그라운드에 액세스할 수 있고, 일반 사용자는 포그라운드 페이지에만 액세스할 수 있습니다. 또는 로그인한 사용자만 특정 기능에 액세스할 수 있습니다. 고급 관리자는 전반적인 상황을 통제할 수 있고, 일반 관리자는 하나의 메뉴만 볼 수 있습니다. 이것은 권한 문제와 관련이 있으며, 거의 모든 시스템은 시스템 리소스의 보안을 보장하기 위해 권한 관리가 필요합니다. 다음 호에서는 Shiro 권한 프레임워크를 배우게 될 것입니다. 이는 경량 프레임워크이지만, 그 기능은 작지 않습니다. 입문부터 고급까지 여러 단계로 나누어 말씀드리겠습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 도전명언) < /p>
다음 호에서 만나요. 저를 지켜봐요. 길을 잃지 않아요 ~