| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
| 31 |
- Summer/Winter Coding(~2018)
- 분할정복
- 알고리즘고득점Kit
- dfs
- GIT
- 토마토
- 프로그래멋
- 구현
- 정렬
- 그래프탐색
- 백준
- Python
- 그래프
- 깃허브
- 다익스트라
- 깃허브 프로필
- 완전탐색
- 15686
- 월간 코드 챌린지 시즌1
- 이코테
- 1932
- 알고리즘
- 프로그래머스
- 자바
- Lv2
- 정수 삼각형
- 조합
- Java
- BFS
- DP
- Today
- Total
목록Project (5)
갱스터하우스
이 글은 제가 학습하고 경험한 것을 바탕으로 작성하여,일부 부족하거나 잘못된 점이 있을 수 있습니다.부족한 부분이나 잘못된 내용에 대한 피드백을 주시면 감사히 배우겠습니다! 1. 문제점 - 유효기간이 지나도 만료되지 않는 쿠폰의 상태 쿠폰 테이블을 조회했을 때,쿠폰의 expiredAt이 지나도 여전히 쿠폰의 상태는 "AVAILABLE", 즉, 사용가능한 status로 남아있었다. Q. 어떻게 하면 좋을까?처음에는 Redis를 이용한 방법을 생각했다.1. 쿠폰 발급 시, 해당 쿠폰 아이디를 Key로 Redis에 저장2. TTL 만료 시, Redis Keyspace Notifications 이용해 status 상태를 "EXPIRED"로 업데이트 하지만 곧바로 의문이 들었다.1. 쿠폰을 발급받을 때마..
이 글은 제가 학습하고 경험한 것을 바탕으로 작성하여,일부 부족하거나 잘못된 점이 있을 수 있습니다.부족한 부분이나 잘못된 내용에 대한 피드백을 주시면 감사히 배우겠습니다! 1. 사용하는 쿠폰 Redis에 저장하기Q. 사용하는 쿠폰을 왜 Redis에 저장해?본 프로젝트의 쿠폰 정책은 유저가 사용하는 시각을 기준으로 24시간이었다.닉네임 변경과 같이 사용하는 순간, 완료 처리가 되는 쿠폰도 있지만대부분의 쿠폰은 24시간 동안 그 효력을 발휘했다.따라서, 유저가 서비스를 이용할 때마다 쿠폰의 사용 여부를 검증해야 했고이를 위해 매번 DB를 조회해야 한다는 문제와쿠폰의 상태를 쿠폰 이력 테이블에서만 관리하고 있어ORDER BY created_at DESC LIMIT 1 이런 쿼리를 매번 날려야 하는 문..
이 글은 제가 학습하고 경험한 것을 바탕으로 작성하여,일부 부족하거나 잘못된 점이 있을 수 있습니다.부족한 부분이나 잘못된 내용에 대한 피드백을 주시면 감사히 배우겠습니다! 1. 쿠폰 사용 API 설계쿠폰은 다음과 같은 과정을 거쳐 사용할 수 있다. 1. 사용자가 쿠폰을 사용하려고 할 때,2. 해당 쿠폰을 사용할 수 있다면,3. 사용 가능하다. 이걸 개발하는 관점으로 본다면,1. 사용자가 어떠한 쿠폰의 사용을 요청할 때,2. 해당 쿠폰의 유효성 검증을 성공한다면,3. 데이터베이스에서 해당 쿠폰의 상태는 IN_USE로 바뀐다. ➡️ 위의 내용을 바탕으로 아래와 같이 API를 설계했다! 기능쿠폰 사용HTTP MethodPOSTAPI Path /users/user/coupon Request UseC..
이 글은 제가 학습하고 경험한 것을 바탕으로 작성하여,일부 부족하거나 잘못된 점이 있을 수 있습니다.부족한 부분이나 잘못된 내용에 대한 피드백을 주시면 감사히 배우겠습니다! 0. 쿠파프가 뭐야?마지막 자율 프로젝트(a.k.a Throwng)에서 꼭 리팩토링을 다짐했던 부분이 있었다.간략하게 설명하자면,Redis를 통해 사용 중인 쿠폰을 관리하고 있었지만 TTL이 만료될 경우 DB에는 반영이 안 되는 문제와발급받은 쿠폰 중 유효기간이 지나도 DB에 해당 쿠폰이 만료되지 않는 문제였다.즉, 데이터 동기화 문제를 해결하는 것이었다. 이렇게 되기까지의 원인은 여러 가지 요인이 있지만,자세한 건 나중에 Throwng 리팩토링 포스팅에서 다뤄보겠습니다~ 결론부터 얘기하자면,이 문제는 비정규화와 스케줄러를 이용해 ..
1. 413 Request Entity Too Large 오류 원인2. 413 Request Entity Too Large 오류 해결3. (부록1) 나의 트러블 슈팅기4. (부록2) 배운 점 1. 413 Request Entity Too Large 오류 원인nginx에서 client max body size를 별도로 설정해주지 않는다면기본값이 1MB로 설정되기 때문에, 업로드하려는 이미지의 1M보다 크다면 413 Request Entity Too Large 오류가 발생한다. 공식문서에도 아주 잘 나와있다 2. 413 Request Entity Too Large 오류 해결nginx 설정 파일에 다음과 같은 코드를 추가한다.-> 이걸 따로 설정하지 않는다면, default로 요청 사이즈의 크기가 1MB..