docs: Gateway 메모리 캐시 전략 추가
- 매번 DB 조회 대신 메모리 캐시 사용 - 로그인 시 캐싱, 로그아웃 시 제거 - 성능 대폭 개선 예상
This commit is contained in:
parent
cd318892c4
commit
cce4804d86
@ -62,7 +62,8 @@
|
|||||||
- **역할**:
|
- **역할**:
|
||||||
- API 게이트웨이 (사용자 요청 → 로빙 라우팅)
|
- API 게이트웨이 (사용자 요청 → 로빙 라우팅)
|
||||||
- 인증 체크 (auth-server 연동)
|
- 인증 체크 (auth-server 연동)
|
||||||
- 사용자-로빙 매핑
|
- 사용자-로빙 매핑 (메모리 캐시)
|
||||||
|
- 캐시 관리: 로그인 시 추가, 로그아웃 시 제거
|
||||||
|
|
||||||
#### robing-control (구 frontend-base 일부)
|
#### robing-control (구 frontend-base 일부)
|
||||||
- **위치**: 51123 서버
|
- **위치**: 51123 서버
|
||||||
@ -105,7 +106,7 @@ sequenceDiagram
|
|||||||
|
|
||||||
U->>F: 채팅 입력
|
U->>F: 채팅 입력
|
||||||
F->>G: /api/chat (user_id 포함)
|
F->>G: /api/chat (user_id 포함)
|
||||||
Note over G: DB 조회: user_id → port 8001
|
Note over G: 메모리 캐시 확인<br/>없으면 DB 조회 후 캐싱
|
||||||
G->>R: 프록시 (port 8001)
|
G->>R: 프록시 (port 8001)
|
||||||
R->>G: 응답
|
R->>G: 응답
|
||||||
G->>F: 응답
|
G->>F: 응답
|
||||||
@ -115,7 +116,9 @@ sequenceDiagram
|
|||||||
**수정된 흐름 설명:**
|
**수정된 흐름 설명:**
|
||||||
1. 로그인 완료 후 Frontend는 user_id만 알면 됨
|
1. 로그인 완료 후 Frontend는 user_id만 알면 됨
|
||||||
2. 모든 API 요청에 user_id 포함 (JWT 토큰 또는 헤더)
|
2. 모든 API 요청에 user_id 포함 (JWT 토큰 또는 헤더)
|
||||||
3. Gateway가 매번 DB 조회하여 해당 사용자의 robing_port 확인
|
3. Gateway가 메모리 캐시 확인 (대부분 여기서 처리)
|
||||||
|
- 캐시 hit: 즉시 라우팅
|
||||||
|
- 캐시 miss: DB 조회 후 캐싱
|
||||||
4. Gateway가 적절한 로빙으로 프록시
|
4. Gateway가 적절한 로빙으로 프록시
|
||||||
5. Frontend는 로빙 포트를 전혀 알 필요 없음
|
5. Frontend는 로빙 포트를 전혀 알 필요 없음
|
||||||
|
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user