WLOG

지난 글에 이어서 실시간 대기 순번을 받을 수 있도록 구현해 보자.   일반적으로는 API 는 클라이언트가 요청한 값에 대해 응답을 제공한다.클라이언트(웹 애플리케이션, 모바일 앱, 서버)가 특정 데이터를 요청하면, API는 그 요청에 알맞은 데이터를 반환한다.  API는 클라이언트의 요청에 대해서만 응답을 반환하며, 클라이언트의 요청 없이 API가 데이터를 보내지 않는다.하지만 API가 클라이언트의 요청 없이 데이터를 보내야 하는 상황이 있다. 지금과 같이~~  이렇게 API가 클라이언트의 요청 없이 데이터를 주도적으로 전달하기 위해 서버-사이드 이벤트(SSE), 웹소켓, 푸시 알림, 폴링/롱 폴링과 같은 기술들이 개발되었다.   실시간 알림을 구현하는 대표적인 방법에는 SSE, WebSocket 가 ..

티켓팅 시스템은 수천, 수만 명이 동시에 접속하는 상황을 고려해야 한다.특히 티켓팅 당일에는 막대한 트래픽이 몰리기 때문에, 이를 효율적으로 처리할 수 있는 대기열 시스템이 필요하다.또한 실시간 대기열 관리와 순번 조회 기능이 필요하다.대기열을 구현하기 위한 방법에는 SQS, RabbitMQ, Kafka와 같은 큐 서비스가 있다. 각각의 서비스의 장단점을 알아보고, 적합성을 판단하여 구현해보자! SQSAWS에서 제공하는 완전 관리형 서비스로 설정이 간단하고 확장성이 뛰어나다.메시지 중복 제거와 지연 메시지 처리가 가능하다.다만, 사용량에 따라 비용이 증가하며 메시지 처리 속도와 보장 수준은 Kafka보다 낮다.RabbitMQ다양한 라우팅 옵션과 기능을 제공한다.(우선순위, TTL)클러스터링을 통한 고가용..

(내가 아는 바로는...)기존의 이커머스 시스템은 결제 요청 직전에 재고 확인 후 락을 걸고 결제를 진행하기에 락을 짧게 잡는다. 하자만 티켓 예매의 경우 좌석을 잡고 있는 시간이 존재한다.7분 가량 좌석을 잡고 있을 수 있으며, 그 시간 이내에 결제를 완료해야 한다.두 시스템의 차이는 핵심 비즈니스 로직과 트랜잭션 처리에 대한 우선순위가 달라서 라고 생각한다.  두 시스템의 차이를 생각해보자.  티켓팅 시스템과 이커머스 시스템티켓팅 시스템좌석은 고유한 자원으로, 하나의 좌석에 대해 한 명의 유저만 선택할 수 있어야 한다.만약 하나의 자원에 대해 여러 사람이 동시에 선택이 가능하게 되면 중복 예매가 되거나 계속되는 결제 실패로유저의 불편함이 증가할 것이다.따라서 좌석은 한 번 선점되면 다른 사용자가 선택..

회원가입에 이어 이제 로그인을 구현할 차례이다. 로그인이 뭘까?사용자가 웹 애플리케이션에 접근하기 위해 본인이 맞는지 확인하는 과정이다.사용자는 아이디와 비밀번호를 입력하여 인증을 수행하고 인증이 성공하면 웹 애플리케이션에 접근할 수 있다.그러면 인증이 성공적으로 완료된 후 사용자는 애플리케이션의 모든 리소스에 접근할 수 있을까? 아니다. 인증만으로는 애플리케이션 내의 모든 자원에 자유롭게 접근할 수 없다. 사용자가 자원에 접근할 수 있는 권한이 있어야 접근이 가능하다.인증을 통해 신원을 확인했다면, 그 다음에는 인가가 필요하다.인증과 인가인증 Authentication인증은 사용자의 신원을 확인하는 과정으로 사용자의 입력 정보를 바탕으로 셀제 등록한 사용자와 일치하는지를 확인하는 절차이다.인가 Auth..

비민번호는 복호화 되지 않도록 단방향으로 암호화 되어야 한다.비밀번호를 단방향으로 암호화하는 이유는 복호화가 불가능하기 때문에, 개인 정보가 유출되어도 원본 비밀번호를 쉽게 알아낼 수 가 없기 때문이다.사용할 수 있는 암호화 기법을 알아보자.MDC와 MAC가 있다. 이 둘의 차이는 뭘까Modification Detection Code메시지 변경 감지 코드로 메시지 변경이 일어났는지를 확인하는 코드로 데이터의 무결성을 검증한다.Message Authentication Code메세지가 외부에 노출되어도 상관없을 때 사용할 수 있는 인증 기법으로 메시지 인증, 디지털 인증에 주로 사용된다.메시지가 내가 원하는 사람에게 왔는지 확인하려면 어떻게 해야 할까? 키를 주면 된다.송신자와 수진자는 미리 공유된 키를 가..

