Key-Value Repository 구현 변경 | CacheManager -> Redis

[sseunghoon]

📄 이슈 내용

• GameRepository | User <-> Game
• ClientRepository | User <-> WebSocket Client
• RoomRepository | User <-> Room

📝 상세 내용

• RoomRepository 는 추후에 채팅룸이 비휘발성으로 변경된다면 DB로 구현체가 바뀔 수 있으므로 가장 마지막에 변경
• 키값 의미구분 컨벤션을 '-' 에서 ':' 로 변경 (ex. user:{userId})
• Hashes 자료 구조 사용

🙋‍♀️ 의논해봐야 할 것

• (Game/Client/Room)Repository Interface와 RepositoryImpl를 만들고 interface에 의존하는 형태가 이상적으로 느껴진다.
• 더티체킹 기능이 없기 때문에 update(room:Room) 형태의 함수를 만들기 어렵다.
• updateTitle() 과 같은 함수를 여러개 만들어 interface에 넣는 것이 좋은 설계인가? (구현체에 넣는 것은 확실히 구리다.)
• update(room:Room, {업데이트 멤버: any}) 형태의 함수를 interface에 넣고 업데이트 멤버의 타입으로 구별할까 생각도 든다. 이를 위해서는 title, participants, bannedUsers, invitedUsers, mode, password 모두 각각을 위한 클래스를 구현해야 한다. Collection 을 래핑하고 title의 경우 욕설 검사로직을 수행하는 클래스를 상속하고 글자 제한을 검사하는 등의 로직을 담은 클래스를 만들 수도 있을 것 같다.

🔗 참고 자료

• Redis 공식문서
• NestJS-주문처리과정을-통해-알아보는-수익률-랭킹-조회-Part-4-Redis-Sorted-Set과-Ranking

[sseunghoon]

해당 이슈가 끝나고 Clustering 을 고려할 것