시뻘건 개발 도전기

이전 포스팅에서 우리는 대표적인 낙관적 락과 비관적 락에대해서 간략하게 살펴보았다. 사실 나는 낙관적 락도 사용하지 않았고 비관적 락도 사용하지 않았다. DB의 부하를 줄일 수 있는 방법을 몰색하다가 redis를 사용한 [분산 락]이라고 하는 녀석을 파보았다. "왜 분산 락을 사용해야만 했는가?"에 대해서는 마지막에 언급하겠다. 분산 락 (Distributed Lock) 동시성 이슈(경쟁)로 동일한 리소스에 대해서 접근이 이루어질 때 리소스의 결함이 생기지 않게하기 위해서 분산된 서버들을 하여금 원자성을 보장한다. 분산서버로 쉽고 간편한 redis를 사용하였다. redis client 그렇다면 redis client로 무엇을 사용해야할까. 결론을 먼저 이야기 하자면 Redisson을 사용하는 것이 좋다...

최근 토이 프로젝트를 진행하면서 맞이한 동시성 이슈. 그 이슈는 "게시글의 조회수 증가"에서 맞이하게 된다. 서로 다른 사용자가 동시에 게시글을 열람한다면, 조회수는 +2가 되어야할테니... 따라서 동시성 이슈를 해결하기 위해 락을 획득하기로했다. 일반적으로 알고 있는 락은 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)이있다. 낙관적 락(Optimistic Lock) 동시에 동일한 데이터에 대한 수정을 서로 연관되지 않게 방지하는 기능으로써 해당 데이터의 "version"을 확인하여 엔티티의 변경을 감지한다. "낙관적"이라는 말처럼 "여러 트랜잭션이 동일한 데이터를 동시에 수정하지 않는다."라는 가정을 가지고 트랜잭션의 충돌을 방지한다. 한 마디로 "일단 데이터 가..