오늘은 발표자료 제작과 발표 및 KPT, 다면평가 위주로 진행되었다. KEEP 프로젝트 진행 중 생긴 문제를 원인 - 해결책 - 결과 순으로 잘 정리하였다 깃헙 프로젝트 같이 협업 툴 이용 적극적으로 하였다 문제를 해결할 때 팀원 모두가 참여하여 노력하였다 PROBLEM 스핀락의 경우엔 락점유를 위해 계속 시도를 하는데 이 과정에서 만료시간의 정책이 필요하다 글로벌 락을 많이 쓰게 될텐데 Rpop Lpush 라는 것을 이용해보자 테스트 코드에서 벽을 느꼈다 TRY 서버에 부하가 덜 가해지도록 시간정책을 구성하자! push(lpush, rpush)와 pop(lpop, rpop)을 적용해보자! 테스트 코드를 좀 더 연습해보자! 이후엔 개인공부시간을 가지다가 7시에 튜터님께 궁금한점을 하나 물어보았다. 우리는..

오늘 공부한 내용 Redisson을 이용한 Lock 구현 기존에 사용하던 Lettuce는 락을 점유할때 까지 레디스에 요청을 계속 보내는 형식의 SpinLock 형태이다. 요청을 끊임없이 계속해서 한다는 것은 결국 CPU resource를 끊임없이 사용한다는 의미다. 이렇게 CPU를 계속 낭비하게 되면,, 다른 일을 해야하는 스레드들이 CPU에서 작업할 수 있는 기회는 줄어들게 된다 결국 프로그램의 퍼포먼스는 안좋아 지고, 컴퓨터 시스템 전체적으로도 응답성이 나빠지게 된다 그런 대안점으로 사용하려하는것이 Redisson을 이용한 Pub-sub기반 Lock 이 Lock을 설명해보자면 Pub-sub 기반으로 Lock 구현 제공 Pub-Sub 방식이란, 채널을 하나 만들고, 락을 점유중인 스레드가, 락을 해제..

오늘 공부한 내용 Lettuce클라이언트를 이용한 Lock 구현 처음 동시성을 제어하기 위해 @Synchronized 를 이용했다. 우리가 만들어놓은 테스트코드로는 싱크로나이즈드만으로도 해결이 가능했다. 하지만 자바의 Sychronized는 하나의 프로세스 안에서만 보장이 됩니다. 즉, 서버가 1대일때는 문제가 없지만 서버가 2대 이상일 경우 데이터에 대한 접근을 막을 수가 없습니다. 이러한 문제점이 있었다. 그러기에 @ Synchronized 를 사용하기보단 직접 Lock을 구현하여 동시성을 제어하는게 맞다고 판단되었다. 우선 이 Lock 이란것부터 알아보자. 락에는 비관락, 낙관락이 있다. 낙관락은 실제로 Lock 을 이용하지 않고 버전을 이용함으로써 정합성을 맞추는 방법입니다. 먼저 데이터를 읽은 ..

오늘 작업한 내용 1. 테스트코드 작성 및 DB연결 2. RedisLock 공부 1. 테스트코드 작성 및 DB연결 동시성 제어를 위한 테스트 코드를 작성한 후 이를 테스트용 DB에 연결하도록 코드를 작성하였다. 이번 테스트를 위해 사용한 DB는 h2 데이터베이스 테스트용으로 걸맞는 가벼운 DB이다. 기록용으로 Yml 파일을 남겨놓음 spring: data: redis: host: 3.39.34.103 port: 6379 jpa: hibernate: ddl-auto: update properties: hibernate: format_sql: true highlight_sql: true use_sql_comments: true default_batch_fetch_size: 500 logging: level:..

오늘 진행한 것 1. Category페이지네이션 작성 2. CreateTicketTest 코드작성 우선 1. Category페이지네이션 작성 처음엔 CategoryResponse 안에 Goods리스트를 같이 포함하여 반환할까 생각해서 Response에 goodsList를 추가하였다. 하지만 승환님의 의견에 따라 우리의 와이어프레임기준으로는 goodsList를 반환하는건 따로 구현이 되어있고, https://www.notion.so/A05-e753a98e639a4c3f9403b9d1e9623e8a?pvs=4#da0eaf516d7f42b6a163b4ee29f5d6d9 (위는 우리가 작성한 S.A.의 와이어프레임 사진 링크) 카테고리는 그냥 링크의 역할만 해주면 될것 같아서 Response에서 goodsLis..

오늘 한일 1. TicketCRUD 보완점 수정 - 1차적으로 완료하고 다른부분 개발과정때문에 아직 작성하지 못했던 부분(서비스 임플, 컨트롤러 등)들을 마저 완료해주었음 2. 각 Entity간의 관계 설정 - 다른 패키지들의 CRUD가 거의 완성됨에 따라 각자의 관계(일대다, 다대일, 양방향, 단방향) 등의 고민을 해보았고, 문제는 우리가 사용한 어노테이션 OnDelete와 소프트 딜리트를 위한 SQLDelete가 서로 맞물리지 않는다는 거였다. OnDelete는 OneToMany에 걸어주는 cascade와 같이 한쪽 객체에서 Delete 쿼리가 날라갈때 다른쪽에도 같이 날려주는 역할이고 SQLDelete는 Delete쿼리가 날라갈때 우리가 설정해놓은 다른 쿼리로 대체되어 날라가게 해주는것이다. @SQ..