해결된 질문
작성
·
96
·
수정됨
0
학습 관련 질문을 최대한 상세히 남겨주세요!
고민 과정도 같이 나열해주셔도 좋습니다.
먼저 유사한 질문이 있었는지 검색해보세요.
인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
[인기글 Producer&Consumer 테스트] 강의 6분 30초에서 좋아요 수는
userId는 유니크해야 좋아요 수가 중복없이 하나씩으로 집계된다고 말씀하셨습니다.
근데 비관적 락 방법 1과 2 그리고 낙관적 락 방법 모두 다 저희가 구현할 때,
따로 userId에 대한 중복 처리는 하지 않았는데
userId는 동일해도 상관 없지 않나 싶어서요.
비관적 락 방법 1 쿼리도 단순 where 조건은 articleId 뿐이라서 질문드려봅니다.
게시글 조회수는 redis로 key 생성할때, articleId와 userId를 활용해서 중복처리는 했는데,
게시글 좋아요수는 redis를 활용하지 않아서요!
답변 2
0
parkhs님, 안녕하세요!
좋아요의 정책은 각 사용자는 게시글마다 1회만 수행할 수 있었고,
그렇기 때문에 (articleId, userId)에 유니크 인덱스가 걸려있었습니다.
애플리케이션에서 중복 방지 코드를 따로 넣지 않았더라도, 유니크 인덱스에 의해 중복된 데이터에 대한 요청은 이미 실패하게 되는 상황입니다!
그래서 6분 30초에 나타나는 테스트코드처럼 좋아요 데이터를 넣어서 likeCount만큼 좋아요 수를 만드려면, 모두 다른 userId가 필요하게 됩니다.
0
안녕하세요, 인프런 AI 인턴입니다. parkhs님.
질문 주신 내용은 좋아요 수 집계에서 userId의 중복 처리가 필요한지에 대한 것으로 보입니다. 아래 내용을 통해 정리해보겠습니다.
userId
와 articleId
를 복합 키로 설정하여, 특정 사용자가 특정 게시글에 대해 여러 번 좋아요를 누르는 것을 방지합니다.userId
와 articleId
의 조합에 유니크 제약 조건을 설정하여 같은 사용자가 동일한 게시글에 중복 좋아요를 방지하는 것이 일반적입니다.관련하여 유사한 문제를 다루고 있는 링크를 소개드리니 참고하시기 바랍니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.