트랜잭션의 격리 수준은 데이터베이스에서 동시에 실행되는 여러 트랜잭션이서로 간섭하지 않도록 격리하는 정도를 설정하는 기준이다.데이터의 일관성을 유지하면서 성능을 최적화하기 위해 사용 1. Read Uncommitted(커밋되지 않은 상태 읽기) 다른 트랜잭션이 아직 커밋하지 않은 변경 내용도 읽을 수 있다.데이터 일관성 보장 정도가 가장 낮음 장점가장 높은 성능단점Dirty Read : 다른 트랜잭션이 롤백한 데이터를 읽을 수 있음Non-repeatable Read : 같은 데이터를 두 번 읽었을 때 결과가 다를 수 있음Phantom Read : 한 번의 쿼리에서 보이지 않던 데이터가 이후 쿼리에서 나타날 수 있음 2. Read Committed (커밋된 상태 읽기) 커밋된 데이터만 읽을 수 있다.트랜잭..

동시성 제어  다수의 사용자 또는 프로세스가 동일한 자원(데이터)을 동시에 접근하거나 수정하려 할 때발생하는 문제를 방지하기 위한 기법   락을 관리하는 방식으로낙관적 락비관적 락분산 락락을 획득하는 방식으로공정 락비공정 락 으로 나눌 수 있다.락을 관리하는 방식에 따라 낙관적 락, 비관적 락, 분산 락 1. 낙관적 락 (충돌은 자주 일어나지 않아!)  @Version 어노테이션을 사용해 엔티티의 버전을 관리한다.데이터 수정 시 현재 버전을 확인한 뒤 수정하며, 충돌 발생 시 예외를 발생충돌이 없을 경우 업데이트와 함께 버전 증가 장점Lock을 사용하지 않으므로 트랜잭션 간 대기 시간이 없다.읽기 작업이 많은 시스템에 적합함.단점:충돌이 잦은 경우, 예외(OptimisticLockingFailureExc..

Kafka란? 오픈소스 분산 메시지 스트리밍 플랫폼으로, 대규모 데이터를 실시간으로 처리하거나저장, 전송할 때 주로 사용한다. 빠르고 안정적이며 확장성까지 뛰어난 시스템이다.   Kafka의 주요 구성요소 Producer : 데이터를 Kafka로 전송하는 클라이언트주로 애플리케이션에서 생성된 데이터를 Topic으로 보냄데이터를 어떤 Partition에 보낼지 결정함Consumer : Kafka로부터 데이터를 읽어오는 클라이언트Consumer Group을 이용해 여러 Consumer가 데이터를 분산 처리 가능Broker : Kafka 클러스터의 각 서버데이터를 저장하고, Producer와 Consumer의 요청을 처리Topic : 데이터의 카테고리 또는 스트림을 정의Topic은 여러개의 Partition으..

기존 코드  AWS S3에서 파일을 삭제하고, delete를 통해 DB에서 지우면 끝이겠거니, 했는데     S3에는 지워져있지만, DB에는 남아있는 상황  Repository.delete를 하면 당연히 지워져야 하는게 아닌가? 했던 생각이 너무 안일했다.    둘이 손을 꼭 잡고있는데, File을 단순히 삭제 하려해도,Card가 꼭 잡고있기 때문에, Card에게도 이별통보를 해야한다.    이제.. File을 놓아줘..  ..  ..    삭제 ^^..   원인 Delete 쿼리는 Flush 이후에 나감→ JPA는 DB와 직접적으로 상호작용하지 않고 영속성 컨텍스트를 사용함.따라서 Flush 호출 전까지 변경사항이 DB에 반영되지 않음.삭제(delete)도 바로 DB에 반영되지 않고, 영속성 컨텍스트에..

문제 발생 1. 동일한 요청에 대해 매 번 외부 API가 호출되어성능 저하 및 불 필요한 트래픽, 불 필요한 추가비용이 발생하였고,이로인해 캐싱을 해야겠다는 결정을 함. 2. 캐싱한 이 후에 테스트를 돌려보니초당 10명의 동시 접속이 있을 때, 캐시가 있음에도 불구하고API가 중복으로 호출되는 현상 발생.  문제 해결 (수치 , 개선방법, 의사결정 과정 ) 1. 캐시 저장 및 조회 로직 구현Redis 캐시를 사용하여 API 호출 결과를 저장.API를 호출하기 전에 Redis에서 해당 데이터를 먼저 조회 (redisTemplate.opsForValue().get(cacheKey))캐시된 데이터가 있으면 API 호출을 생략하고 캐시된 데이터를 반환.캐시된 데이터가 없다면 API를 호출하여 데이터를 가져오고,..

개개인의 유저들은 여러 채널에 가입할 수 있고,한 채널에 여러 유저들이 가입되어있다. 이런 Many : Many 관계는 이해하기도 힘들 뿐더러, 쿼리도 복잡해지고 실수할 가능성이 높아진다. 그래서 중간에서 둘 사이를 중재해줄 중간 테이블이 필요한데,    테이블 명은 보통 두 엔티티를 붙여서 명명한다.     가운데 중간 테이블은 채널에 가입한 유저들 명단처럼 작성되었다.   간단하게 @ManyToMany를 사용하여 해결할 수도 있지만,내부 어노테이션을 제어하기가 힘들기 때문에각각의 엔티티는 @OneToMany를 사용하고, 중간테이블은 @ManyToOne으로 각각 연결한다.    User@OneToMany(mappedBy = "user", cascade = CascadeType.ALL, orphanRem..