주제 선정 이유첫째, 야구 예매 시스템을 주제로 선정한 이유는 개인적인 야구에 대한 관심에서 비롯되었습니다.올해 야구의 인기가 크게 상승하면서, 나 또한 경기 관람을 위해 예매를 자주 하게 되었습니다. 하지만 각 구단마다 예매 사이트가 분리되어 있어 불편함을 겪었고, 모든 구단의 티켓을 한 곳에서 예매할 수 있다면 얼마나 편리할까 라는 생각과 함께 티켓팅 로직이 궁금하여 해당 프로젝트를 시작하게 되었습니다. 둘째, 티켓팅 오픈일에는 대규모 사용자가 동시에 몰리면서 서버가 원활하게 작동하는 원리에 대해 궁금증이 생겼고, 이를 해결하는 방법을 배우고 적용하고 싶었습니다. 대규모 트래픽을 처리할 수 있는 서버 안정성을 확보하는 과정에서 많은 기술적 도전이 있을 것이라고 생각했습니다. 마지막으로, 티켓팅 시스템..

String 을 선언하는 방법에는 두 가지 방법이 있다. 두 방식은 저장 공간(메모리)에 차이가 있다.  리터럴로 선언리터럴로 선언하는 경우 문자열을 String Constant pool에 저장하기 때문에 메모리의 효율이 좋다.리터럴을 사용하여 생성할 때 상수 풀에 같은 값이 존재하면 객체는 이미 존재하는 값을 참조한다.따라 동일한 문자열을 리터럴로 선언한 변수는 모두 같은 객체를 참조한다.  String Constant Pool의 동작1. String Constant Pool은 JVM이 관리하는 특별한 메모리 영역으로, 문자열 리터럴을 저장하고 관리한다.2. 문자열 리터럴을 선언하면, JVM은 먼저 String Constant Pool에서 동일한 문자열이 존재하는지 확인한다.있는 경우: 기존 문자열 객..

동일성Identity메모리 주소가 같다.주소 값이 같기 때문에 두 변수가 같은 객체를 가리킨다.==동등성Equality두 객체가 같은 값을 갖는다.객체의 데이터(필드 값)가 동일하다면 두 객체는 동등하다.equals() 메서드     기본 타입의 변수는 값을 직접 저장한다.예를 들어, int, double, char 등의 변수는 메모리에 값 자체를 저장하기 때문에,같은 값을 가지는 여러 변수가 존재해도 각각 독립적으로 메모리에 저장된다. == 연산자를 이용해 값을 비교하며, 두 변수가 같은 값을 가지면 true, 다른 값을 갖는 경우 false를 반환한다.   참조 타입의 변수는 객체의 메모리 주소를 저장한다.값 자체가 아닌 객체가 저장된 메모리 주소를 가리키기 때문에, 같은 값을 갖는 두 객체라도 메모..

Primitive Type기본 데이터 타입으로 정수, 실수, 불리언 등의 실제 데이터 값을 저장하는 타입int, long, double, float, boolean   Reference Type객체 참조 타입으로 객체의 주소를 저장하는 타입배열, 클래스, 인터페이스  두 타입의 차이는 메모리 저장 위치와 데이터 처리 방식에 있다.     메모리 저장 위치Primitive Type메모리의 스택 영역에 저장하고,  그 값을 직접 갖는다.스택 영역에 저장되기 때문에 메소드 호출이 종료되면 자동으로 사라진다.스택 영역에 저장된 변수들은 값에 직접 접근이 가능하기 때문에, 메모리 절약 및 속도가 중요한 경우에 사용한다.Reference Type객체의 주소를 스택 영역에 저장한다.실제 데이터는 힙 영역에 저장되며,..

자바에서 관련된 상수의 집합을 정의하는 클래스 상수 값을 그룹화하고 타입을 안전하게 보장한다.요일, 월 등 고정된 값 집합을 표현하거나 상태 머신에서 특정한 상태를 나타낼 때 사용하며 코드의 가독성과 유지보수성을 높일 수 있다.내부 메서드를 사용하면 상수의 특성에 따라 각각 다른 동작을 수행할 수 있고, 각 상수의 동작을 구현하거나 해당 상수의 속성을 반환할 수 있다.   전략 패턴행위를 캡슐화하여 동적으로 변경할 수 있도록 설계하는 방식이다.각각의 클래스(전략)로 캡슐화하여, 특정 클래스의 행위를 유연하게 바꿀 수 있다. 코드의 재사용성과 확장성을 높이는 데 유용 구조Context : 전략을 사용하는 클래스로 외부에서 전략을 주입받아 실행한다. Strategy : 공통 인터페이스 또는 추상 클래스로, ..