고마워요~사실 이해가 틀렸네요~ 이런 정보는 어디서 보셨는지 모르겠네요... 사실... 동시성 문제 해결은... 단순한 데이터베이스 잠금이 아닙니다... 일련의 캐싱, 전환, 필터링 등을 통해 구현됩니다. ~ 그리고 멱등성은 동일한 작업에서 사용자 중 한 명만 적용된다는 데 동의합니다. 사용자가 난폭하게 주문하면 실제로는 하나만 적용됩니다... 해결 방법은 매우 간단합니다 ~ 두 개의 레이어로 나뉩니다... 프런트 엔드 제어 지점을 다시 클릭할 수 없습니다... 백엔드가 고유하게 식별합니다 요청 ~ 캐시에 저장 ~ 그 이후에는 실제로 하나만 적용됩니다 ~
지난 몇 번 질문하신 내용은 교과서에서 다루는 내용과 좀 더 비슷하다고 생각합니다. 타오바오가 작성한 플래시 세일 원칙. 최근 출간된 높은 동시성 하의 레드엔벨로프 시스템 아키텍처와 실제 생산 과정에서 요약된 기타 실무 정보~
인쇄 주문에는 멱등성이 필요한 것으로 알고 있습니다. 이는 동일한 주문을 몇 번 인쇄하더라도 다른 주문의 인쇄에는 영향을 미치지 않습니다. 이는 제어하기 쉽습니다. 주문을 인쇄할 때 데이터를 애플리케이션 측으로 가져와서 처리하면 데이터베이스 측에서 조각화가 발생하지 않습니다.
균등은 비즈니스 시스템에 대한 호출을 의미합니다. 여러 호출이 발생하더라도 비즈니스 시스템에는 영향이 없습니다. 이 요구 사항은 분산 시스템에서 매우 중요합니다. 왜냐하면 분산 시스템에서는 데이터베이스 자체가 트랜잭션 제어를 완료할 수 없기 때문입니다. 일부 메시지 대기열과 비동기 호출은 상태가 불분명할 때 원격 호출을 수행하는 데 사용됩니다. 서비스가 동일성을 보장하지 않으면 재시도 메커니즘을 사용할 수 없습니다.
주문을 생성하는 시나리오는 공평하지 않습니다. 여러 번 호출하면 여러 주문이 나타납니다. 일반적인 접근 방식은 주문을 생성하기 전에 전달된 정보를 기반으로 쿼리하는 것입니다. 이미 실행된 경우 중복 주문을 방지하기 위해 호출 성공 정보를 직접 반환합니다.
발기부전은 HTTP의 GET 요청으로 이해될 수 있으며(동일한 URL을 방문할 때 콘텐츠가 다를 때도 있다는 말은 하지 마세요), POST 요청은 멱등성이 아닙니다. 따라서 대부분의 경우 GET을 사용하는 것이 좋습니다! POST는 본문 데이터를 숨기기 때문에 안전하다고 생각하지 마십시오.
Impotence는 분산 시스템에서 타임아웃과 같은 네트워크 사유가 발생할 경우 서버가 성공적으로 실행되었는지 실패했는지 클라이언트가 알 수 없는 문제를 해결합니다. 이때 클라이언트는 다시 시도해야 합니다. 인터페이스가 멱등성이 아닌 경우. 예상치 못한 결과가 나올 수 있습니다.
간단히 말하면 인터페이스가 멱등적이라면 한 번 호출하든 여러 번 호출하든 효과는 동일합니다. 예를 들어
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
고마워요~사실 이해가 틀렸네요~ 이런 정보는 어디서 보셨는지 모르겠네요...
사실... 동시성 문제 해결은... 단순한 데이터베이스 잠금이 아닙니다... 일련의 캐싱, 전환, 필터링 등을 통해 구현됩니다. ~
그리고 멱등성은 동일한 작업에서 사용자 중 한 명만 적용된다는 데 동의합니다. 사용자가 난폭하게 주문하면 실제로는 하나만 적용됩니다... 해결 방법은 매우 간단합니다 ~ 두 개의 레이어로 나뉩니다... 프런트 엔드 제어 지점을 다시 클릭할 수 없습니다... 백엔드가 고유하게 식별합니다 요청 ~ 캐시에 저장 ~ 그 이후에는 실제로 하나만 적용됩니다 ~
지난 몇 번 질문하신 내용은 교과서에서 다루는 내용과 좀 더 비슷하다고 생각합니다. 타오바오가 작성한 플래시 세일 원칙. 최근 출간된 높은 동시성 하의 레드엔벨로프 시스템 아키텍처와 실제 생산 과정에서 요약된 기타 실무 정보~
멱등성은 시스템 인터페이스가 외부 세계에 대해 약속하는 것입니다. 이는 인터페이스가 성공적으로 호출되는 한 여러 외부 호출이 시스템에 동일한 영향을 미칠 것이라고 약속합니다. 멱등성은 외부 호출의 실패를 정상으로 간주하고, 실패 후에는 반드시 재시도를 하게 됩니다.
당신이 언급한 주문 단편화 방지에 관해 제가 아는 것은 그것이 거래에 의존한다는 것뿐입니다. Alipay와 같은 동시성 높은 환경에서는 무엇을 사용하는지 모르겠습니다.
토큰을 사용하면 CSRF를 방지할 수 있을 뿐만 아니라 UI 수준에서 재생도 방지할 수 있습니다.
멱등성을 이해하는 간단한 예
으아악인쇄 주문에는 멱등성이 필요한 것으로 알고 있습니다. 이는 동일한 주문을 몇 번 인쇄하더라도 다른 주문의 인쇄에는 영향을 미치지 않습니다. 이는 제어하기 쉽습니다. 주문을 인쇄할 때 데이터를 애플리케이션 측으로 가져와서 처리하면 데이터베이스 측에서 조각화가 발생하지 않습니다.
균등은 비즈니스 시스템에 대한 호출을 의미합니다. 여러 호출이 발생하더라도 비즈니스 시스템에는 영향이 없습니다.
이 요구 사항은 분산 시스템에서 매우 중요합니다. 왜냐하면 분산 시스템에서는 데이터베이스 자체가 트랜잭션 제어를 완료할 수 없기 때문입니다. 일부 메시지 대기열과 비동기 호출은 상태가 불분명할 때 원격 호출을 수행하는 데 사용됩니다. 서비스가 동일성을 보장하지 않으면 재시도 메커니즘을 사용할 수 없습니다.
주문을 생성하는 시나리오는 공평하지 않습니다. 여러 번 호출하면 여러 주문이 나타납니다. 일반적인 접근 방식은 주문을 생성하기 전에 전달된 정보를 기반으로 쿼리하는 것입니다. 이미 실행된 경우 중복 주문을 방지하기 위해 호출 성공 정보를 직접 반환합니다.
발기부전은 HTTP의 GET 요청으로 이해될 수 있으며(동일한 URL을 방문할 때 콘텐츠가 다를 때도 있다는 말은 하지 마세요), POST 요청은 멱등성이 아닙니다. 따라서 대부분의 경우 GET을 사용하는 것이 좋습니다! POST는 본문 데이터를 숨기기 때문에 안전하다고 생각하지 마십시오.
Impotence는 분산 시스템에서 타임아웃과 같은 네트워크 사유가 발생할 경우 서버가 성공적으로 실행되었는지 실패했는지 클라이언트가 알 수 없는 문제를 해결합니다. 이때 클라이언트는 다시 시도해야 합니다. 인터페이스가 멱등성이 아닌 경우. 예상치 못한 결과가 나올 수 있습니다.
간단히 말하면 인터페이스가 멱등적이라면 한 번 호출하든 여러 번 호출하든 효과는 동일합니다. 예를 들어
UPDATE 테이블 SET NAME="LILEI" WHERE UID='1'
으아악