집단 유동성
1) 왜 필요한가
새로운 클러스터의 즉각적인 유동성. 지역/틈새 시장에서 출시- 일반 수영장을 "혼합" 하십시오.
더 나은 일치와 가격. 심층 시장 → EPI 이상의 확산 감소 (유효 가격/선택 개선).
공급/수요 충격. 노드 사이의 오버플로드는 오류와 대기열을 줄입니다.
경제학. 적당한 비용 증가로 채우기 속도 이상 및 ARPU; 교차 판매 기능.
2) 집단 유동성 모델
3) 건축 구성 요소
주문/카탈로그: 응용 프로그램/제공 추상화, 상태 및 버전, SLA 및 호환성 속성.
SOR (Smart Order Routing): 가격/품질/관할권/대기 시간을 고려하여 풀/공급 업체를 선택하는 규칙.
일관성: CDC 및 이벤트 로그, 이벤트 _ id dedup, 트랜잭션 보상.
귀속 및 청구: 거래/커미션의 "소유자" 인 사람, 창을 청구하고 조정합니다.
품질과 명성: 파트너 등급/SLA, 페널티, 배지.
개인 정보 보호 및 현지화: PD 마스킹, 지오 피닝, 이벤트 내보내기 규칙.
mermaid flowchart LR
U [Demand] --> GW [Routing Gateway]
P1 [Pool A] --- GW
P2 [Pool B] --- GW
P3 [Partner C] --- GW
GW --> SB[Settlement/Billing]
GW --> OBS[Observability/SLO]
4) 데이터 계약 (최소 필드)
yaml offer. v1:
id: uuid kind: product slot capacity price: {amount: decimal, currency: ISO4217}
quality: {rating: 0..5, sla_ttm_ms: int}
geo: {region: "EU", city: "Tallinn"}
vendor: {id: "partner-123", tier: "gold"}
terms: {ttl_s: 60, cancellation: "window:15m"}
version: 7 request. v1:
id: uuid constraints: {geo, time, price_ceiling, compliance}
qos: {max_ttm_ms: 500, min_rating: 4. 0}
trace_id: uuid consent: {...}
5) SOR: 규칙 및 의사 코드
순위 기준:- 'score = w _ priceprice _ repression + w _ slattm _ slo + w _ qquelity + w _ geowarge _ pencement + w _ riskbander _ risk _ penalty'
python def route(request, pools):
candidates = []
for pool in pools:
if not compliant(request, pool):
continue quotes = pool. quote (request) # timebox, idempotent for q in quotes:
s = score(q, request)
candidates. append((s, pool, q))
ordered = sorted(candidates, key=lambda x: -x[0])
return best_feasible(ordered, fairness=request. fairness)
공정성: 공급 업체 교체, 매출 점유율 할당량, 평판 타이 브레이크 및 최근 상금.
6) 유동성 지표
충전 속도 = 닫힌 응용 프로그램/모든 응용 프로그램 (세그먼트/클러스터 별)
경기 시간 (p50/p95) -선택/실행 시간.
깊이-지정된 가격/품질 범위에서 사용 가능한 볼륨.
스프레드/EPI-유효 가격 대 벤치 마크 개선.
사용하기-문장을로드하십시오 (SLA 실패가없는 경우 유휴).
무결성-취소/폴드 변환 비율, 조정 불일치 (<λ).
공정성-품질이 동일한 공급 업체에 대한 판매 분배의 차이.
- (PHP 3 = 3.0.6, PHP 4)
- 피크 시간 동안 'p95 _ time _ to _ match
- (PHP 3 = 3.0.6, PHP 4) 벤더 SLA의 경우 '5%' '정시 98% 이상'.
7) 관찰 및 증거 기반
이벤트: '요청. ',' 인용문을 보냈습니다. ',' 를 받았습니다. ',' 결제 ',' 취소 ',' 환불 '을 만들었습니다.
추적: SOR → 풀 → 공급자를 통한 'trace _ id'.
감사: 웹 후크 서명, 주문 버전 로그, 따옴표의 "스크린 샷".
조정: 양자 보고서, dedup, 불일치 <λ는 폐쇄 SLA를 주장합니다.
8) 개인 정보 보호, 규정 준수, 주권
지리 피닝: 민감한 범주/PII는 허용 된 영역을 떠나지 않습니다.
의사 명칭: 파트너 간 교환의 경우 의사 식별자 만 있습니다.
코드로 유지: TTL 이벤트, 삭제 권한, 법적 보류.
DPA/웹 후크: 시그니처, 재생 방지, 스키마 제어.
9) 운영 모델 및 계산
역할: 시장 운영자 (귀하), 풀/파트너 (공급), 채널/쇼케이스 (수요).
상거래: RevShare/CPA/최소 보증; 라우팅/가격 개선을위한 "클립".
크레딧/처벌: SLA 중단, 허위 제안, 보고서 불일치.
정산: T + N 빈도, 보유, 청구, 보고.
yaml partner_id: "pool-A"
sla:
fill_rate: ">= 90%"
on_time: ">= 98%"
quote_ttl_s: 2 limits:
rps: 200 region: ["EU","TR"]
commercials:
model: "revshare: 20% of net"
security:
webhook_signature: "Ed25519"
10) 통합 패턴
타임 박스 (idempotency-key) 가있는 API를 인용하십시오.
'일치하는 웹 후크 서명. '/' 정착 '(지수가있는 retrai) 을 만들었습니다.
CDC 정렬 및 분석을위한 이벤트 버스 (이벤트 버전).
배치 레콘 (일일 STP/Blob + 체크섬).
양쪽에 전송/받은 편지함 + dedup.
스키마/SDK 버전화, 호환성 창.
11) 과부하 및 스윙 제어
울혈 방지: 리미터, 대기열, VIP/복잡한 케이스 우선 순위 지정, 서지 요인.
차익 거래 방지 (독성): "탁구" 요청을 모니터링하여 저렴한 가격/품질로 "자체 실행" 금지.
사기 방지: 장치/행동 서명, 허니 토큰, 지연된 자격 (쿨 오프).
명예에 따른 분해: 지역 수영장으로의 대체, 투명한 저하로 "최선의 노력".
12) 논리의 예 (스케치)
12. 1 법학 및 SLO 라우팅
python def compliant(req, pool):
return (req. constraints. geo in pool. regions and pool. sla. quote_ttl_s <= 2 and pool. vendor_tier in {"gold","silver"})
12. 2 정의 정책 (레고 아이디어)
rego package fairness deny["overexposed vendor"] {
usage. share[input. vendor] > 0. 45 input. vendor. tier == "silver"
}
12. 3 개의 주문 수렴 테스트
sql
SELECT offer_id, MAX(version)-MIN(version) AS drift
FROM orderbook_events
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING MAX(version)-MIN(version) > 1; -- fragmentation signal
13) 성숙도 지표
적용 범위: X 활성 오퍼가있는 세그먼트/영역의 공유.
탄성: 얼마나 빨리 요금을 채우는 지에 따라 + 자동 수요가 회복됩니다.
EPI/스프레드 개선: 집계 대 솔로 풀의 혜택.
공정 분포: 품질 측면에서 예상 점유율과의 편차.
정찰 건강: 불일치 폐쇄 빈도/타이밍.
개인 정보 보호 점수: 정책 경계를 넘어 PD 제거가없는 경로의 비율.
14) 반 패턴
SOR 및 품질 규칙이없는 벌거 벗은 연합 → 조각화, 취소.
"유리 시장": 사기와 가격 전쟁의 시작으로 모든 사람에게 모든 것을 엽니 다.
귀속 및 화해 → 영원한 분쟁과 동결 된 지불.
수영장 → 계단식 대기 시간/고장 사이의 하드 동기화.
다른 세그먼트에 대한 동일한 규칙 → 프리미엄/로컬 틈새에서의 경험 저하.
TTL을 무시하면 "썩은" 조건에서 → 거래가 제공됩니다.
전체 → 시장에 대한 단일 암호화 키는 지점별로 "지우기" 할 수 없습니다.
15) 건축가 점검표
1. 모델 (공유 풀/페더레이션/허브) 및 주권 제약이 정의 되었습니까?
2. 데이터 계약 (스키마, 버전, TTL, 서명) 과 호환성 창이 있습니까?
3. 공정성과 comps, 유동성 SLO 및 대시 보드로 SOR 구현?
4. 청구/귀속, 청구 창, 크레딧/벌금이 등록되어 있습니까?
5. 사기 방지/사기 방지/차익 거래 방지 및 분해 모드로 구축 되었습니까?
6. "거래의 증거" 의 화해와 인공물?
7. 개인 정보 보호: 가명, 지리 고정, 보존, 삭제 권한?
8. 드릴: 수요 스트레스 피크/풀 드롭/오더 북 오브 싱크?
9. FinOps: 출구 예산, 라우팅 비용, 목표 EPI?
10. 거버넌스: 임계 값 주식, 파트너 인증, 감사.
결론
집단 유동성은 "다른 파트너를 연결" 하는 것이 아니라 시장을 설계하는 것입니다: 균일 한 계약 및 이벤트, 투명한 라우팅 및 공정성 규칙, 강력한 관찰 및 계산, 개인 정보 보호 및 관할권 "코드. "따라서 이질적인 출처에서 사용자를위한 최고의 경험과 전체 생태계를위한 예측 가능한 경제를 갖춘 하나의 깊고 지속 가능한 공급 및 수요 풀이 탄생합니다.