냥덕

명시적 락(Explicit Lock)앞서 synchronized를 사용할 때 멀티 서버 환경에서의 동시성 제어 한계를 해결하기 위해서 나온 방법이 명시적 락이다. 애플리케이션 코드나 데이터베이스 쿼리에서 명확하게 락을 요청하여 특정 리소스에 대한 접근을 제어하는 방식이다.아래는 대표적인 명시적 락의 종류이다. 하나씩 살펴보자낙관적 락(Optimistic Lock)비관적 락(Pessimistic Lock)네임드 락(Named Lock)낙관적 락(Optimistic Lock)낙관적 락은 어플리케이션 레벨에서 동시성을 제어하는 방식으로 충돌이 발생할 것이라고 '낙관적'으로 가정하고, 실제로 충돌이 발생했을 때만 대응하는 방법이다. 데이터베이스에 대한 변경이 드물게 발생하고, 충돌 가능성이 낮은 환경에서 유용한..

틀린 부분이 있다면 피드백 주시면 감사합니다! 프로젝트를 진행하면서 조회수 불일치 문제를 겪은적이 있다. 당시 3주라는 짧은 기간에 기능 구현하기 급급해서 블로그 슥 보고 Redisson을 활용해서 분산락 방식으로 해결한 적이 있다. 프로젝트 끝나고 나서 동시성 문제가 왜 생기는지 알아보면서 멀티 스레드 환경에서 동시성 문제는 꼭 이해하고 넘어가야 한다는걸 느꼈다.  동시성 문제란?여러 작업(스레드, 프로세스, 트랜잭션)이 동시에 같은 데이터나 자원을 수정하려고 하면 문제가 발생할 수 있으며 이를 동시성 문제라고 한다.여기서 다룰 내용은 데이터베이스의 저장된 데이터에 여러 작업이 동시에 수행될 때 의도하지 않은 작업 결과가 발생하는 경우라고 가정한다. 가장 쉬운 예시로 흔히 재고 시스템에서의 동시성 문제..

