무엇이 멱 등 성 입 니까?
한 자원 이 자원 자체 에 똑 같은 결 과 를 가 져 야 한다 고 여러 번 요청 했다. 즉, 자원 자체 에 미 치 는 영향 을 임의로 여러 번 수행 한 결 과 는 모두 첫 번 째 집행 의 영향 결과 와 같다.(여러 번 요청 한 자원 은 모두 같은 데이터 재고 저장 데 이 터 를 초래 합 니 다)
멱 등 성 필드 생 성
네트워크 파동 은 중복 요청 을 일 으 킬 수 있 습 니 다 사용자 가 반복 적 으로 조작 하면 사용자 가 조작 할 때 여러 번 의 주문 거래 를 촉발 하지 않 을 수도 있 고 심지어 응답 하지 않 아 여러 번 의 거래 를 촉발 할 수도 있다 애플 리 케 이 션 은 실효 또는 시간 초과 재 시도 메커니즘 (Nginx 재 시도, RPC 재 시도 또는 업무 층 재 시도 등) 을 사용 했다.
페이지 중복 리 셋 브 라 우 저 후퇴 단 추 를 사용 하여 이전 작업 을 반복 하여 양식 을 중복 제출 합 니 다 브 라 우 저 기록 을 사용 하여 양식 중복 제출 브 라 우 저 에서 반복 되 는 HTTP 요청 정시 임무 중복 집행 사용자 가 제출 단 추 를 더 블 클릭 멱 등 은 어느 층 에서 실현 합 니까?
: , 멱 등 성 해결 방안
단 추 는 한 번 만 조작 할 수 있 습 니 다. 보통 제출 한 후에 단 추 를 회색 이나 loding 상태 로 두 고 사용자 가 중복 클릭 으로 인해 발생 하 는 중복 기록 을 제거 합 니 다. 예 를 들 어 조작 을 추가 하고 두 번 클릭 해서 두 개의 기록 이 발생 합 니 다 token 메커니즘 기능 에 서 는 중복 제출 을 허용 하지만 중복 제출 이 부작용 이 발생 하지 않도록 해 야 한다. 예 를 들 어 n 번 을 클릭 하면 하나의 기록 만 생 긴 다. 구체 적 으로 실현 하면 페이지 에 들 어 갈 때 token 을 신청 한 다음 에 뒤의 모든 요청 은 이 token 을 가 져 가 고 백 엔 드 는 token 에 따라 중복 요청 을 피 하 는 것 이다. Post / Redirect / Get 모드 를 사용 하여 제출 후 페이지 의 방향 을 바 꿉 니 다. 이것 이 바로 Post - Redirect - Get (PRG) 모드 입 니 다. 쉽게 말 하면 사용자 가 연결 폼 을 제출 한 후에 방향 을 바 꾸 는 정보 페이지 로 이동 하면 사용자 가 F5 새로 고침 으로 인 한 중복 제출 을 피 할 수 있 고 브 라 우 저 폼 이 중복 제출 되 는 경고 도 나타 나 지 않 습 니 다.브 라 우 저 에 따라 전진 과 후퇴 로 인해 같은 중복 제출 문 제 를 없 앨 수 있다. session 에 특수 로 고 를 서버 에 저장 하고 유일한 식별 자 를 생 성하 여 session 에 저장 하 는 동시에 전단 에서 이 식별 자의 값 을 가 져 와 폼 의 숨겨 진 곳 에 기록 합 니 다. 사용자 가 정 보 를 입력 한 후에 같이 제출 하려 면 누 르 십시오. 서버 에서 폼 에 숨겨 진 필드 의 값 을 가 져 옵 니 다. session 의 유일한 식별 자 와 비교 하면 같은 설명 은 처음 제출 합 니 다.이번 요청 을 처리 한 후, session 의 유일한 식별 자 를 제거 하고, 같 지 않 으 면 중복 제출 이 며, 더 이상 처리 하지 않 는 다 는 것 을 표시 합 니 다. 유일한 색인 을 사용 하여 더러 운 데 이 터 를 추가 하 는 것 을 방지 하고 데이터 가 중복 되면 데이터 베 이 스 를 삽입 하면 이상 이 발생 하여 더러 운 데이터 가 발생 하지 않도록 합 니 다. Token + Redis 는 주문 서 를 예 로 들 수 있 습 니 다. 첫 번 째 단계: 주문 서 를 제출 하기 전에 주문 시스템 이 사용자 정보 에 따라 백 엔 드 에 Token 을 신청 하 는 요청 을 해 야 합 니 다. 백 엔 드 는 Token 을 Redis 캐 시 에 저장 하여 두 번 째 단계 에 사용 해 야 합 니 다.두 번 째 단계: 주문 시스템 이 신청 한 token 을 들 고 주문 서 를 제출 합 니 다. 백 엔 드 는 Redis 에 이 Token 이 존재 하 는 지 확인 합 니 다. 존재 하면 첫 번 째 주문 서 를 제출 하 라 는 요청 을 표시 하고 논리 적 처 리 를 시작 합 니 다. 논 리 를 처리 한 후에 Redis 에 있 는 Token 을 삭제 합 니 다. 중복 요청 이 있 을 때 캐 시 에 Token 이 존재 하 는 지 확인 합 니 다.불법 청 구 는 존재 하지 않 습 니 다. 상태 기 는 업데이트 작업 을 대상 으로 한다. 예 를 들 어 업무 상 주문 상 태 를 수정 해 야 한다. 예 를 들 어 주문 상 태 는 지불 대기, 지불 중, 지불 성공, 지불 실패, 주문 시간 초과 종료 등 이다. 디자인 할 때 상태의 단 방향 변화 (불가 역) 만 지원 하 는 것 이 좋다. 즉, 업데이트 할 때 where 조건 에 status = {상태} 를 추가 할 수 있다.여러 번 호출 하면 실제로 도 한 번 만 실 행 됩 니 다. 낙관적 인 자 물 쇠 는 기 존 데 이 터 를 업데이트 하면 잠 금 업 데 이 트 를 할 수 있 고 표 구 조 를 디자인 할 때 낙관적 인 자 물 쇠 를 사용 할 수 있 습 니 다. version 을 통 해 낙관적 인 자 물 쇠 를 만 들 수 있 습 니 다. 그러면 집행 효율 도 확보 할 수 있 고 멱 등 도 확보 할 수 있 습 니 다. 낙관적 인 자물쇠 의 version 버 전 은 업무 데 이 터 를 업데이트 할 때 증가 update table set version = version + 1 where id = #{id} and version = #{version} 예 를 들 어야 합 니 다.첫 번 째 요청 은 현재 상품 의 version 버 전 번 호 를 가 져 옵 니 다. 받 은 version 은 1 입 니 다. 이 어 첫 번 째 요청 으로 인해 상품 의 version 을 업데이트 하지 않 았 습 니 다. 두 번 째 요청 으로 얻 은 version 도 1 입 니 다. 이때 첫 번 째 요청 작업 이 업 데 이 트 될 때 version 을 가 져 와 서 조건 으로 업 데 이 트 를 추가 하면 상품 의 version 은 2 가 됩 니 다.두 번 째 요청 이 업 데 이 트 를 조작 하 러 갔 을 때 분명히 version 이 일치 하지 않 아 업데이트 에 실 패 했 습 니 다. 방 중 표 는 지불 을 예 로 들 면 유일한 메 인 키 를 사용 하여 방 중 표 의 유일한 색인 을 만 듭 니 다. 예 를 들 어 주문 번 호 를 방 중 표 의 유일한 색인 으로 사용 합 니 다. 모든 요청 은 주문 번호 에 따라 방 중 표 에 데 이 터 를 삽입 하고 성공 적 인 설명 을 삽입 하면 뒤의 업 무 를 처리 할 수 있 습 니 다. 업무 논 리 를 처리 한 후에 방 중 표 의 주문 번호 데 이 터 를 삭제 합 니 다. 나중에 중복 요청 이 있 으 면방 중 표 의 유일한 색인 으로 인해 삽입 에 실 패 했 고 직접 작업 에 실 패 했 습 니 다. 첫 번 째 로 결 과 를 되 돌려 달라 고 요청 할 때 까지 방 중 표 역할 은 잠 금 기능 임 을 알 수 있 습 니 다. : select + insert or update 이 방안 은 조작 하기 전에 먼저 조회 하고 요구 에 부 합 된 다음 에 삽입 하 는 것 입 니 다. 이 방안 은 병발 하지 않 은 시스템 에서 멱 등 문 제 를 해결 할 수 있 습 니 다. 단일 JVM 이 병발 할 때 JVM 잠 금 으로 멱 등 성 을 확보 할 수 있 고 분포 식 환경 에서 멱 등 성 을 보장 할 수 없 으 며 분포 식 으로 보증 할 수 있 습 니 다. 분포 식 자 물 쇠 는 진입 방법 에 들 어 갈 때 먼저 자 물 쇠 를 가 져 오고 자 물 쇠 를 가 져 오 면 뒤의 절 차 를 계속 합 니 다. 자 물 쇠 를 얻 지 못 하면 자 물 쇠 를 풀 때 까지 기다 리 고 자 물 쇠 를 가 져 올 때 까지 자 물 쇠 를 풀 어 줍 니 다.이 해결 방안 은 분포 식 시스템 의 멱 등 성 을 해결 하 는 데 쓸 수 있다.자주 사용 하 는 분포 식 잠 금 실현 방안 은 Redis 와 Zookeeper 등 도구 입 니 다. 분포 식 잠 금 을 사용 하면 무 게 를 방지 하고 캐 시 에 보 내 는 것 과 유사 합 니 다. 효율 적 이 고 사고 방향 이 같 으 며 같은 시간 에 한 번 만 지불 요 구 를 완성 할 수 있 습 니 다. : , 버퍼 대기 열 은 요청 을 신속하게 받 은 후 버퍼 대기 열 에 넣 고 비동기 작업 처리 대기 열 에 있 는 데 이 터 를 추가 로 사용 하여 중복 되 는 요청 을 걸 러 냅 니 다. 이 솔 루 션 은 동기 화 처 리 를 비동기 처리, 높 은 스루풋 으로 바 꾸 는 것 이 장점 입 니 다. 단점 은 요청 결 과 를 제때에 되 돌려 주지 못 하고 후속 적 인 문의 처리 결과 가 필요 합 니 다. 전역 유일 번호, 예 를 들 어 source 소스 + 유일한 시리 얼 번 호 를 통 해 백 엔 드 에 전송 되 고 백 엔 드 는 요청 이 중복 되 는 지 여 부 를 판단 합 니 다. 동시 다발 시 하나의 요청 만 처리 할 수 있 습 니 다. 다른 동시 다발 요청 은 요청 이 중복 되 거나 앞에서 요청 이 완 료 된 후에 실 행 됩 니 다.
