728x90
문제 상황
이전에 낙관적 락을 이용하여 동시성 이슈를 해결하려고 했습니다.
저희 서비스는 낙관적 락을 이용하면 데드락(Deadlock)이 발생합니다. 그리고 여러 계정이 동시 요청이 왔을 때 성능 저하가 뚜렷합니다.
해결 방법
Like 엔티티 동시성 이슈 해결
Like 엔티티에 유니크 제약 조건을 걸어 Like 엔티티에 값이 중복되어 들어가는 것을 방지하겠습니다.
LikeEntity
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(uniqueConstraints = {
@UniqueConstraint(
name = "user_board_post_unique",
columnNames = {
"user_id",
"board_post_id"
}
)
})
@Getter
public class Like extends BaseTimeEntity {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "like_id")
private Long id;
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id")
private User user;
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "board_post_id")
private BoardPost boardPost;
@Builder
public Like(User user, BoardPost boardPost) {
this.user = user;
this.boardPost = boardPost;
}
}
데드락 발생 해결
BoardPost 엔티티에 likeCount 컬럼을 업데이트 하는 로직을 삭제해서 데드락을 피합니다.
유니크 제약 조건 적용 후 테스트
위 코드처럼 유니크 제약 조건을 설정하고 addLikeCount를 사용하지 않았습니다.
Jmeter를 이용하여 스레드100 설정 후 테스트 해보겠습니다.
유니크 제약 조건에 의해 예외가 발생합니다.
이러한 예외는 공통으로 처리해도 무관하다고 합니다.
이러한 방식으로 동시성 문제를 완벽하게 해결할 수 없었습니다.
위에 글에서도 동시성 문제를 해결할 수 없다고 나와있습니다.
조금이라도 문제를 개선하고 싶으면 좋아요, 좋아요 취소 Api를 생성해서 해결할 수 있습니다.
제가 테스트했을 때 이러한 경우에 동시성 문제를 해결할 수 있다고 생각합니다.
현재 서비스에서는 동시성 문제가 터질 일이 적다고 판단하여 Api를 따로 나누지는 않았는데, 추후에 개선해보겠습니다.
과정에서 깨달은 점
1. 유니크 제약 조건을 사용했을 때 발생하는 예외와 예외처리에 대해 알게 되었습니다.
2. 데드락 발생 원인과 해결 방법에 대해 알게 되었습니다.
3. Lock을 사용하는 것보다 유니크 제약 조건을 사용하는게 성능 측면에서 훨씬 우수합니다.
728x90
'데이터베이스' 카테고리의 다른 글
동시성) 싱글벙글 게시글 좋아요 Lock을 이용하여 동시성 이슈, 데드락 해결하기 (1) | 2023.10.04 |
---|---|
Database - 과제4 JDBC (0) | 2022.07.15 |
Database - JDBC연동 (0) | 2022.07.14 |
Database - 데이터 삽입,수정,삭제 (0) | 2022.07.14 |
Database - 테이블 생성 (0) | 2022.07.14 |