요구사항회원가입 시 이메일 인증비밀번호 찾기 시 이메일 인증문제점기존 코드의 경우 각 상황별로 API들이 존재하면서 그에 맞게 서비스 로직도 구현되어 있음 즉 똑같은 로직들이 반복 될 수 밖에 없는 구조Before CodeAuthController@Operation(summary = "이메일 인증번호 생성 API")@Parameter(name = "email", example = "teamluckyvickyblurrr@gmail.com")@GetMapping("/email/{email}")public ResponseEntity createEmailAuth(@PathVariable("email") String email) { return ResponseEntity.ok(memberService.cre..

Quartz 도입기 1Github Code : batch quartz demo 목표1편에서 정리한 내용 바탕으로 기능을 구성해보자. 최종적으로 구현할 스케줄러는 2개며 Listener도 추가해보고 여러가지를 해보도록 하자외부 서버에서 5분마다 새로운 상품 데이터 가져오는 배치 Job 실행5분 간격으로 등록 상품들 이상 서버로 전달하는 배치 Job 실행중요한 작업은 배치에서 처리 하기 때문에 사실 스케줄러는 크게 어려울게 없다.  Job 정의외부 서버에서 5분마다 새로운 상품 데이터 가져오는 배치 Job 실행@RequiredArgsConstructor@Slf4jpublic class FirstJob extends QuartzJobBean { //batch JobLauncher private final..

처음 공부한 내용이라 틀린 부분이 있을 수도 있습니다........Github Code : batch quartz demo1 도입기기업 연계 프로젝트를 진행하면서 아래와 같은 기능이 필요하게 됨5분 간격으로 상품 증분데이터를 받아와야 하는 기능상품 데이터의 이상치 검사를 위해서 받은 상품 데이터들을 하나의 배치 ID로 매핑해서 이상치 검사 서버로 보냄일정 주기로 동작(대충 스케줄링?)+ 데이터를 묶어서 처리(음...배치?)를 생각하게 됨대용량 수준까지는 아니지만 반복적인 작업을 처리하고 새로운 상품 데이터의 처리라는 점에서 작업 관리가 중요하다고 생각함Scheduling?일정한 시간 간격으로 반복적인 작업을 수행하는 도구특정 작업을 주기적 혹은 일정 시간이 지난 후에 작업을 수행할 수 있으며 효율적인 작..

*구선생님과 김영한님의 스프링 핵심원리 기본편을 바탕으로 이해한 내용을 정리한 것입니다! 틀린 내용이 있다면 언제든 댓글로 알려주시면 감사합니다!!!*IoC(Inversion of Control)란?Spring을 접하면 가장 먼저 접하는 단어라고 생각한다. 물론 처음 보는 사람은 절대로 한번에 이해하기 힘든 내용이기도 하다.(난 그랬다) 우선 직역을 하면 제어의 역전이라는 의미이다. 무엇에 대한 제어를 역전했다는 것인지 솔직히 와닿지는 않는다. 결론부터 말하자면 객체의 생성, 생명주기의 관리까지 모든 객체에 대한 제어권이 뒤바뀐 것을 의미한다. 그럼 IoC가 없다면?간단하다 제어의 역전의 반대라고 생각하면 된다! 객체의 생성, 생명주기 관리를 직접 관리하는 것이다.아래 코드가 그 예시이다./..

스프링 컨테이너란? 스프링에서 관리하는 Bean의 생성과 소멸 등의 라이프사이클을 관리하며 IoC를 이용하여 애플리케이션 컴포넌트를 관리하는 일종의 관리자이다. 일반적으로 IoC 컨테이너 혹은 컨테이너라고 부른다. 우리가 흔히 말하는 스프링 컨테이너는 ApplicationContext를 의미한다. 스프링에서는 BeanFactory와 이를 상속받은 ApplicationContext 이렇게 두개의 컨테이너를 활용할 수 있다. 우선 BeanFactory의 상속 구조를 알아보면 아래 이미지 구조로 되어있다. BeanFactory Bean을 등록하는 방법은 xml 설정이나 자바 어노테이션을 통해서 가능하다. 이때 BeanFactory는 해당 객체들을 생성할 때 사용자의 요청이 있을 때 생성하는 지연로딩 방식으 생..

관심사의 분리란? 영한님의 설명에 의하면 쉽게 말하자면 자신이 맡은 역할과 책임에만 집중하며 객체를 생성하고 연결하는 역활과 실행하는 역할이 명확히 분리되어있는 것을 의미한다.. 애플리케이션을 공연이라 했을 때 인터페이스들을 배역이라고 가정하자. 이때 실제 배역에 맞는 배우를 선택하는 것을 누가할 것인가라고 봤을 때 각 배역을 맡은 배우들이 선택하는 것이 아니라 제 3자가 선택해주는 것이 맞다. 만약 로미오의 배역을 A라는 배우가 했을 때 줄리엣이라는 배역의 배우를 B 배우가 해야한다 라고 정해버리는 순간 A의 책임은 공연을 해야하는 책임에서 줄리엣의 배역까지 정해버리는 책임까지 가지게 된다. 다시 말해 OOP의 원칙 중 단일 책임의 원칙(SRP)을 위반하게 된다. 이를 위해 나온 것이 관심사의 분리이다..

목표 spring boot, spring security 환경에서 springdoc을 붙여보자 1. 들어가기 앞서 api 문서란 무엇인가? 어떤 url을 통해 api 요청을 보낼 수 있는지 그리고 해당 api에 어떤 값들을 요청을 해야하는지, 해당 api로 부터 어떤 응답값이 내려오는지 등을 정리한 문서이다. 2. 그럼 springdoc은 무엇인가? springdoc은 당신이 만든 api를 자동으로 문서화 해주는 역할을 하는 친구이다. 쉽게 예시를 들어보자 spring mvc 환경에서 개발자가 controller class를 작성하고 url 매핑값을 지정하고 응답값은 string을 내려주는 메소드를 작성했다. 그럼 springdoc에서 제공하는 어노테이션들을 추가해서 설정을 하면 swagger-ui를 통..