근데 티켓이니 예매니 하는데에 대기열 쑤셔박은건, JSP 나 PHP 같은 것만 할 줄 아는 땔감들이, 멀티 프로세싱에서 임계영역이나 동시성 제어를 할 줄 모르니까 임시방편으로 대기열 넣었을 가능성이 더 크다고 봄.
삼촌(116.40)2019-09-15 22:45
답글
배민도 글케하던데
익명(106.102)2019-09-15 22:45
답글
거기도 땔감이 만들었나보지
삼촌(116.40)2019-09-15 22:45
답글
ㅇㅎ
익명(106.102)2019-09-15 22:46
답글
가령 예매 가능한 티켓이 총 30 부라고 했을 때, 동시에 여러군데서 오는 요청 (이로 인해 PHP 나 JSP 서버 등에서 멀티 프로세스 또는 멀티 스레드가 생성됨) 이 오더라도 티켓은 총 30 부 이상 발부해서는 결코 안 되거든? 근데 땔감 놈들은 이런거에 대한 서버나 전 시스템 수준의 임계영역 제어를 할 줄 모르니까, 아예 프론트 수준에서 대기열로 총 커넥션 수를 30 개로 제한했다거나 이랬겠지 ㅉㅉ
삼촌(116.40)2019-09-15 22:49
답글
ㅠㅠ
포봄(bonnbonn)2019-09-15 22:50
답글
나도 구현해본건아닌데 모든 요청 메시지큐에넣고 순서대로 처리하믄대지않나, 뇌피셜임
익명(106.102)2019-09-15 22:52
답글
근데 락 안걸고 하는방법은 모르겠네
익명(106.102)2019-09-15 22:52
답글
ㅇㅇ 티켓 예매의 경우에는 병렬적인 요청을 순차적으로 처리할 줄만 알아도 대기열 그딴 거 필요없지
아재가 말씀하신 거마냥 대기열 만들어도 실제로 트래픽을 줄이는 효과는 미비한 것도 있고
근데 티켓이니 예매니 하는데에 대기열 쑤셔박은건, JSP 나 PHP 같은 것만 할 줄 아는 땔감들이, 멀티 프로세싱에서 임계영역이나 동시성 제어를 할 줄 모르니까 임시방편으로 대기열 넣었을 가능성이 더 크다고 봄.
배민도 글케하던데
거기도 땔감이 만들었나보지
ㅇㅎ
가령 예매 가능한 티켓이 총 30 부라고 했을 때, 동시에 여러군데서 오는 요청 (이로 인해 PHP 나 JSP 서버 등에서 멀티 프로세스 또는 멀티 스레드가 생성됨) 이 오더라도 티켓은 총 30 부 이상 발부해서는 결코 안 되거든? 근데 땔감 놈들은 이런거에 대한 서버나 전 시스템 수준의 임계영역 제어를 할 줄 모르니까, 아예 프론트 수준에서 대기열로 총 커넥션 수를 30 개로 제한했다거나 이랬겠지 ㅉㅉ
ㅠㅠ
나도 구현해본건아닌데 모든 요청 메시지큐에넣고 순서대로 처리하믄대지않나, 뇌피셜임
근데 락 안걸고 하는방법은 모르겠네
ㅇㅇ 티켓 예매의 경우에는 병렬적인 요청을 순차적으로 처리할 줄만 알아도 대기열 그딴 거 필요없지