일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 웹사이트최적화기법
- 성능
- 푸시
- nginx설치
- JPA
- kafka
- notification
- php
- 웹사이트 성능
- 레디스
- NoSQL
- nginx
- APNS
- 페이스북
- Push
- gcm 푸시 번역
- nginx설정
- 디자인패턴
- redis
- 카프카
- GCM 번역
- 자바스크립트
- 웹사이트성능
- GCM
- Design Pattern
- git
- 푸시 번역
- 페이스북 번역
- Today
- Total
목록2024/11/22 (2)
간단한 개발관련 내용
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로 새 프로듀서가 시작된 경우.이 상황에서 두 프로듀..