Torrent Gear

Failover, replicarea și planurile DR pentru cazinouri

1) Obiective de afaceri: RTO/RPO și fluxul critic

RTO (cât timp serviciul poate fi indisponibil): autentificare/rată/depozit - secunde/minute; rapoarte - ore.

RPO (cât de multe date pot fi pierdute): portofel/tranzacții - ~ 0-30 secunde; telemetrie - minute.

Flux critic: autentificare, depunere/retragere, pariu/decontare, KYC/AML-gulere, PSP/carti web furnizor de jocuri.

2) Modele de toleranță la defecțiuni arhitecturale

Active-Active (multi-regiune): ambele regiuni se ocupă de trafic; RTO/RPO scăzut, consistență complexă.

Active-Standby: o regiune în funcțiune, a doua fierbinte; stare mai ușoară, minute RTO.

Pe bază de celule: izolarea prin „celule” (piață/marcă), incidentele locale nu reduc totul.

Plăcintă de margine: Anycast CDN/WAF → gateway-uri regionale → clustere de aplicații → DB/cache cu replicare.

3) Managementul traficului și rețeaua falsă

Anycast + CDN/WAF: absorbție L3/4/7, control de sănătate pentru origine.

DNS-feilover (TTL scăzut, multi-valoare), Trafic Manager/GSLB pe metrici de sănătate.

Anunțul BGP prin intermediul furnizorului anti-DDoS pentru schimbarea rapidă a căii.

Bilanțul de sănătate (exemplu de logică):


dacă p95_latency>threshold        5xx_rate>threshold        synthetic_login_fail:
scurgere (region_A); shift (trafic-> regiune _ B, rampă = 5min)

4) Date: portofel, comenzi, pariuri

Sursa adevărului este registrul: adăugați numai, idempotența prin "operation _ id'.

Reconciliere: locuri de muncă periodice de reconciliere între registru, PSP și furnizorii de jocuri.

Anti-dublu: chei de idempotenta pentru depozite/carnati/plati; deduplicarea outbox/inbox.

5) Replicarea bazei de date - opțiuni și tranzacții

Sincron fizic (semi-sincronizare): RPO minim, risc de întârzieri - se aplică pointwise (portofel).

Asincron: performanță/simplitate mai mare, secunde-minute RPO - pentru metadate de joc, cărți de referință.

Logic (flux de → CDC într-o altă regiune): selectivitate flexibilă, convenabilă pentru motoare încrucișate și analiză.

Cache (Redis/Memcached): nu ca sursă de adevăr; replica/instantanee, porniri calde.

PITR: jurnale continue (WAL/redo) pentru stocare offsite, fereastră de recuperare ≥ 7-30 zile.

6) Modele de coerență și reconciliere

Saga + Outbox: tranzacții de afaceri ca un lanț de pași, publicarea evenimentelor atomic cu scrierea la baza de date.

Exact o dată „în sensul”: idempotența operațiunilor, controlul versiunilor de echilibru (blocare optimistă).

Eventuala consecventa in fluxul non-cheie (leader board, analytics); puternic pentru bani.

7) Componente și feilover lor

API/backend

Containere Statles, autoscale, albastru-verde/canar; configs prin stocare (cu versioning).

Cozi/Fluxuri

Clustere de cvorum (N = 3/5), replică cross-AZ; reface politicile și dlt cozi.

Portofel DB

Primari în Regiunea A, sincronizare replica în A (alte AZ), asincron în Regiunea B; promovarea automată cu split-creier este interzisă - numai manual/scripted cu o listă de verificare.

Fișiere/Artefacte CUS

Stocare obiect cu versioning, cross-regional replica/CRR, chei în KMS.

WebSocket/Timp real

Sharding după taste (tabel/joc/piață), lipicios-rutare; cu un feiler - resubscribe cu un token rejoin.

8) Plăți și furnizori de jocuri: Multe surse de adevăr

Feilover PSP: cel puțin 2 furnizori pentru fiecare metodă (card, portofele, cripto).

Procent de rutare prin SLA/valoare/banlists BIN; dezactivarea PSP degradat de către întrerupătorul automat.

Furnizori de jocuri: canale de rezervă/lista permisă ASN, chei individuale pentru regiuni, izolarea temporizărilor.

9) Cârlige și cârnați: recepție și reproducere durabilă

Inbox-pattern: acceptăm webhook-ul → verificăm semnătura/NMAS → scriem în imuable-inbox → procesăm lucrătorul în mod idempotent.

Retroadele furnizorilor: backoff + dedup prin 'event _ id'/' semnătură'.

În DR: reluare din inbox cu comanda de control (txn → decontare).

10) Backup-uri: 3-2-1 strategie și cecuri de recuperare

3 copii/2 medii/1 offsite (și 1 offline/WORM pentru reviste critice).

