이벤트 스트리밍 및 실시간 데이터
(섹션: 기술 및 인프라)
간략한 요약
이벤트 스트리밍은 이벤트가 나타날 때 이벤트를 처리하고 전달하는 것입니다. iGaming의 경우 이는 베팅, 예금, 사기 방지 신호, 책임있는 게임 제한, 토너먼트 테이블 및 개인 제안에 대한 즉각적인 반응을 의미합니다. 기본 벽돌: 이벤트 버스 (Kafka/Pulsar), 스트리밍 엔진 (Flink/ksqlDB/Spark Structured Streaming), 트랜잭션 데이터베이스 (Debezium) 의 CDC, 온라인 ML 기능 저장소 및 실시간 분석 (실시간보기, OLAP)
iGaming에서 중요한 곳은 어디입니까?
사기 방지 및 위험: <100-300ms의 거래 점수, 행동 패턴의 상관 관계, 차단 및 에스컬레이션.
책임있는 게임: 제어, 손실률, 비정상적인 동작-경고 및 실시간 자동 제한.
지불: 상태 밸브, 웹 후크 PSP, 스마트 재 시도, 잔액 투영, SLA "시간 지갑".
게임 이벤트: 토너먼트 리더 (슬라이딩 창) 계산, 라이브 게임 라운드, CRM/마케팅을위한 실시간 피드.
개인화: 온라인 기능 (RFM, 성향) → 트리거 캠페인, 몇 초 내에 푸시/이메일.
운영 분석: p95/p99 대기 시간, 깔때기 단계 변환, 플랫폼 상태 신호.
건축 모델
람다 vs 카파
Lambda: 배치 (DWH/ETL) + 스트리밍 (작동). 또한-유연성과 "저렴한" 벡치; 마이너스는 이중 논리입니다
Kappa: 모든 것은 잡지 (Kafka) 의 개울과 같습니다. 또한-단일 코드, 이벤트 재생; 마이너스-더 엄격한 인프라 요구 사항
연습: 중요한 실시간 윤곽을위한 - Kappa; 보고/ML 교육-추가 배치 회로.
이벤트 파이프 라인 (참조)
1. 제조업체: 베팅/결제 서비스는 도메인 이벤트를 게시합니다 (Outbox → Kafka).
2. 버스: 키별로 부품이있는 카프카 ('player _ id', 'bet _ id').
3. CDC: Debezium은 OLTP (밸런스, 한계) 에서 스트림으로 변경을 가져옵니다.
4. 스트리밍: Flink/ksqlDB/Spark-집계, 창, CEP, 가입.
5. 프로젝션: 구체화 된 테이블 (Kafka Streams 주 상점/ksqlDB 테이블/Redis), OLAP (ClickHouse/Druid).
6. 소비자: 사기 방지, CRM, 알림, 대시 보드, 워크 플로 트리거.
데이터 계약 및 스키마
Avro/Proto + Schema Registry: 엄격한 계약, 역 호환 마이그레이션.
버전: '도메인. 이벤트. v {n} '; 변경 중단을 금지합니다
PII: 토큰 화/암호화, 마스킹, 목적 제한 (GDPR).
배달 의미론 및 demmpotency
적어도 한 번은 사실상의 표준입니다 (복제 가능) → demempotent 처리가 필요합니다.
정확히 한 번 스트리밍: Flink/Streams의 Kafka + EOS 트랜잭션 제작자; 더 비싸고 적용 포인트 (돈/잔액).
송신기 + CDC: 서비스 데이터베이스의 단일 진실 소스, 이중 쓰기 보호.
데드 업: 키 ('idempotency _ key'), TTL이있는 중복 제거 테이블, upsert/merge.
시간 창 및 "늦은" 데이터
창:- 텀블링-고정 슬롯 (예: 1 분의 회전).
- 호핑-증분으로 미끄러짐 (예: 1 분 단위로 5 분의 창).
- 세션 - 비 활동 (플레이어 세션).
- 워터 마크: 이벤트 타임 처리, 지연 시간, DLQ/사이드 출력 대피.
- CEP (복잡한 이벤트 처리): 패턴 "3 분 안에 A, B", "M 초 안에 N 이벤트", "취소/보상".
상태 및 스케일링
안정적인 연산자: 집계/조인은 상태를 유지합니다 (RocksDB 상태 백엔드).
Changelog 주제: 신뢰성 및 상태 복구.
역압: 자동 속도 제어, 시스템 싱크/제한.
주요 분포: 무거운 타자 → 키 소금, 왜곡 완화.
모니터링 및 SLO
스트림 SLO: p99 엔드-투-엔드 대기 시간 (예: 9%.
측정 항목: 처리량, 당사자 별 지연, 워터 마크 지연, 드롭/레이트 비율, 역압, 바쁜 시간 운영자, GC/JVM.
경고: DLQ 성장, 워터 마크 지연, EOS 체크 포인트 실패, 온라인/오프라인 rassinh 기능.
추적: 프로듀서 스트림 소비자를 통한 공동 관계 ID ('trace _ id', 'messation _ id').
안전 및 준수
주제/테이블의 TLS/RBAC, 민감한 도메인의 세분화 (지불/CCM).
전송/온 디스크의 PII 암호화; Vault/SOPS의 비밀.
데이터 유지 및 지역: 지역 별 저장 (EU, 터키, LatAm), 제거 정책.
감사: 누가 출판/읽고, 대본의 재현성.
높은 가용성 및 DR
카프카: '복제. 계수 이하 3 ',' 분. 동기화되지 않았습니다. DR의 복제본 ',' acks = all ', 교차 영역 복제 (MM2)
Flink/Streams: 제어 된 릴리스를위한주기적인 체크 포인트 + 세이브 포인트; HA-JobManager.
OLAP: 세그먼트 복제, 복제본 읽기; 장애 (게임 데이) 테스트.
성능 및 튜닝
프로듀서: 버칭 ('남아 있습니다. ms ',' 배치. 크기 '), 압축 (lz4/zstd).
소비자: 정확한 'max. 설문 조사. 간격 ', 백오프 중 파티 일시 중지
분할: 대상 TPS 및 병렬 처리에서 당사자를 계산합니다.
상태: RocksDB 옵션 (블록 캐시/쓰기 버퍼), NVMe/IOPS, 피닝.
네트워크: 10/25G, Tuning, n + 1 싱크 요청 격리.
구현: 핵심 기술
Shina: Apache Kafka (대안: Pulsar, Redpanda).
스트리밍: Apache Flink, Kafka Streams, ksqlDB, Spark Structured Streaming
CDC: Debezium (MySQL/Postgres), 전송 커넥터.
프로젝션 리포지토리: ksqlDB 테이블, Kafka Streams 주 상점, 낮은 대기 시간을위한 Redis, OLAP를위한 ClickHouse/Druid/Pinot.
Fichestor: 축제 또는 자체-온라인 (Redis) + 오프라인 (Parquet/Bigquery), 일관성 보장.
디자인 패턴
전송 메시지 → Kafka: DB 트랜잭션의 각 도메인 이벤트.
사가: 사건을 통한 보상; 스트림 별 오케스트레이션.
팬 아웃: 하나의 이벤트 → 사기 방지, CRM, 분석, 알림.
재료 화보기: 리더 보드, 밸런스, 한계-스트림에서 업데이트되는 테이블 형태.
재 처리: 골재/복고풍 분석의 재 계산을위한 국소 재생산.
예 (개념)
ksqlDB: 토너먼트 리더 (슬라이딩 창)
sql
CREATE STREAM bets_src (
bet_id VARCHAR KEY,
player_id VARCHAR,
amount DOUBLE,
ts BIGINT
) WITH (KAFKA_TOPIC='bets. placed. v1', VALUE_FORMAT='AVRO', TIMESTAMP='ts');
CREATE TABLE leaderboard AS
SELECT player_id,
SUM(amount) AS total_stake,
WINDOWSTART AS win_start,
WINDOWEND AS win_end
FROM bets_src
WINDOW HOPPING (SIZE 10 MINUTES, ADVANCE BY 1 MINUTE)
GROUP BY player_id
EMIT CHANGES;Flink (의사 코드): 늦은 사건으로 인한 사기 방지 점수
java stream
.assignTimestampsAndWatermarks(WatermarkStrategy. forBoundedOutOfOrderness(Duration. ofSeconds(10)))
.keyBy(e -> e. playerId)
.window(SlidingEventTimeWindows. of(Time. minutes(5), Time. minutes(1)))
.aggregate(scoreFunction, processWindow)
.sideOutputLateData(lateTag)
.addSink(riskTopic);스레드 품질 테스트
체계 및 진화의 계약 테스트 (Schema Registry).
로딩: 대상 TPS, p99, 싱크 저하 동작.
실패/혼돈: 중개인/노드 감소, 네트워크 지연, 분할 뇌.
결정 론적 재생-주제를 다시 실행합니다 → 동일한 결과.
카나리아 스트림: 지연 및 무결성 확인을위한 루프.
구현 체크리스트
1. SLO 정의 (p99 E2E
2. 표준화 체계 및 키 (플레이어 _ id/bet _ id).
3. 선택 아키텍처 (중요 루프의 경우 카파).
4. Outbox + CDC를 설정하고 PII를 분리하십시오.
5. 창, 워터 마크, 늦은 정책 및 DLQ/측 출력을 설정하십시오.
6. 화폐 경로에서 EOS/idempotency 사용하기
7. 지연, 워터 마크, DLQ에 대한 모니터링 및 경고를 소개합니다.
8. HA/DR 및 재 처리 절차를 제공하십시오.
9. Feature Store를 배포하고 온라인/오프라인으로 동기화하
10. 게임 데이를 보내십시오: 실패와 회복을 해결하십시오.
반 패턴
의식적인 정책없이 이벤트 시간과 처리 시간을 혼합합니다.
스키마 거버넌스 부족 → "파괴" 릴리스.
늦은 데이터와 핫 키를 무시합니다.
재생 전략 부족 및 주제의 다양성.
dempotency 및 EOS가없는 요금/지불.
요약
실시간 스트리밍은 "다른 전송" 이 아니라 도메인 이벤트, 명확한 SLO, 데이터 계약, 창 및 상태, 보안 및 관찰 가능성과 같은 사고 방식입니다. iGaming의 경우 지속 가능한 세트는 Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store입니다. 부하가 증가함에 따라 밀리 초 반응, 온라인/오프라인 분석 일관성 및 제어 된 복잡성을 제공합니다.