간단한 개발관련 내용

16.1 트랜잭션과 락16.1.1 트랜잭션과 격리 수준트랜잭션은 ACID를 보장해야한다.원자성 (작업에 대한 것) - Atomicity트랜잭션 내의 작업은 모두 성공하거나 실패해야한다일관성 (데이터에 대한 것) - Consistency모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다격리성 (트랜잭션에 대한 것) - Isolation트랜잭션의 분리 및 보장동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 예를 들어 동시에 같은 데이터를 수정하지 못하도록 한다.지속성 (데이터에 대한 것)- Durability트랜잭션을 성공적으로 끝내면 그 결과가 항상 기록되어야 한다. 중간에 시스템에 문제가 발생해도 데..

예외처리엔터티 비교프록시 심화 주제성능 최적화N+1 문제읽기 전용 쿼리 최적화배치처리SQL 쿼리 힌트트랜잭션을 지원하는 쓰기 지연과 성능 최적화15.1 예외처리15.1.1 JPA 표준 예외 정리JPA 표준 예외들은 RumtimeException 을 상속하는 javax.persistence.PersistenceException의 자식 클래스들이다.트랜잭션 롤백을 표시하는 예외심각한 예외로 복구해서는 안되고javax.persistence.RollbackException 예외가 발생한다.트랜잭션 롤백을 표시하지 않는 예외심각한 예외가 아니라 판단에 따라 복구해도 된다15.1 .2 스프링 프레임워크의 JPA 예외 전환데이터 접근 계층에 대한 예외를 추상화해서 개발자에게 제공15.1 .3 스프링 프레임워크에 JP..

7.1 신뢰성 보장카프카는 다음과 같은 신뢰성 보장을 제공:메시지 순서 보장: 동일한 프로듀서가 동일 파티션에 쓴 메시지는 순서를 유지.커밋된 메시지 보존: 모든 인-싱크 레플리카에 저장된 메시지는 최소 하나의 레플리카가 살아 있는 한 유실되지 않음.커밋된 메시지 소비: 컨슈머는 커밋된 메시지만 읽음. 7.2 복제카프카는 복제를 통해 데이터 지속성과 고가용성을 보장.인-싱크 레플리카:조건:Zookeeper와의 세션이 유지됨(기본 6초).최근 10초 이내에 리더 레플리카와 동기화.최신 메시지를 복제 완료.복제 지연 발생 시 아웃-오브-싱크 레플리카로 간주되어 신뢰성 저하. 7.3 브로커 설정복제 팩터:높은 복제 팩터 → 가용성과 신뢰성 증가, 디스크 사용량 증가.설정:replication.factor (토..

1. 카프카 트랜잭션의 목적Exactly-once semantics (EoS): 메시지를 정확히 한 번만 처리.프로듀서-컨슈머 간 원자적 작업:데이터 생산(프로듀서) 및 소비(컨슈머)를 원자적으로 연결.데이터 무결성:장애 발생 시 중복 메시지 방지 및 데이터 일관성 유지. 2. 카프카 트랜잭션의 주요 구성 요소transactional.id:트랜잭션을 구분하는 고유 ID.프로듀서는 transactional.id를 기반으로 트랜잭션 작업을 수행.Producer ID (PID):프로듀서 인스턴스에 부여되는 고유 ID.브로커는 PID를 통해 트랜잭션 상태를 관리.Epoch:트랜잭션 버전 관리.장애 복구 시 동일한 transactional.id로 중복 작업 방지(팬싱).트랜잭션 로그:브로커는 트랜잭션 상태(시작,..

카프카 트랜잭션의 팬싱(Fencing)은 트랜잭션 프로듀서 간의 중복 방지 및 일관성 보장 메커니즘입니다. 이 기능은 트랜잭션 ID(transactional.id)를 기반으로 작동하며, 특정 트랜잭션이 잘못되거나 장애 상황이 발생했을 때, 중복 트랜잭션 프로듀서가 메시지를 잘못 기록하는 것을 방지합니다.1. 팬싱이 필요한 이유트랜잭션 프로듀서는 상태를 유지하며 트랜잭션 ID(transactional.id)를 통해 클러스터와 연관됩니다. 이때 다음과 같은 상황에서 중복 프로듀서가 발생할 수 있습니다:프로듀서 장애로 인해 클러스터와 연결이 끊긴 경우.네트워크 지연 또는 일시적인 장애로 기존 프로듀서가 복구되지 못했는데, 동일한 transactional.id로 새 프로듀서가 시작된 경우.이 상황에서 두 프로듀..

카프카 완벽 가이드 6장 요약: 카프카 내부 매커니즘6.1 클러스터 멤버십카프카는 브로커의 목록을 유지하기 위해 Apache Zookeeper를 사용.Zookeeper는 브로커가 클러스터에 속해 있는지 확인하고 리더 선출 등 여러 작업을 수행.6.2 컨트롤러컨트롤러 역할:파티션 리더 선출 및 메타데이터 관리.브로커가 추가되거나 제거될 때 파티션의 리더를 선출하고 클라이언트 요청 처리 시작.KRaft (Kafka Raft):Zookeeper 의존 제거: 자체적으로 리더 선출 및 메타데이터 관리.액티브 컨트롤러가 브로커 요청 처리, 팔로워 컨트롤러는 데이터 복제.메타데이터 동기화 및 성능 병목 해결.6.3 복제 (Replication)리더 레플리카:파티션의 리더 역할을 수행하며 쓰기 요청 처리.클라이언트 요..