Orare: instantanee zilnice + reviste permanente; testul săptămânal-restaurare la standul „întunecat”.

Directoare de recuperare: „cum să ridicați portofelul în momentul t- Δ”.

11) Planul DR: roluri, scenarii, comunicări

Роли: Comandantul incidentului, Comms, DB Lead, App Lead, Plăți/Joc PM, SRE Oncall.

Canale: war-room, status page, message templates for support/partners/afiliates.

Scenarii (minim):

Pierderea AZ, pierderea regiunii, indisponibilitatea PSP, căderea clusterului de baze de date, degradarea furnizorului de jocuri, scurgeri de chei, 5xx masiv.

12) Exemplu de matrice de scenariu DR

Scenariu	Detectează	Acțiuni	RTO	RPO	Criteriul randamentului
Regiunea A nu este disponibilă	Sintetice + GSLB	Schimbați traficul în B, promovați baza de date, dezactivați caracteristicile grele	10-20 min	≤30 sec	p95 OK, 5xx <0. 5%
degradarea PSP-1	Erori 3DS/timeout	Comutarea rutării la PSP-2, activarea limitelor	2-5 min	0	Rata de succes> 99%
Eșecul bazei de date portofel	Bătăi ale inimii/decalaj de replicare	Promovarea standby, verificarea registru, activați țineți pe ace	5-10 min	≤5 sec	Registru = OK
Lag furnizor de jocuri	RTT/ora de pornire	Comutarea traficului la birouri alternative/furnizor	1-3 min	0	TTFS <800 ms

13) Runbook și automatizare

Butonul „DR-cutover”: secvență de pași cu validare (freeze scrie → promova → cache-uri calde → traficul de rampe).

Scripturi de verificare a integrității: reconcilierea sumelor din registru/portofel, consistența echilibrului.

Feature-flags: dezactivați rapid rapoartele/exporturile/tablourile de bord grele în timpul unui accident.

14) Observabilitate pentru un feilover

Măsurători SLO ca declanșatoare: autentificare, depunere, pariu, lansare joc.

Технические: replicare-lag, WAL-transport, coadă-lag, 5xx, p95, SYN restanțe, WebSocket deconectează.

Scenarii sintetice din alte regiuni: autentificare/depunere/pariere în fiecare minut.

Urme end-to-end, etichete 'region', 'psp', 'game _ provider'.

15) Exerciții de haos/DR

GameDay trimestrial: deconectarea AZ, degradarea PSP, „pierderea” nodului de baze de date, oprirea cozii.

Retrospectivă: timp de decizie, alerte lipsă, zgomot, blocaje.

Ajustarea RTO/RPO și automatizarea pe baza faptelor, nu a „senzațiilor”.

16) Siguranță și conformitate

Chei/secrete în KMS/HSM (cross-regional), rotație și dual-control.

WORM/imunitate pentru jurnalele de audit și tranzacții.

DPA/PSP/furnizor de contracte pentru angajamentele SLA/DR și 24 × 7 puncte de contact.

17) Exemplu de politică minimă Feilover (Pseudocode)


pe Incident (tip = „REGIUNE _ JOS”):
freeze_non_critical_writes ()
promote_db (regiune = B)
verify_ledger_consistency ()
warm_caches (regiune = B)
route_traffic (regiune = B, rampă = 10%)
pentru etapa în [25%, 50%, 100%]:
dacă SLO_green (): rampă (pas) altfel rollback ()
announce_statuspage ()

18) Lista de verificare pregătită pentru prod

Definit RTO/RPO per flux; acceptate de afaceri.
Multi-AZ minim; Multi-regiune pentru portofel, conectare și plăți.
Ledger + idempotency (chei) + outbox/inbox; reconciliere pe un program.
Replicarea bazei de date: sincronizare locală, async în DR; PITR activat, restaura verificat.
Două PSP-uri pe metodă, politica de rutare și tastele de testare; furnizorii de jocuri sunt alternative.
DNS/GSLB/Anycast, controale de sănătate și sintetice, TTL scăzut.
Runbook și butonul DR-cutover, feature-steaguri pentru degradare.
SLO/alerte/urmărire; Panoul de stare DR.
Exerciții DR trimestriale + retro; contacte actualizate 24 × 7.

Rezumat reluare

O platformă iGaming de încredere este construită în jurul unui circuit monetar: un jurnal de postări cu idempotență, un feiler previzibil, replicare verificabilă și exerciții DR regulate. Împărțiți sistemul în celule și regiuni, automatizați tăierea, păstrați două PSP-uri și furnizorii de jocuri de rezervă, monitorizați integritatea SLO și a registrului - și chiar și un accident major va deveni un eveniment ușor de gestionat fără a pierde încredere și bani.