비즈니스에서 낙관론 및 비관적 잠금의 실제 적용 사례

낙관적 잠금 및 비관적 잠금의 선택은 비즈니스 시나리오 및 데이터 일관성 요구 사항에 따라 다릅니다. 1. 비관적 잠금은 데이터 충돌을 가정하고 잠금은 데이터 일관성을 보장하지만 은행 전송과 같은 높은 동시성에서는 효율성이 낮습니다. 2. 낙관적 잠금은 데이터 충돌 확률이 낮고 잠금이 추가되지 않았다고 가정하고, 업데이트 전에 데이터가 수정되었는지 여부를 확인하고 효율성이 높지만 전자 상거래 인벤토리 관리 및 포럼 주석과 같은 데이터 불일치; 3. 높은 동시성 시나리오에서 낙관적 잠금 장치와 비관적 잠금 장치, 낙관적 잠금의 첫 번째 전처리 및 최종적으로 비관적 잠금을 확인하여 효율성과 데이터 일관성을 고려할 수 있습니다. 최종 선택에는 효율성과 데이터 일관성 사이의 상충 관계가 필요합니다.

낙관적 잠금 및 비관적 잠금 장치 : 비즈니스 관행의 상충 관계 및 선택

낙관적 잠금과 비관적 잠금,이 두 개념은 신비 롭지 만 실제로 데이터베이스에 대한 동시 액세스를 처리 할 때 완전히 다른 두 가지 전략입니다. 간단히 말해서, 낙관적 잠금은 "데이터는 일반적으로 충돌하지 않는다"고 생각하지만, 비관적 잠금은 "데이터가 충돌 할 가능성이 높다"고 믿는다. 이 기사에서는 지루한 정의를 제공하지 않지만 비즈니스 시나리오에 들어가서 실제 조건에 따라 올바른 솔루션을 선택하는 방법을 확인하기 위해 비즈니스 시나리오로 안내합니다. 그것을 읽은 후에는 비즈니스 요구에 따라 오래된 드라이버와 같은 두 가지 잠금 메커니즘을 제어 할 수 있습니다.

기본부터 시작하겠습니다. 이름에서 알 수 있듯이 비관적 잠금은 항상 최악의 경우 - 동시 수정을 가정합니다. 데이터 충돌을 피하기 위해 데이터에 액세스 할 때 데이터를 직접 잠그게합니다. 일반적인 예는 데이터베이스의 트랜잭션 격리 수준과 일부 프로그래밍 언어가 제공하는 MUTEX 메커니즘입니다. 은행 계좌 이체를 상상해보십시오. 비관적 인 자물쇠는 엄격한 경비원과 같습니다. 한 명만 한 번에 작업에 입력 할 수 있으며 다른 사용자는 줄을 서서 기다릴 수 있습니다. 이것은 데이터의 일관성을 보장하지만 효율성은 ... 특히 동시성이 클 경우 대기 시간이 길다는 것을 알고 있습니다.

낙관적 잠금은 완전히 다릅니다. 데이터 충돌 가능성은 매우 낮으므로 잠금을 적극적으로 추가하지 않을 것입니다. 데이터를 업데이트하기 전에 수정되었는지 확인합니다. 수정되지 않은 경우 업데이트됩니다. 수정 된 경우 충돌을 일으키고 사용자가 다시 조정할 수 있습니다. 이는 유연한 관리자와 같습니다.이 관리자는 여러 사용자가 데이터를 동시에보고 수정하고 수정할 때만 확인을 수행 할 수 있습니다. 이것은 훨씬 더 효율적이지만 위험이 있습니다. 즉, "더러운 쓰기"가 발생할 수 있으며주의해서 처리해야합니다.

실제 사례를 살펴 보겠습니다.

사례 1 : 전자 상거래 제품 재고 관리

