이벤트 서버의 성능 테스트 시작(4)

일정이 잡혀있으니... 올만에 쫄렸다. 러프하게 생각했는데..

ㅇ1렇게 공부했음 인서울은.... 지금 다시 수능 보다해도 ㅋㅋ 지방대겠쥬.

평가(?)에 집착하지 말규 잼나게 하자^^

 

처음 부터 다시 시작하자!! 이제 2회차닷!! ㅋ

이벤트 서버의 성능 테스트 시작(1) 에서 작성 했고 참고 했던 링크 걸어둔 블로그를 다시 확인해봤다. 놓친부분이 있는지.. 오히려 이해 안가는 부분이 포착되었다.

 

https://hudi.blog/distributed-lock-with-redis/ (일부 캡쳐)

https://dkswnkk.tistory.com/712(일부 캡쳐)

 

락을 획득 못하면 예외처리가 된다.  그럼 선착순이 맞나??? 오잉..

해서 로그 심어서 비슷하게 테스트..  32번째로 요청했던 친구는 락 획득 못하고 팽 당하고 대략 40번째 친구는 성공..... 띠용

 

사용자 입장에서는...아 나는 아쉽게 안 되었구나..하구 말겠지만... 동시성은 보장해 주나.. 선착순을 보장 못하는 것 같다.

물론 이 또한 내가 잘 이해 못해서 나온 결론일 수 있다... 

 

그리고 분산락을 걸어도 제한된 수보다..넘치게 받아오니 따른 방법으로 환승 gogo!!

 

바쁠수록.. 돌아가라..다른 방법을 모색해야겠다고...지금까지 한 것들은 시원하게 쓰뤠기통!! 영구삭제!!

 

유후!!

https://velog.io/@hgs-study/redis-sorted-set (일부 캡쳐)

 대기열은 그냥 쌓으면 되는 거니깐 굳이 락을??? 동시성을??? 필요 없을 듯하다

1초마다 동기화를 해야 하는 추가적인 작업이 필요하긴 하지만..더 안정적이고 신뢰도가 있어 보인다.

 

구현을 해야 될 것을 다시 정리해보자.!

 

1. 웨이팅 대기열은 순간 끝날 것이다. 모든 친구들이 대기 페이지에 순번을 받고 웨이팅한다.

 

sortSet은 정렬을 하기 위한 데이텨형이 double이다

System.nanoTime()을 더블형으로 넣어야 하는데 정렬을 신뢰 할 수 있을까 해서 챗지피티한테 물어본거였는데.. 좋은 정보를 얻어간다. 

 

 

2. 동기화 작업으로 대기열에서 60명을 결제 대기열로 이동한다.

fun searchWaitRankJoin(key: String, count:Int): Mono<Collection<String>> {
	return redissonReactiveClient.getScoredSortedSet<String>("event:$key:wait").pollFirst(count)
}

 

3. set의 value마다...TTL을 설정할 수 있으면 얼마나 좋을까... 결제 대기열로 인입될 때 별도의 ttl을 설정해 준다.

RedisConfig.searchWaitRankJoin(eventId, (60 - tuple.t2)  - tuple.t1)
            .doOnNext { list ->
                list.forEach{userId ->
                    RedisConfig.addJobJoin(eventId, userId)
                        .filter { isOk -> isOk }
                        .flatMap {  RedisConfig.setTtl( "ttl:$eventId:$userId") }
                    .subscribe()
                }
            }.subscribe()

 

4. ttl을 확인해서 결제 행위를 하지 않은 친구들을 제거해 준다. 그리고 그 친구들만큼 add한다. ( 4번 -> 3번을 1초 ∞)

RedisConfig.searchJobJoin(eventId)
.collectList()
.doOnNext { keys ->
                keys.forEach {userId ->
                    RedisConfig.getTtl( "ttl:$eventId:$userId")
                        .filter{ isOk -> !isOk}
                        .flatMap { RedisConfig.removeJobJoin(eventId, userId)}
                        .subscribe()
                }
}
.subscribe()

 

 

동시 접속자가 많지는 않지만 뭔가 있어보인다.ㅋㅋ

 

vue를 작업하면서 문득.. 나의 프론트엔드 실력도  발전한 것 같다...물론 시간은 여전히 많이 걸리지만 작업하는 것이 수월해 졌다.ㅋㅋ

프론트 개발자여!! 빨리 좀 뽑히자 ㅠ 결제 대기 순서는 2초에 한번씩 setInterval로 진행했지만..

 

소켓통신 해보자잉!!

 

진정 성능테스트는..언제..

그나마 조금은 했으니. 로직 변경해서 락도 없으니 크게 문제 없을것 같다. 네이버 클라우드가 버텨준다면 ㅎ.

동일한 강의에 대한 다른 시간대별 이벤트를 동시에 2개 띄어야 한다. 담주가 기다려진다