일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |
- LV01
- 연습문제
- CoffiesVol.02
- LV02
- 알고리즘
- 코테
- Java
- LV03
- 일정관리 프로젝트
- SQL
- 이것이 자바다
- LV1
- mysql
- 포트폴리오
- Redis
- JPA
- CI/CD
- 일정관리프로젝트
- LV.02
- Kafka
- 데이터 베이스
- LV0
- GIT
- 프로그래머스
- spring boot
- docker
- Join
- S3
- Lv.0
- 디자인 패턴
- Today
- Total
목록2025/09/01 (2)
코드 저장소.
목차1.문제 출저2. 요구사항3.코드 작성 1.문제 출저https://www.acmicpc.net/problem/308022. 요구사항우선 이 문제를 보고 도출한 요구사항은 아래와 같다. 참가자의 수: N티셔츠 (T)6개의 사이즈가 있다.(S,M,L,XL,XXL,XXXL)같은 사이즈의 T장 묶음.참가자의 수보다 남아도 괜찮다.펜 (P)참가자 수만큼 묶음으로 주문재고는 참가자수이므로 남는게 없다. 첫 입력은 참가자의 수 두번째 입력은 참가자의 수만큼 티셔츠 사이즈의 갯수를 입력 세번째 입력은 티셔츠와 펜의 묶음수 마지막으로 계산을 한 값을 보여준다. sudo 코드는 참가자 입력을 받는다. 참가자의수 만큼 배열을 만들어서 반복문을 돌려서 반복문 안에 티셔츠의 종류의 수를 넣는다. 티셔츠와 펜의 묶음수..

목차1. 도입 배경2. EOS(Exactly Once Semantics) 접근 방식3. 설계 및 구현 방법4. 성능 측정5. 후기 1. 도입 배경현재 서비스는 Outbox + DLQ + Retry 구조로 이벤트 발행 및 복원력을 확보하고 있습니다. 이 방식은 at-least-once 전달 보장을 만족하여 메시지 유실은 방지할 수 있습니다. Outbox로 DB 트랜잭션과 메시지 발행의 원자성을 맞췄고, DLQ/Retry를 통해 장애 상황에서도 재처리가 가능하기 때문에 안정적으로 이벤트를 보낼 수 있습니다. 하지만 여전히 한 가지 문제가 남아 있습니다. 메시지의 중복 처리입니다. 문제의 소지는 동일한 Outbox 이벤트가 재발행되었을 때 Retry 스케줄러가 같은 이벤트를 재전송했을 때 Consumer가 재..