분류 전체보기404 [Redis]StringRedisTemplate StringRedisTemplate: 키와 값을 모두 문자열로 다루며 직렬화가 문자열로 고정되어있어서 사람이 읽는 값으로 그대로 저장단순 문자열 및 숫자만 다룰때 사용 redis에 상태만 저장하려고 사용 참고 : https://jessyt.tistory.com/465https://docs.spring.io/spring-data-redis/reference/api/java/org/springframework/data/redis/core/StringRedisTemplate.html StringRedisTemplate (Spring Data Redis 4.1.0 API)Constructs a new StringRedisTemplate instance ready to be used.docs.spring.io.. 2026. 7. 20. REQUIRES_NEW Propagation 1. 왜 사용하는지?결제 승인과 같은 핵심 비즈니스 로직 하나의 트랜잭션으로 동작-> 결제 실패시 retryCount 증가 재시도를 위한 상태 정보 반드시 저장되어야하는데 부모 트랜잭션에서 수행하면 부모 트랜잭션이 롤백될때 함께 롤백되는 문제가 발생합니다. -> 현재 결제가 실패했더라도 다음 재시도를 가능하게 만들기 위해2. 부모 트랜잭션에서 발생하는 문제예를 들어 결제 승인 로직이 있다고 가정합니다. @Transactionalpublic void confirm(Long orderId) { Payment payment = paymentRepository.findById(orderId); tossPaymentClient.confirm(payment); payment.complete();} .. 2026. 7. 20. [Redis]원자적 락 1. 의의: 두개의 스케줄러 인스턴스가 동시에 재시도를 요청을 할때(레이스 컨디션)락 확인이 1단계: 확인 -> 2단계: 저장Redis는 확인이랑 저장을 서버 내부에서 하나의 명령으로 묶고 처리한다.싱글 스레드로 처리하기 때문에 먼저 도착한 쪽만 true를 받고 나머지는 무조건 false 받는다. 2. 락 해제와 리스명시적 해제: 정상 종료시unlock()을 호출해서 지연 없이 진행시킨다.비정상 종료: TTL 자동 만료를 통해 해제 경로를 갖게함3. 데이터 저장과 락의 차이Redis는 락만 DB는 데이터만 저장한다. 2026. 7. 20. 멱등성(Idempotency)이 결제 시스템에 필수인 이유 1.멱등성: 같은 요청을 몇번 보내건 한번 보낸것과 동일해야한다왜 결제에서 중요한가? 같은 결제 요청이 실수로 2번 서버에 도달하면 멱등성이 없는 시스템은 사용자에게 이중 청구를 할 수 있다.왜 네트워크가 응답을 유실시키는가? 클라이언트가 요청을 보내고 서버가 처리를 끝내서 응답 만들었는데 그 응답 클라이언트에게 돌아오다가 도중에 회선이 끊기면서버 입장에서는 결제완료 클라이언트는 응답 못받았으니 실패로 간주하고 재전송이다 멱등성 보장= 요청이 몇번 중복 도달해도 실제 처리는 1번 이 역할= Redis 락 2.setIfAbsent(SETNX)가 원자적 락인 이유1. 조회 orderId가 db에 있나 확인없을때 등록1단계를 A가 실행한 찰나에 Brk 1단계 실행하면 둘다 2단계로 넘어가는게 레이스 컨디션확.. 2026. 7. 16. [REDIS] 분산락 실전 학습 태그 없음 → 모두 inline style - 태그 없음 - CSS 변수(var()) 없음 → 직접 색상값 ===================================================== --> Lua Redis Java 분산락 Spring WebFluxLua × Redis × Java — 분산락 Lua 스크립트 실전 이해Lua를 전혀 모르는 상태에서 시작해서 RedisScript.of(...)를 직접 작성하고 이해하는 것까지. 목차 1. Lua 기초 — 딱 필요한 것만 2. Redis에서 Lua를 쓰는 이유 3. 내 코드 한 줄씩 해부 (케이스 A/B/C) 4. Java에서 실제로 사용하는 법 5. 전체 완성 코드 1. .. 2026. 6. 11. [오늘의 옷장] FCM 스레드 풀 고갈 2차해결 — 비정상 토큰 유입 시 전체 서비스 응답 불가 FCM 스레드 풀 고갈 — 비정상 토큰 유입 시 전체 서비스 응답 불가 문제: 페이크 FCM 토큰을 부하테스트에 추가했더니 Firebase SDK의 블로킹 호출이 스레드 풀을 점유해 전체 서비스 응답이 불가 상태가 됐다. 추가 증상: 브로드캐스트 완료 후 total 값이 0으로 찍히고, 실패 건수도 집계되지 않아 장애 발생 여부 자체를 확인할 수 없었다. 해결 과정 1 1차 대응 — 타임아웃 적용 SDK 레벨(.get(5, TimeUnit.SECONDS))과 Reactor 레벨(.timeout()) 이중 타임아웃을 적용해 스레드 점유는 해소, 서비스 응답은 복구됐다. 그러나 알림이 제대로 전송되지 않는 문제는 지속됐고, 실패.. 2026. 5. 22. 이전 1 2 3 4 ··· 68 다음