✅ Redis가 싱글 스레드인데도 빠른 이유Redis는 기본적으로 명령어 처리에 대해 단일 스레드로 동작함.멀티 스레드가 더 빠를 것 같지만, 싱글 스레드인 Redis가 더 빠른 이유는 I/O 멀티플렉싱 구조이기 때문.Redis는 I/O 멀티플렉싱 방식으로, 이벤트 루프가 작업 가능한 요청을 작업 큐에 등록해주면싱글 쓰레드(Redis 엔진)는 I/O 작업 없이 바로 처리 가능할 수 있음일반적인 Blocking I/O문제점 : 커널이 요청을 받아줄 때까지 쓰레드가 대기예) 점원(커널)이 자기를 봐줄 때까지 손님(쓰레드)이 손을 들고 기다리는 비효율적 구조Non-Blocking I/O 중 epoll()을 사용한 멀티플렉싱 방식(🔔Redis 구조)소켓이 이벤트 발생 시, 알림을 이벤트 루프에 전송이벤트 루프..

1. Redis 메시지 Queue 구조: Spring Boot 프로젝트에서 메일 전송 작업을 큐로 처리하는 예시구성요소Producer : 작업 요청을 생성해 Redis 큐에 삽입 (`LPUSH`)Redis : 중간의 Queue 역할 (List 자료 구조)Consumer : 큐에서 작업을 꺼내서 처리 (`BRPOP`)[사용자 또는 서비스 요청] ↓[Producer: 작업 생성] ↓ LPUSH taskQueue "이메일 전송 요청"[Redis Queue] ↑ BRPOP taskQueue 0[Consumer: 작업 처리 → 이메일 전송 등]동작 흐름LPUSH : 작업을 큐에 넣음BRPOP : 큐가 비어있으면 기다림(blocking) -> 작업이 들어오면 꺼냄Consumer가 ..

1. 동시성 제어 (Concurrency Control): 여러 사용자가 동시에 데이터에 접근하거나 조작할 때 발생할 수 있는 문제를 방지하기 위한 기술동시성 제어를 하지 않으면같은 데이터를 동시에 읽거나 수정할 때 데이터 정합성이 깨짐중복 처리, 데이터 충돌, 무결성 오류함예 : 여러 사용자가 동시에 같은 열차 좌석을 예매하는 경우, 중복 예약이 발생함 주요 방법낙관적 락 (Optimistic Lock) : 충돌이 드물다고 가정하고, 마지막에 변경 여부 확인비관적 락 (Pessimistic Lock) : 충돌 가능성이 크다고 보고, 먼저 락을 걸고 작업 수행분산 락 : 여러 서버/인스턴스 환경에서 락을 제어2. 낙관적 락 (Optimistic Lock)데이터 충돌이 거의 없을 것이라고 낙관적으로 가정하..

0️⃣문제 배경 (JWT의 한계와 Redis 도입의 필요성)JWT는 서버에 저장하지 않는 토큰 기반 인증 방식이기 때문에 한번 발급되면 유효기한이 끝날 때까지 유효함즉, 사용자가 로그아웃을 해도 서버는 그 토큰이 유효한지 알 수 없음이를 해결하기 위해서, Redis에 무효화된 토큰 목록(블랙리스트!)를 저장해두고 인증 요청시마다 체크하면서버는 특정 토큰을 무효화 된 것으로 간주할 수 있음1️⃣구현 방식 (로그아웃시)1. 사용자가 로그아웃 요청을 보냄2. 서버는 해당 jwt를 Redis의 블랙리스트에 저장TTL : 토큰 만료시간까지 설3. 이후 사용자가 다시 요청하면서버는 Redis에 해당 토큰이 존재하는지 확인존재하면 토큰을 무효 처리 (인증 거부. 로그아웃 처리)✍🏻예시코드// 로그아웃 시 Redis..

현재 진행하는 프로젝트에서 결제 업무를 위해서 외부 API인 토스 API를 호출하고 있다.결제 파트의 주요 로직들을 통합테스트 하려는데,이때 외부 API를 실제로 호출할지 아니면 Mocking하는게 좋을지에 대한 고민이 있었다.외부 API 호출 여부에 대한 결정은 테스트의 목적과 외부 API에 대한 의존성을 바탕으로 고려되어야 할 것이다.1️⃣ 외부 API를 실제 호출하는 경우외부 API를 호출하면 실제 연동 시나리오를 검증할 수 있다는 장점이 있다.인증 포맷, 인증 흐름 등 외부 시스템과의 실제 통신 과정을 그대로 확인할 수 있으며,추후 외부 API에 변경이 있다면 빠르게 감지할 수 있다.반면에, 외부 API가 불안정한 경우, 프로그램 로직과는 무관하게 테스트가 자주 실패되기 때문에 테스트가 일관되지 ..