🏝️ Spring

🤔 서론 이번 글에서는 Redis를 사용하여 분산락을 구현해 보도록 하겠습니다. Java의 Redis 클라이언트로는 Jedis, Lettuce, Redisson 등이 있으며, 각각의 특징이 서로 다릅니다. 이중에서 Jedis는 제외하고 Lettuce와 Redisson을 사용해서 분산락을 구현해 보도록 하겠습니다. (Jedis와 Lettuce의 비교는 다음 글을 참고해주세요) 🤔 Redis 환경 설정 아래 명령어를 통해 redis를 다운받아줍니다. (반드시 도커를 사용할 필요는 없습니다.) docker pull redis 이후 레디스를 실행시켜줍니다. docker run --name redis -d -p 6379:6379 redis 프로젝트에서는 Redis 관련 의존성을 추가해주도록 하겠습니다. imple..

🤔 서론이전 글에서는 비관적 락(Pessimistic Lock)과 낙관적 락(Optimistic Lock)을 통해 분산락을 구현하여 단일 서버는 물론 다중 서버에서도 동시성 문제를 해결하였습니다.이번 글에서는 비관적 락과 비슷한 MySQL의 USER-LEVEL Lock(Named Lock)을 통해서 동시성 문제를 해결해 보도록 하겠습니다.(앞으로는 user-level lock이라고 부르도록 하겠습니다.)       🤔 USER-LEVEL Lock (Named Lock)MySQL 공식 문서를 보면 다음과 같은 user level lock을 지원해주는 것을 알 수 있습니다.   🐳 GET_LOCK(str, timeout)주어진 이름(str)에 대한 Lock 획득을 시도합니다. 이때 문자열의 길이는 최대..

🤔 서론 이전 글에서 알아본 synchronized는 단일 서버 환경에서만 동시성 문제를 해결할 수 있었습니다. 이번 글에서는 다중 서버 환경에서 동시성 문제를 해결할 수 있는 방법에 대해 알아보도록 하겠습니다. 여러 대의 서버에서 동일 자원에 접근하는 경우, 동시에 한 개의 프로세스(혹은 쓰레드)만 접근 가능하도록 하기 위해 사용하는 Lock을 분산 락(Distributed Lock)이라 부릅니다. 이제부터 분산 락을 구현하는 여러 방법들에 대해 알아보도록 하겠습니다. 💡 분산 락에 대해서 분산 락에 대해서 이렇다 할 완전한 정의를 찾지는 못해서 다음 두 상황이 혼동될 수 있을 것 같습니다. 1. 웹 애플리케이션 서버가 여러대인 경우, 이들간의 동시성 문제를 해결하기 위해 사용되는 Lock 2. 스케일..

🤔 서론 다중 사용자를 위한 웹 애플리케이션을 만들다 보면 한 번쯤은 동시성 문제에 접하게 됩니다. 동시성 문제는 하나의 자원에 대해서 여러 쓰레드가 동시에 접근하여 수정하는 경우에 발생하는 문제입니다. 동시성 문제가 발생하는 간단한 예시로는 특정 게시물의 조회 수가 올바르게 증가되지 않는 문제가 있을 수 있습니다. 특정 게시물에 100명의 사용자가 동시에 접근하는 경우 조회수는 100이 되어야 옳겠지만, 대부분의 경우 조회수는 100보다 작은 값으로 설정될 것입니다. 조회수 같은 경우에는 대체로 데이터의 정합성이 중요하지 않기 때문에 이러한 부분이 문제가 되지 않을 수 있지만, 상품의 재고 수량과 같은 경우에 이러한 동시성 문제가 발생한다면 치명적일 수 있습니다. 이러한 동시성 문제를 막기 위해서는 다..

(제 궁금증 풀 용도로 정리한거라 막 깔끔하게 정리하지는 않았습니다.) 🧐 ManyToOne, OneToOne 연관관계 일반적으로 merge 시 merge되는 특정 엔티티에 대해서만 조회합니다. 그러나 cascade 속성이 MERGE라면 merge 시 연관된 엔티티들도 left join으로 조회해옵니다. merge()가 되어 값이 변경되는 것도 일반적으로는 fk 값의 변경만이 반영되지만, cascade 속성이 merge라면 연관된 엔티티의 변경도 함께 반영됩니다. (DB 관점에서 생각하면 편합니다) @NoArgsConstructor @Accessors(fluent = true) @Getter @Entity public class Member { @Id @GeneratedValue(strategy = Ge..

🧐 문제 상황 @Service @Transactional @RequiredArgsConstructor public class PostService { private final PostRepository postRepository; private final MemberRepository memberRepository; public Long create(CreatePostCommand command) { Member member = memberRepository.findById(command.memberId()) .orElseThrow(NotFoundMemberException::new); Post post = command.toPost(member); Post saved = postRepository.sa..

(전 순정 백엔드 개발자기 때문에 React는 못합니다. React 코드는 Chat GPT 시켜서 구현하였고, 대신 백엔드에 온 진심을 담하서 구현하였으니, 프론트 코드는 정말 그냥 테스트용으로만 참고해 주시면 감사하겠습니다.) OAuth의 개념에 대해서는 이미 많은 블로그들에서 다루고 있으므로 저는 이에 대해서는 따로 다루지 않겠습니다. 이 글에서는 (적어도 제가 살펴보았던) 대부분의 블로그에서 애매하게 설명되어있는 프론트엔드와 백엔드의 역할과, 실제로 어떻게 구현하는지를 집중적으로 다뤄보도록 하겠습니다. 또한 이 과정에서 단순히 구현하고 끝내는 것이 아니라 새로운 타사 플랫폼을 추가하는 과정도 간단하게 처리할 수 있도록 유연하고 확장 가능한 구조를 가져가는 코드를 작성해보도록 하겠습니다. 소스 코드는..

🧐 인수테스트 데이터 초기화 인수테스트 혹은 통합테스트를 작성할 때에는 테스트를 격리하기 위해 다양한 방식을 사용할 수 있습니다. 이와 관련한 여러 방법에 대해서는 인수테스트에서 테스트 격리하기 글에 자세히 나타나 있습니다. 저는 여러가지 방법들 중 @Sql 애노테이션을 사용하여 truncate 쿼리를 작성하는 방법을 주로 사용했었는데요, 이 방법은 truncate.sql 파일에 코드가 의존적이게 되며, 테이블이 새로 추가되거나 삭제되는 경우 truncate.sql 파일도 계속해서 수정해주어야 한다는 단점을 느꼈습니다. 그러던 중 BeforeEachCallback라는 것에 대해 알게되었고, 이를 사용하여 truncate.sql 파일 없이도 데이터베이스를 초기화를 자동화 시켰는데요, 해당 방법에 대해서 알..