상품 재고는 일반적인 동시 시나리오입니다. 비관적 잠금을 사용하는 경우 사용자가 제품 페이지를 방문하거나 인벤토리를 확인할 때마다 잠금을 추가해야합니다. 낙관적 잠금은 매우 적합합니다. 버전 번호 메커니즘을 사용하여 낙관적 잠금을 달성 할 수 있습니다. 각 제품에는 버전 번호가 있으며 인벤토리가 업데이트 될 때마다 버전 번호가 일관되는지 확인하십시오. 일관성이 없다면 데이터가 수정되었고 업데이트가 거부되었음을 의미합니다. 제품 재고에 게시 된 레이블과 같습니다. 수정 수를 기록하며 레이블이 변경되지 않은 경우에만 수정할 수 있습니다.

class Product:

 def __init __ (self, id, name, stock, version) :
    self.id = id
    self.name = 이름
    self.stock = 주식
    self.version = 버전

def update_stock (self, new_stock, current_version) :
    self.version == current_version :
        self.stock = new_stock
        self.version = 1
        True # Endude Enchud Enthing :
        Return False # 업데이트 실패, 데이터가 변경되었습니다

동시 업데이트를 시뮬레이션하십시오

Product = Product (1, "iPhone", 100, 1)
Thread1 = Threading.thread (target = lambda : product.update_stock (90, 1))
Thread2 = Threading.thread (target = lambda : product.update_stock (80, 1))

thread1.start ()
Thread2.start ()
thread1.join ()
Thread2.join ()

print (f "최종 인벤토리 : {product.stock}") #결과는 스레드 실행 순서에 따라 80 또는 90이 아닐 수 있으며 낙관적 잠금의 가능한 문제를 보여줍니다.

이 코드는 파이썬을 사용하여 낙관적 잠금의 구현을 시뮬레이션합니다. 이것은 단순한 버전 일 뿐이며 실제 응용 프로그램에서 데이터베이스 트랜잭션의 원자력과 같은 문제를 고려해야합니다. 당신은 그것을 보셨습니까? 낙관적 잠금은 효율적이지만 데이터 불일치로 이어질 수 있으며 충돌을 처리하기 위해 적절한 메커니즘이 필요합니다.

사례 2 : 포럼 게시물 의견

포럼 게시물 의견, 동시성 볼륨도 매우 큽니다. 비관적 잠금 장치를 사용하는 경우 모든 의견을 잠겨 있어야합니다. 이는 너무 비효율적입니다. 낙관적 잠금도 여기에 적용됩니다. 버전 번호와 유사한 메커니즘을 사용하거나 타임 스탬프를 사용하여 데이터가 수정되었는지 여부를 결정할 수 있습니다.

사례 3 : 은행 양도 (또 다른 강조)

위에서 언급했듯이 비관적 잠금은 데이터의 일관성을 보장 할 수 있기 때문에 더 안전한 선택 인 것 같습니다. 그러나 동시성 부피가 매우 높으면 비관적 잠금의 성능 병목 현상이 매우 분명 할 것입니다. 현재 낙관적 잠금 장치와 비관적 잠금 장치를 결합하는 것을 고려할 수 있습니다. 예를 들어, 높은 동시성 시나리오에서 전처리를 위해 낙관적 잠금을 사용하고 마지막 커밋이 제출 될 때만 최종 확인을 위해 비관적 잠금 장치를 사용합니다. 이를 통해 효율성과 데이터 일관성을 모두 보장 할 수 있습니다. 이를 위해서는보다 복잡한 전략과 디자인이 필요합니다.

요컨대, 낙관적 인 자물쇠와 비관적 자물쇠에는 절대적인 좋은 사람이 없습니다. 선택할 전략은 특정 비즈니스 시나리오 및 데이터 일관성 요구 사항에 따라 다릅니다. 높은 동시성 시나리오에서 낙관적 잠금은 일반적으로 더 효율적이지만 데이터 충돌은주의해서 처리해야합니다. 데이터 일관성에 대한 요구 사항이 매우 높은 시나리오에서는 비관적 잠금 장치가 더 안전하지만 성능은 병목 현상이 될 수 있습니다. 선택할 때는 효율성과 데이터 일관성을 평가하고 실제 상황에 따라 적절한 솔루션을 선택하거나 조합하여 사용해야합니다. 은 총알도없고 적절한 솔루션 만 있습니다. 나는 당신이 잠금 메커니즘 마스터가되기를 바랍니다!

위 내용은 비즈니스에서 낙관론 및 비관적 잠금의 실제 적용 사례의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!