소프트웨어 설계 문제를 해결하기 위한 재사용 가능한 해결책객체지향 설계 원칙을 기반으로 유사한 문제를 해결하는 공통된 방식코드를 더 효율적, 유지보수하기 쉽게, 확장 가능하게 만든다.  디자인 패턴의 3가지 유형생성 패턴구조 패턴행동 패턴 사용하는 이유코드 재 사용성 증가 -> 같은 문제를 다시 해결할 필요 없음유지보수 용이 -> 코드가 명확해지고 수정이 쉬움확장성 증가 -> 기존 코드를 수정하지 않고 기능 추가 가능개발 속도 향상 -> 검증된 설계 방식을 따르므로 효율적  1. 생성 패턴 (객체 생성을 캡슐화하여 유연성을 높임)-> 객체 생성을 new로 직접 하지 않고, 특정 메서드나 클래스를 통해 관리함 패턴설명싱글톤(Singleton)하나의 인스턴스만 생성, 전역적으로 접근 가능팩토리 메서드(Fac..

트랜잭션의 격리 수준은 데이터베이스에서 동시에 실행되는 여러 트랜잭션이서로 간섭하지 않도록 격리하는 정도를 설정하는 기준이다.데이터의 일관성을 유지하면서 성능을 최적화하기 위해 사용 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으..

Redis는 NoSQL 데이터 베이스중 하나로,인 메모리 데이터베이스이며, 주로 키-값 저장소로 사용된다.데이터는 메모리에 저장되기 때문에 빠른 읽기/쓰기가 가능하다.  NoSQL(Not Only SQL) ↔ (Relational DataBase Management System) → 비관계형 데이터 모델인 NoSQL은 테이블간의 관계를 정의하지 않고,데이터를 자유롭게 정의할 수 있음  대충 NoSQL은 아무렇게 놔둬서 대충 집어서 쓰기 좋음RDBMS는 정리정돈 해야해서 조금 느리지만 효율적임  인 메모리 ? → 디스크를 사용하는 Database와는 달리, 메모리를 사용하는 Redis는 훨씬 빠르다.   Redis의 특징키-값 저장 외에도 리스트, 집합, 정렬, 해시, 비트맵 등등 다양한 데이터 구조를 지..

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