prisma랑 react-query next-auth tailwind 등
좀 익숙해질겸
로그인(구글만) 글 댓글 답글 페이지네이션 등등
흔하디 흔한 crud 작업 중인데
추천 비추까진 구현했는데
추천 n개 이상 개념글 기능 구현하려다 보니 깨달음을 얻음.
만약 n개 이상 추천이 박혀서 개념글을 보냈는데
추천 취소 기능이 있을 경우
추천이 취소된 거를 개념글을 취소해야 하나 부터
추천 비추천 취소까지 허용한 상태인데
추천 누른 상태에서 비추 누르면
기존에 존재하는 추천 delete + 새로운 비추천 post 되도록 구현했는데
이렇게 될 경우 리퀘스트만 벌써 2개 날리는 거임.
사람 조금만 많아지더라고 서버 못버티겠더라고
왜 디씨나 인벤, 펨코 같은 사이트들이 추천 취소를 안 넣었는지도 알겠더라
디씨처럼 개념글 기능도 존재하면서 유튜브처럼 좋아요 싫어요 취소도 할 수 있게 해주세요!
이렇게 한 번에 두 마리 토끼는 못 잡는다는 걸 깨달았음
규모가 전부다!
추천수나 조회수는 사실 굉장히 정밀할 필요는 없잖아? 집계나 이런건 정확해야 하지만. 추천이나 조회수 같은건 30개든 28개든 딱히 중요하지 않은 정보임. 그렇다면 속도를 위해선 추천 delete 비추천 post 이렇게 두개하지말고 push만 하도록 하는건 어떨까?
이게 맞다
뭔소리임 추천 비추천 처리하는데 비용이 얼마나든다고 근들갑ㄴ
likeCount, likes=[{id:'abc',count:1},{id'abc',count:-1]] 이렇게 푸쉬만하고 request를 끝내고, 봇같은게 자주 돌면서 count를 reduce하고 likeCount에 다시 써놓는거지.
보통은 splice 같은걸로 자르기도 하는데 동시성 접근에서 문제가 될 수 있다보니(동시에 누르면 한놈이 누락될 가능성) 그냥 push만 하게 두는 경우가 있음.
여기부터는 잘 모르는 내용이네... 좋은 정보 ㄳㄳ
친절한 퇴물이형이 설명해준다. 서버 인스턴스가 여러개 있고, 로드벨런서가 트래픽을 배분하는 상황이라고 할 때, 거의 동시(0.001초)에 접속한 경우 각자 마지막 조회수에서 viewCount++ 한 경우, 실제로 두군데서 하니까 동일한 조회수에서 +1 하니까 +2가 실제론 맞는데 +1이 되는 경우가 있음. 이게 동시성 문제임. 생각보다 흔하게 발생 됨. 내 계정의 회원포인트가 있는데 포인트를 쓴 시점과, 다른 봇 작업등을 통해서 들어오는 포인트 지급이 겹쳐질 때 정산이 안맞는 상황이 발생하는거지. 다시 위의 문제로 돌아오면, 취소 구현을 위해서 추천 아이디를 빼고 어레이를 다시 재정립해야되는데. 그사이에 또 누가 추천 누르게 되면 누락이 발생함.
그래서 보통 어레이에 append만 하게 되는 경우 DB는 이런 Insert 작업을 Table Lock을 걸던지 Document(Record) Lock을 걸던지해서 여러 쿼리가 동시에 들어와도 순서를 지켜가면서 append 를 시킴. MongoDB라면 $push. 락이 풀릴때까지 쿼리를 딜레이시켜버림. 근데 카운팅은 또 따로 10초마다 빠르게 봇이 돌면서 업데이트가 된게 있으면 어레이를 뒤져서 Count를 10초마다 한번씩 업데이트 해주는거지. 10초 늦어도 뭐 상관할 사람 없으니까. 이렇게해서 누락을 없에고 좀더 고속처리를 하게 됨. 자세한건 RabbitMQ를 배워보면 좋을꺼야.
ㄳㄳ 내일 출근하면서 한번 더 읽어볼게용
그렇게 클라에서 쿼리를 두번날리는건 좋은 방식이 아님. 차라리 엔드포인트를 하나 더 열어서 거기다가 한번에 요청하든가 해야지
그리고 추천, 비추같은건 누르자마자 클라에서는 눈속임으로 +1만 보여주고(나중에 서버 response가 오류로 나오면 1 까든가 하면됨) 서버에서는 추천비추같은건 총합이 중요하지 그 중간엔 사실 몇초 늦어도 되거든 그래서 webflux같은걸로 비동기로 쌓아도됨
이것도 고쳐야겠다. 그냥 엔드포인트 따로 파서 하는 게 맞을 듯
디씨 펨코 xe 라이믹스 같응 좆틀딱프레임워크. 인벤도 php 씹틀딱이라 그런건데
펨코 추천 취소 도입함. 시간제한 빡빡하긴 한데 됨.