물빠진떡 님의 블로그

읽기 전에Redis Lock 기본Redisson vs Lettuce서론위 글에서 적은 동시성 이슈를 해결하기 위해 Redisson을 도입한 Redis 락을 구현하게 되었다. 1. User A와 User B가 동시에 방에 참가한다2. User A와 User B가 거의 동시에 방 목록을 가져오게된다3. User A가 먼저 saveRoom을 하여 참가를 하게되고 다른 유저들은 User A가 마지막 참가자로 참가하는 알림을 받게 된다4. User B가 saveRoom을 하며 덮어쓰게되고 다른 유저들은 마지막 참가자가 User B가 되었다는 알림을 다시 받게된다5. User A는 방에서 추방되게 된다.이처럼 유저가 직접적으로 동시성 이슈로 인한 버그를 느낄 수 있기 때문에 Lock의 필요성을 느끼게 되었다.설계L..

읽기 전에Redis의 락 레디스의 락에 대해서 정리한 글이다Spring의 Redis FrameworkSpring의 레디스 프레임 워크는 크게 3가지가 있다.Jedis , Lettuce, Redisson이렇게 있다. JedisRedis 동기식 Java 클라이언트, 비교적 간단하고 쉽다LettuceRedis 비동기 및 반응형 연결 Java 클라이언트, netty (자바 비동기 이벤트 기반 네트워크 애플리케이션)기반으로 이루어져 있다Reddisonnetty 기반의 고성능 비동기 및 락프리 Java 클라이언트, 락프리란 락을 사용하지 않고도 공유 자원에 대하여 여러 스레드 접근시 데이터의 일관성을 보장하는 프로그래밍 기법JedisRedis 용 비 동기식 Java 클라이언트라고 설명하며 비교적 간단하고 쉽게 사용..

서론마피아 투게더를 개발하면서 Redis를 도입했다.Redis를 도입한 이유는 다음과 같다JVM 내부 세션 방식으로 관리하는 것보다 분산환경에 더 유연하게 설계 가능RDBMS보다 더 빠른 인메모리 DB하지만 여러가지 문제에 봉착하게 되었다.바로 동시성 문제에 봉착한 것이다.대표적인 예시로동시에 A, B가 마지막 멤버로 들어오면서 A가 사소한 차이로 먼저 들어왔을때A의 입장 요청이 B의 findRoom(참여인원 정보)보다 먼저 들어갈 경우 방의 입장정보를 계속 받고 있던 다른 유저는 마지막 유저가 A -> B로 바뀌는 동시성 이슈를 맛보게 될것이다.또한 DB(Redis)에는 해당 테이블에 먼저 입장한 A가 아닌 B가 최종적으로 저장되게 된다.이러한 문제는 @Transactional로 격리하여 해결할 수 있..

서론마피아 투게더라는 프로젝트를 진행하면서 기존 JVM 메모리로 관리하고 있던 게임내의 데이터 Repository를 Redis로 바꾸게 되면서 이에 대한 학습을 진행하였다.기존 JVM 인메모리로 관리하던 것이 문제가 된다고 생각한 것은모놀로식 서버에서 모든 데이터를 관리하는 것이 단일 장애점(SPOF)을 유발MSA 아키택처로 변경하거나 혹은 스케일 아웃 진행시 데이터 관리에 문제가 발생이라고 판단하였다.그렇다면 DB로 어떤 스택을 사용해야 하는 것일까?우리는 영속성 DB와 인메모리 기반의 DB를 고민하게 되었다.이중에서 영속성 DB를 채택하지 않은 이유는 우리의 서비스는 인증 인가의 과정이 없는 서비스 이기 때문에 이전 유저의 기록을 영구 저장할 필요가 없다고 판단했기 때문이다. 때문에 에초에 영속성 계..