결국엔 그냥 별로 정확성이 중요하지않은 데이터라 생각해서 동시성이니 뭐니 그런 개념 생각안하기로했어
select 해서 숫자가져오고 -> +1 -> 다시 save 하는 과정에서 동시에 같은 자원 바라볼때 생기는 race condition 인가가 발생해서
정확한 결과값이 안나온다는 생각과 디시나 펨코같이 대규모 커뮤니티는 어떨까하는 생각으로 그냥 조언을 구한건데,
댓글로 뭐 머리가 모자란거같다, 기초개념도 없는데 고급과정을 하려는거 같다.. 등등 그냥 속으로 생각하면 되는말들을 왜쓰는지
그렇다고 알려주는 것도 아니고 ㅋㅋ 참으로 남 비난하려고 꼬여있더라. 뭐 사용해봐라 / 적용해봐라 / 굳이 즁요한데이터가아니다 등등 고마웠음
뭐 그걸 떠나서
update + 1 하면 동시성 문제 없다는 댓글 보고 찾아보니 update / select for update 구문은 해당 row 에 lock 이 걸린다고하네
(틀린말이면 댓글로 정정좀)
redis 도 써본적이 있어서 생각도 해봤어
조회수를 redis 에 incr 명령어로 1씩증가시켰다가 일정시간 후에 lock 걸고 db에 저장하는 것도 있더라고
덕분에 이것저것 많이 찾아보기도 했다 형들
날 서있는 댓글들은 다 취준중이라고 생각하면 편하다 취준해야 해서 가뜩이나 짜증나는데 엄한데 화 푸는거지
이제 db 커넥션 풀 관리할려면 카프카도 달아야지 ?
조금..더.. 공부해보겠습니다 ㅠ
조회수가 아니라 남은 선착순 개수라면!? - dc App
어... queue 를 활용할 수 있지 않을까요?!!
비꼬는 애들 무시하고 더 깊게 공부 ㄱㄱ - dc App
개인적으로 조회수보다는 윗댓처럼 이벤트쿠폰 10개를 정시에 뿌리는데 10만명이 동시에 누른다면 어떻게 동시성제어를 할까? 생각해보는게 나음 조회수는 아무리봐도 의미가 없음 - dc App
그러면서 각종 기술스택의 고유장점을 파악해보는게 좋음 굳이 카프카나 레디스를 쓴다면 왜 어떻게 돌아가길래 로우레벨도 생각을 확장해보쇼 - dc App
감사합니다
나도 그냥 보다가 궁금해서 내 나름대로 생각을 정리해봤는데 흐름이 맞는지 좀 댓글로 알려주셈 1. 게시글의 조회수를 조회하고 -> 조회수 증가(update) 방식은 로직 간의 원자성이 보장되지 않기 때문에, 동시에 로직이 수행될 경우 일반적으로 같은 값을 조회하고 다른 시점에 업데이트를 쳐서 정확히 계산이 안되는 케이스가 발생(동시성 문제) 2. 이를 해결하고자 UPDATE + 1 쿼리를 사용함으로써, 조회수 조회와 증가를 하나의 원자적인 로직으로 묶어서 처리함 -> 동시성 문제는 해결되지만 게시글을 조회할 때 마다 DB 커넥션을 맺고, 레코드에 X-락을 거는 작업을 매번 수행하기 때문에 동시에 여러 사용자가 같은 게시글을 조회하면 DB 커넥션 풀이 모자라서 대기하는 상황이 발생
3. 비관적 락은 게시글 조회 시 X-락을 획득하는데, 이 락이 해당 트랜잭션이 종료될 때까지 유지되기 때문에 조회 이후 로직이 더 있는 경우 의도치 않게 너무 오래 락을 점유하게 되어서 성능면에서 딸리고, 조회수 증가하는 데에 사용하기에는 투머치함 4. 2번에서 발생하는 문제를 해결하기 위해서는 DB 커넥션 사용횟수를 줄이는 방법을 생각해볼 수 있고, 이럴 때 redis나 inmemory db에 조회수 증분을 기록하여 조회 시에도 빠르게 조회, 한꺼번에 많은 조회수 데이터를 한번의 DB 커넥션 연결로 업데이트 가능 -> 그런데 여기서 동시성 문제가 해결이 되나??잘 모르겠음 헷갈림
ㅇㅇ 그런 흐름 맞음. 마지막에 동시성 문제 해결이 되나?라는 내용은 이제 레디스가 왜 동시성 문제를 처리할 수 있는지 찾아보면 댐. 찾아보면 동시성 문제가 발생하는 근본적인 이유가 무엇인지도 다시 상기시켜줌 레디스가 아닌 인메모리도 예를 들어서 단일 서버라면 HashMap에 Atomic 자료형 추가해서 사용할 수도 있는데, 왜 Atomic 자료형은 동시성 문제를 해결할 수 있는지? 이런거 찾아보면 댐
난 거기서 고민하는거 다른데에도 적용할 수 있는 기반이 다져지니 좋은 고민이라고 생각함. 나도 조회수는 아니지만 쓸모 없는 기능이니 오버엔지니어링이니 이런소리 들었는데, 정작 면접 본 회사들에서 그런 소리 하나도 못들었고 어떤 고민을 했는지 물어보더라. 근데 회사마다 사람마다 다를 수 있으니 조회수가 좀 찝찝하면 윗댓처럼 선착순 쿠폰으로 하는게 제일 좋음
감사합니다
나도 공감함. 실무에서 오버엔지니어링 했다는 것도 아니고 '백엔드 개발자 포트폴리오'인데 자기 기술적 역량을 보여주는 게 좋지
디시 프로그래밍 관련 갤러리들은 지금 죄다 가시 잔뜩 세운 고슴도치들과도 같아요
그럼 병신들 먹이주지 않는게 똑똑한거임 ㅋㅋ 뭐든 깊게 생각해보면 좋지 안좋을게 뭐가있겠음
여기 개병신 취직 못한 망령들 끓어대는 지잡대 열등감 집합소인데 4~5등급 새끼들 말 귀담아 듣지마시고 ~
select 후 +1해서 저장하는게 대체 뭔소리임... update할때 +1 하면서 저장하면 되는데
db 기초도 모르는데 대체 뭘 하려는거임.. 니가 하는건 다 틀린 고민이야 왜냐면 아무것도 모르는데 어디서 줏어들은거로만 상상의 나래를 펼치는거니까
Jpa 쓰면 특정 게시글 번호의 조회수를 가져와서 상태 변경하면 트랜잭션 어노테이션안에 있는 내용이 자동 커밋되면서 업데이트 된다는거 같은데 - dc App
깊은 고민은 좋은데, 개발자에게 필요한건 깊은 고민 말고도 많아 그중 하나는 정확한 목표 설정 능력과 커뮤니케이션 능력인데, 너한텐 그게 부족했던거같음 대부분의 저장소에서 증감에 대한 락을 보장해주기 때문에, 너처럼 일부러 락을 회피하는게 아니면 보장되지 않는 경우가 거의 없어 니가 목표로 삼아야했던건 동시성이 아니라 실시간성이었던거지
정확한 목표 설정을 하려면 베이스 지식이 탄탄해야해, 댓글들에서 널 비난한 이유가 이것 때문일듯
커뮤니케이션 능력은 원인이 뭔지 콕 찝어서 말을 못하겠는데, 니 글을 보고 나도 모르게 어그로가 끌려서 이상한 댓글 달았다 지웠음 (쓸데없는거에 과몰입한다~ 라는 내용) 의미있는 고민이 맞는데도 뭔가 개쓸데없어보이게 만드는 재주가 있는거같다
위에서도 "이벤트쿠폰 10개를 정시에 뿌리는데 10만명이 동시에 누른다면 어떻게 동시성제어를 할까? 생각해보는게 나음" 이라는 이야기가 나왔네 이건 동시성 문제가 아닌데 말이야 아마도 니가 동시성이라는 단어를 계속 써서 사람들 뇌가 고장나버린거같음