안녕하십니까, 나는 오리입니다 :
오늘은 멀티 스레드 애플리케이션 시나리오가 업무를 봄 실제 주입니다 :
이전은 원칙에 대해 이야기 주로 시작 및 실행 거래에 대한 (데이터베이스 링크, 격리 수준, ThreadLocal를 쓰레드 범위).
https://blog.csdn.net/Angry_Mills/article/details/82502288
분석의 실용적인 관점에서 다음과 같습니다.
다음 장면 데모 코드 주소 :
https://gitee.com/fireduck_admin/demo-mutithread.git
1. 시뮬레이션 시나리오
1.1 방법 트랜잭션 주석의 제출 마스터 스레드 트랜잭션 새로운 스레드 실시 추가하지
메인 스레드와 자식 스레드 트랜잭션 별도로 전송을 (자식 스레드는 메인 스레드 제출 출원)
의 경우 1.2 플러스 트랜잭션 주석 저작 마스터 스레드 트랜잭션 새로운 스레드 실시 어디
메인 쓰레드와 하위 스레드 업무 와 함께 제출
주석 유일한 방법은 상황에 다음 사항을 고려
1.3 정상, 비정상 자식 스레드의 메인 스레드
새 스레드 방식을 추가하는 하위 스레드 실행 방법의 관점에서 트랜잭션 주석없이, 자식 스레드가 비 트랜잭션에서 실행되는
노트의 1.4 비동기 사용 springboot, 주 스레드, 플러스 거래 메모, 업무없이 하위 스레드는 노트
메인 쓰레드와 자식 스레드 업무 와 함께 제출
비동기 노트의 1.5 용도의 springboot, 메인 쓰레드 플러스 거래 정보, 거래 노트없이 하위 스레드, 하위 스레드 예외
메인 스레드와 자식 스레드 트랜잭션이 커밋
1.6 비동기 노트의 springboot를 사용하여, 플러스 메인 스레드의 업무 노트, 플러스 거래 하위 스레드 주석 @Transactional (전파 = Propagation.REQUIRES_NEW)
메인 쓰레드와 트랜잭션이 자식 스레드 제출 된이 (자식 스레드 스레드가 황제를 제출 제출)
비동기 코멘트 springboot를 사용하여 1.7, 마스터 코멘트 스레드 거래, 플러스 거래 하위 스레드 주석을 추가 @Transactional (전파 = Propagation.REQUIRES_NEW), 비정상적인 아이 thread
메인 쓰레드와 자식 스레드 트랜잭션이 커밋되지 않은
노트 1.8 비동기 사용 springboot 플러스 메인 스레드의 업무 노트, 하위 스레드 플러스 거래 주석 @ 트랜잭션 (P = 전파 ropagation.REQUIRES_NEW) 이상 메인 쓰레드
주 스레드 확약그리고 아이 thread 업무가 제출
요약.
비동기 구성 Propagation.REQUIRES_NEW, 사용주의 사항 메인 쓰레드와 자식 스레드는 정말 두 개의 서로 다른 거래되고 제출했다.
그러나 비정상적인 자식 스레드,하지만 두 사람은 롤백됩니다. 때문에 비정상적인 롤백에 자식 스레드,이 문제가되지 않습니다. 하지만 , 예외가 메인 쓰레드에 발생 , 메인 쓰레드는 롤백을 따랐다.
우리가 생각할 수있는 예외가 롤백에게 전체 트랜잭션의 하위 스레드의 원인이됩니다, 중첩 된 다중 스레드 거래 .
그러나 더 이상 실행 트랜잭션이 직접 제출되지 않을 경우 자식 스레드에 관계없이 메인 스레드의 이상입니다 .
2. 실제 장면
이러한 장면, 사용자 동수 지급가 발생하여 우리는 동기 인터페이스되기 전에, 이번에는 타사 지불 인터페이스 (예 : Alipay의 같은 인터페이스를) 요청, 이번에는 문제가있다.
지불하기 때문에 비동기 콜백 너무 빨리 , 주문 번호와 데이터베이스의 결과로 덜 데이터 (찾을 스토리지에 제출되지 않은 데이터를 ).
이 비동기 방법은 타사 데이터베이스를 호출하기 전에 인터페이스가 저장 (하위 스레드 트랜잭션 커밋)가 있는지 확인하기 위해 주로 이루어졌다에 창고 운영의 생각을 분명하지 않다 할 수있는 서비스.
우리가 1.7 위의 방법을 채택 할 수있는이 시간, 주 스레드의 우선 순위보다 자식 스레드가 제출하지만 경우에도 그것이 실행의 특정 하위 스레드가 빨리 콜백보다 보장 할 수 없습니다 .
3. 개선
일반 타사 콜백 인터페이스는 타임 아웃 시간을 가지고, 그는 어떤 논리적 인 처리를하고 싶지 않습니다. 긴만큼 수신 된 메시지는 성공에 반환됩니다.
그들은 성공적으로 콜백 반환을받은 후, 별도로 동안 비동기 비즈니스 로직을 메시지 처리 및 서비스 로직을 받게됩니다.
이 시간이 창고에 넣어되지 않은 경우는 캐시에 고유 식별 (주문 번호와 콜백 매개 변수) 콜백.
자식 스레드 저장 후도 비슷한 작업을 수행가 (콜백 먼저이 설명)하는 경우 쿼리 캐시 주문 번호는 다음 비동기 통지 된 invoke 수동으로 콜백 매개 변수를 얻을 수 있습니다.
물론,이 가능성이 극단적 인 경우, 단지 쿼리를 완료 콜백 방법, 동시에 캐시, 단지 스토리지 액세스를 캐시 / 자식 스레드를 넣어. 원인은 아직 캐시 주문 번호에 존재합니다.
문제의이 매우 낮은 확률, 당신은 시간 지연 보상 프로그램 (1 시간 한 번) 실행할 수 있습니다.
