전체 글

알고리즘 스터디가 필요했습니다.저는 이전에 하루 적어도 한 문제씩 알고리즘을 푸는 것을 목표로 잡고 행동에 옮겼습니다.  결과는 3개월만에 백준 기준 브론즈에서 골드레벨까지 올랐습니다.알고리즘 실력은 늘었습니다. 그러나 제가 기대하는 것만큼 드라마틱하게 늘지 않았습니다.왜였을까요? 솔직하게 말하면, 제가 자신있는 분야만 풀었기 때문입니다.하루에 적어도 한 문제를 풀어야하니, 배움의 목적이라기 보다는 풀이의 목적성이 더욱 강했습니다. 그래서 제가 자신있는 분야는 풀이 속도가 빨라졌으나, 전체적으로 보면 그렇게 실력이 많이 늘지 않았던 것입니다. 또한, 공부법도 명확하지 않았습니다.  저는 제가 자신있는 분야만 풀었고, 해결한 문제에 대해서 복습을 하지 않았습니다. 그래서 잘 몰랐던 분야에 대해서는 장기기억..

주소https://www.acmicpc.net/problem/2309 주의점아홉 난쟁이 중 일곱 난쟁이만 산출한다.일곱 난쟁이 키의 합은 100 이다.일곱 난쟁이를 찾을 수 없는 경우는 없다. 알고리즘 선택과 근거브루트포스 알고리즘- 문제의 달성 조건이 명확하다.- 정답이 여러개일 수 있으나 풀이의 수가 제한되어 있다. 풀이import java.util.*;public class Main { public static void main(String[] args) { Scanner sc = new Scanner(System.in); int sum = 0; int[] arr = new int[9]; // 스파이 난쟁이 초기값은 배열 ..

이번 Radiata 프로젝트 진행하며 나는 부팀장 역할을 맡고, 타임세일 쿠폰 파트를 맡았다.프로젝트 초반에는 ERD 설계에 공을 많이 들였다. 팀원분들과 계속 소통하며 어떻게 해야 비즈니스 도메인 적으로도 이상적이고, 코드 딴에서 깔끔하게 처리를 할 수 있을까 고민을 많이 했었다. 그렇게해서 완성 된 ERD 정말 공을 많이 들인 만큼 수정이 거의 없을 정도로 깔끔하게 짜여진 ERD 였다. 그 다음은 각 파트별 아키텍처 및 구상도를 그렸다. 어떻게 동작하고, 어떤 점이 문제인지 파악하고, 추후에 해당 구상도를 보고 개발을 할 수 있게끔 하려는 목적이었다.내 생각에는 이런 구상도가 개발 시간을 단축시키는데 가장 큰 힘이 된 거 같다.   막 요런식으로,, 다른 분들도 너무 잘해주셨는데 함부로 올리면 안되니..

기존에는 분산락을 사용했었습니다.왜 동시성 제어 시 여러 선택지가 있는데, 분산락을 사용했을까요?낙관적 락과 비관적 락의 선택지분산락을 채택하기 이전에는 비관적 락으로 동시성 제어 하는 것으로 선택했습니다.비관적 락으로 데이터를 조회하게 되면 해당 트랜잭션이 끝나기 전까지는 비관적 락을 사용한 데이터에 데이터를 Insert 를 할 수 없게 됩니다.하지만 성능상 이슈가 있었습니다.낙관적 락과 비관적 락의 성능 문제공통점 - 기본적으로 다수의 쓰레드에서 DB 에 Select 문을 날려야 하는 구조이기 때문에 DB CPU 의 점유율이 요청 쓰레드에 비례해서 상승하게 됩니다. 🔐 비관적 락 - Lock 이 필요하지 않은 상황에서도 Lock 을 사용하기 때문에, 트래픽이 많은 경우에는 O(N^2) 정도까지 성능..

비관적 락에서 분산 락으로 온 이유 비관적 락에서 분산 락으로 온 이유는 DB의 CPU 점유율 때문이다. 비관적 락은 본질적으로 DB에 Select 문을 날려야 락을 걸 거나 확인 할 수 있는 구조여서, DB 에 많은 부하가 간다.그래서 Redisson 의 Pub - Sub 구조를 이용해 레디스에서 메서드에 락을 걸어 점유하지 못하게 했다. 분산 락은 느렸다.대규모 트래픽 관점에서 너무 느렸다.RPS 200 ~ 250 대가 나왔다. 쿠폰 10000 장을 발급했을 때 최소 50초나 기다려야한다.  이에 따른 응답 시간도 길어졌다. 실제 이벤트를 진행하면 어느정도 RPS 가 나와야 할까?  TPS 3600+.. 내가 구현한 분산락으로는 어림도 없다.더욱 빠른 방법을 갈구해야한다. 이렇게 해볼까?  쿠폰 AP..

재고 감소에 대해 DB 비관적락으로 구현했었다. 여기서 문제가 생겼다. 비관적락은 우선적으로 DB에 요청을 먼저 해야하기 때문에 1000 건이 들어온다고 하면 DB 자체에 1000 건의 요청이 쏠리게 된다. 그래서 DB 의 CPU 점유율이 올라가게 되었다. RDBMS 의 CPU 점유율을 관리하지 못한다면, 예상치 못한 오류가 생길 수 있다. 그래서 Redis의 분산락을 통해 구현했다. 분산락을 통해 RDBMS 의 CPU 점유율을 줄일 수 있었다.