2025-01-07 수정)
동시성 문제
프로그램을 짜다 여러요청이 동시에 올 수 있다. 동시에 요청이 올 시 공유된 자원을 중복사용하여 에러가 날 가능성이 높아진다.
비관적 락, 낙관적 락, 분삭 락, Atomic update
실제 videoid에 조회수 증가 중복 문제에 대한 고민을 하던 중 위 4가지 방법 중 하나로 동시성 문제를 제어 하려고 했다. 아래는 내가 고민한 내용을 총 정리한 부분이다.
낙관적 락: 락을 걸지않고 충돌난 뒤에 알려줌
비관적 락: 트랜잭션 동안 락 유지
redis분산락: 분산 서버로 락 처리
atomic update: 쿼리 실행 기간 동안만 락 유지
Atomic update , 분산 락 고민
단순히 '조회수 + 1'에 대한 중복 고민
서칭을 해보니 보통 간단하거나 쉬운작업에는 atomic update사용하고 , 여러 필드가 연관되어 좀 복잡한 경우에는 분산락을 적용하는 경향이 있었다.
따라서 간단하고 빠른 작업 Atomic update를 선택
atomic update 구현
비관적 락이랑 똑같은 매커니즘 같다 생각되었음 하지만 차이가 있음
둘다 트랜잭션동안 락 걸어주는건 맞는데 atomic update 는 쿼리시간동안만 락걸어주고 , 비관적 락은 전체 api에 대해 트랜잭션 걸어줌
위 글에 대한 나의 생각
우선 지금 단순한 동시성 문제에서는
낙관적 락은 락을 걸지않고 충돌난 뒤에 알려주는 것이 단점
비관적 락은 데이터의 정합성을 보장하지만 너무 오래걸림
redis분산락 : 확장성과 속도 면에서 가장 좋지만 기술 구현하는데 오버헤드 가능성 높음
atomic update : 비관적락 보다 빠르면서 락 없이도 rdbms로 동시성 관리 , 적절한 속도 로 성능과 안정성의 균형이 있는걸로 판단 → 적용
하지만 이제 여러 필드가 연관데 중복성 문제에서는 redis 분산락 사용가능성이 높은데
추후에 프로젝트 개발시 이론적으로 적용해야될 상황이 나오면 그때 공부하고 적용시켜 봐야겠다.
