여기서 주문정보전달은 결제의 부가적인 로직이기 때문에 분리 되어야 한다. 주문정보전송은 sendOrderInfo는 대충 목으로 만들어줬다. 1) 주문정보 전송이 늦어지면 결제처리에 대한 프로세스도 함께 지연된다. 2) 데이터 수집 플랫폼으로 주문데이터가 전달 api가 실패했을 떄, 결제가 취소된다. 3) 데이터 수집 플랫폼으로 주문데이터 전달 api가 timeout이 발생했을 떄도 결제가 취소된다.- 반대로 데이터 수집플랫폼은 실패한 결제임에도 저장이되고, 우리 시스템에서는 결제 실패가 되어 데이터가 맞지 않게된다. 위의 코드는 예이다. 제대로 작동하진 않을 것이다 (aop로 돌아가는 트랜잭션이기에?) 1) 이렇게 트랜잭션을 나눈다면?- 데이터는 정상적으로 결제에 대한 트랜잭션이 있어 결제만 관리가된..
🙂개요 - 나의 시나리오에서 수행하는 쿼리들을 수집해보고, 필요하다고 판단되는 인덱스를 추가하고 쿼리의 성능개선 정도를 작성하여 제출자주 조회하는 쿼리, 복잡한 쿼리 파악Index 추가 전후 Explain, 실행시간 등 비교 🚩 콘서트 예약시스템 사용자 플로우사용자 첫 접근 시 토큰을 발급, -> 대기열에서 기다림 ->차례가 오면 활성화 토큰콘서트 예약 가능 날짜를 조회한다.콘서트 예약 가능 좌석을 조회한다.콘서트 좌석을 예약한다.좌석을 결제한다. 사용자는 크게 5개의 플로우를 타게된다. 그 중에 1번에 해당하는 토큰은 Redis에서 관리되며, 쿼리를 사용하지 않게 끔 진행하려한다.2,3,4,5번의 플로우에서는 쿼리가 사용 된다. ▶️ 예약 가능 날짜 조회 select cs1_0.c..
앞서 우리가 학습한 Transaction, Lock, Index, Cache 등은 모두 비즈니스 로직을 처리하는 데에 있어 중요한 Database의 부하를 줄이고, 속도 및 성능을 향상시키기 위함이었습니다. 그런데 Lock의 범위 뿐 아니라 무분별한 비즈니스 로직과 트랜잭션의 규모 또한 우리가 예측하지 못한 문제를 발생시킬 수 있습니다. 어떤 문제로 이어질 수 있을까? - 다수의 SlowRead 작업으로 인해 요청 처리에 영향을 줄 수 있음- Transaction 범위 내에서 Lock을 사용하고 있을 경우, 해당 자원에 접근하는 다른 요청의 대기 혹은 데드락 상황을 유발할 수 있음- 긴 생명 주기의 Transaction의 경우, 오랜 시간은 소요되나 후속 작업에 의해 전체 트랜잭션이 실패할 수 있음 ..
- 쿼리에 대한 부하를 줄일 수 있는 훈련- 비즈니스 로직 별 트랙잰션 범위를 파악하고 사이드 이펙트에 대해 고려해 본다. > 사이드이펙트란? 의도치 않은 결과로 예로 고혈압약을 먹었는데 머리가 풍성하게 자라나는 것같은 의도하지 않았지만 나타나는 결과들이다.- 비즈니스를 적절하게 핸들링 할 수 있도록 선후관계를 파악하고, 애플리케이션 이벤트를 활용해 관심사를 분리하도록 개선해 본다. ---- 인덱스란? 서비스 개발자의 중요한 역량 중 가장 중요한 것은 데이터베이스를 핸들할 수 있는 역량이다. 그 중 중요한 것이 index이다. - 인덱스는 조회 성능을 높일 수 있지만 아래 사항들을 고려하여 설계해야 함 - 한번에 찾을 수 있는 값 - 인덱스 재정렬 최소화 - 데이터 삽입, 수정이 적은 컬럼 - 인..
🤷 콘서트 예약 프로그램일반적으로 콘서트를 예약할 때에는 '인기가수'의 '팬'들이 몰리게 되며 트래픽이 발생한다. 곧 서버가 부하를 받게 된다. 적은 부하로 트래픽을 처리하기 위한 방법 중 사용 토큰 전략이 있다. Token (feat Redis)in-memory 데이터베이스인 Redis를 이용한 token 대기열 콘서트 예약프로그램의 대기열 방식은1. 사용자 처음 등장 -> 토큰 생성 -> 토큰 대기열로 들어감2. 토큰 대기열 -> 순번에 따라 활성화 토큰으로 전환 (서버의 상태에 따라 대기 시간이 정해짐)3. 활성화 토큰 -> 예약, 결제 등이 가능해짐 이 있다. 이곳에서 토큰 관리는 두가지로 나누게 된다.대기열 토큰 (Waiting Tokens)활성화 토큰 (Active Tokens)대기..
🤷 콘서트 예약 프로그램일반적으로 콘서트를 예약할 때에는 '인기가수'의 '팬'들이 몰리게 되며 트래픽이 발생한다. 곧 서버가 부하를 받게 된다. 적은 부하로 트래픽을 처리하기 위한 방법 중 사용 Caching 전략이 있다.Caching데이터를 임시로 복사해두는 Storage 계층적은 부하로 API 응답을 빠르게 처리하기 위해 사용 콘서트 예약프로그램은콘서트 일정 조회좌석 조회좌석 예약결제총 4개의 핵심 기능을 가지고 있다. 캐싱은 보통 메소드 단위로 작성된다. 자주 변화가 일어나지 않는, 하지만 많은 사용자들이 찾는 부분을 캐싱하는 것이 옳다.만약 사용자가 자주 찾는 정보를 캐싱하면, 서로 다른 정보를 보며 혼란이 일어날 것이다. 이곳에서 Caching으로 처리가 가능한 조회 부분을 볼 수 있다.콘..
1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)이번 주차를 지나며 겪었던 문제가 무엇이었나요?> 향해를 진행하면서 집안일이나 급한 일을 잡지 않으려 했습니다만 집 이사 등의 문제로 금주차는 진행 자체가 많이 힘들었습니다. 2. 시도문제를 해결하기 위해 어떤 시도를 하셨나요?> 준비를 하면서도 적어도 1시간 이라도 시간을 내려 노력했고, 과제보다는 알짜배기로 학습하는 시간을 가졌습니다. 3. 해결문제를 어떻게 해결하셨나요?> 빠르게 이사 일정을 잡고 해결했습니다. 4. 알게된 것문제를 해결하기 위해 시도하며 새롭게 알게된 것은 무엇인가요?> 동시성 테스트 코드를 작성할 때에 ExecutorService의 execute와 submit은 비슷하지만 다른 동작을 하게 된다는 것을 알았습니다. ..
- 간단한 자기소개국비학원을 다니고 취직한 백엔드 개발자 입니다. SM, SI를 3년간 했습니다. 개발 중 PM역할을 함께 해왔어서, 서비스 개발에 대한 지식과, 연습을 해온 시간이 부족했습니다. - 이번 챕터를 시작하며 꼭 해내고 싶었던 목표목표라는게 구체적으로는 없었습니다. 다만 서비스가 제대로 돌아가는 개발을 완성하고 싶었습니다. - 이번 챕터를 마무리하며 가장 기억에 남는 성취커맨드에 대한 비밀이 풀렸고, 소스가 좀 깔끔해진 것 같습니다. - 이번 챕터에서 반드시 이뤘으면 했는데 이루지 못한 것로깅처리를 하고싶었는데 공통 로깅 처리를 못했습니다.. - 다음 챕터에서 반드시 성공하고 싶은 목표로깅처리하고, 리팩토링하고, 분산락까지 사용해보고 싶습니다. - 내가 강화해야 할 강점 중 가장 중요하다고..
- Total
- Today
- Yesterday
- 항해플러스
- 백엔드 개발자 역량
- 리터럴
- 백엔드 개발자 공부
- 예외처리
- react실행
- 스프링공부
- Intercepter
- 향해플러스백엔드
- 인터셉터
- reject
- 향해99
- 로그인
- Java
- 항해99
- BindingResult
- filter
- rejectValue
- jpa api
- SpringBoot
- 컨트
- exception
- React
- JPA
- 향해플러스
- ArgumentResolver
- hypertexttransferprotocol
- 스프링부트
- thymleaf
- HTTP
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |