Шардинг жана репликациялоо

(Бөлүк: Технология жана инфраструктура)

Кыскача резюме

iGaming платформалары үчүн трафиктин өсүшү (коюмдар, депозиттер, PSP веб-хаки, оюн окуялары) жана жеткиликтүүлүк талаптары (≈ 99. 9–99. 99%) тез эле бир DD чегине жетет. Репликация горизонталдык окуу масштабын жана бузулууга туруктуулугун берет; шардинг - жазууларды жана маалыматтарды горизонталдуу масштабдоо. Ачкыч - PACELCтин аң-сезимдүү компромисстери (баш тарткандан кийин: CA/P, антпесе: Latency vs Consistency), так SLO жана схемалардын/ачкычтардын тартиби.

Терминдер жана моделдер

Репликация - түйүндөрдүн ортосундагы маалыматтарды көчүрүп алуу.

Leader-Follower (Primary-Replica): бир жазуу → көп окуу.
Multi-Leader (Active-Active): бир нече аймактарда жазуулар, чыр-чатактар/мердж.
Consensus-replication (Raft/Paxos, NewSQL): кворум жазуулары (Cassandra/Scylla - AP-кворумдар, CockroachDB/Yugabyte - CP-кворумдар).
Sync/Semi-sync/Async: RPO vs кечигүү балансы.
Шардинг - таблицаларды/ачкычтарды шардалар боюнча горизонталдуу бөлүү.

Hash-шардинг (бирдей, татаал диапазондору).
Range-шардинг (ачкыч диапазондору, тобокелдик "ысык" учтары).
Consistent hashing (жумшак кошуу/кыскартуу узел).
Гео-шардинг (аймак/юрисдикция боюнча).
Функционалдык шардинг (домендер боюнча: төлөмдөр/коюмдар/CRM).

Качан жана эмне тандоо iGaming

Бир гана репликация (шардингсиз) - негизги маселе окуганда: окуялардын ленталары, отчеттор, коомдук каталогдор. Жазуулар бир лидерге жайгаштырылат, окуулар - репликалар менен.
Шардинг - жазуу/сактоо жагы тар болгондо: коюмдардын агымы, баланстык транзакциялар, триггер окуялар.

Multi-region:

Players/PSP → Replica менен жергиликтүү окуу үчүн жашыруун.
Жөнгө салуучу (маалыматтарды локалдаштыруу) → гео-шардинг.
Аймак аралык DR → асинхрондук реплика + которуу планы.

PACELC жана кепилдик касиеттери

CAP: split тармагы менен C (консистенттүүлүк) же A (жеткиликтүүлүк) тандоо.
PACELC: мүчүлүштүктөр жок болсо, биз Latency (L) жана Consistency (C) ортосунда тандоо.
Акча жолдору (баланс, эсептен чыгаруу): адатта C-багытталган (CP/strict serializable же Serializable + бизнес-идемотенттүүлүк).
Азыраак критикалык подсистемалар (чыкылдатуу журналы, каталогдор): L-багытталган (AP/EC, eventual).

Репликация: практикалар

Leader–Follower

Records → лидер, окуулар → репликалар (read scaling).
Read-after-write: колдонуучу иштери үчүн лидер менен окуңуз же лагды күтүңүз (текшерүү 'last _ committed _ lsn '/' wait _ for _ replay _ lag').
сындуу жолдор боюнча Semi-sync (жашыруун баа RPO азайтуу).
Failover: автоматтык (patroni/raft-координатору) + fencing (эки лидер жок).

Multi-Leader

Бөлүнгөн домендер жана төмөн чыр-чатактар үчүн ылайыктуу (мисалы, мазмун/орнотуулар), бирок атайын чаралар жок бир оюнчу эсеби үчүн эмес.
Мердж саясаты: last-write-wins, CRDT, домендик консолидация эрежелери.

Consensus/Кворум БД

Кворум менен жазуу (мисалы, 'WRITE QUORUM'), кворум менен окуу ('READ QUORUM') → күчтүү/ылайыкташтырылган консистенттүүлүк.
АЗ/региондор ортосундагы латенттүүлүктү жана кворумдун баасын эске алыңыз.

Sharding: стратегиялар жана ачкычты тандоо

Ачкычты кантип тандоо керек

Туруктуу бөлүштүрүү player_id/ account_id/ bet_id.
range-шардингде монотондук ачкычтарды (auto-increment) болтурбоо - "ысык" куйрук.
Төлөмдөр үчүн - көбүнчө 'player _ id' же 'account _ id'; логдор үчүн - 'event _ time' + bucketing; мазмун үчүн - 'tenant _ id'.

Стратегиялар

player_id боюнча хэш-шардинг: чендердин/баланстардын агымындагы баланс.
Аналитика/архивдер үчүн убакыт боюнча Range-шардинг.
Гео-шардинг: EU-оюнчулар → EU-шард (жергиликтүү мыйзамдарга ылайык).
Гибрид: аймактын ичинде hash + юрисдикция боюнча гео.

"Ысык" ачкычтар менен күрөшүү

Key-salting (ачкычка туз/bucket кошуу).
Write-throttling маңызы боюнча, кезек командалар (сериялык executor).
"Агрегаттарды" (балансты) кезектүүлүк менен өзүнчө лагарда материалдаштыруу.

Кросс-шард операциялары

Акча которуу/компенсация: ысык жолдордо 2PC качуу.
Сага-үлгү: жергиликтүү бүтүмдөр + ордун толтуруу иш-аракеттери, катуу боштук жана outbox.
2RS/коммит протоколдору: чекиттик (бэк-кеңсе батч) жол берилет, бирок жашыруун жана бузулууга туруктуулугу боюнча кымбат.
Проекциялар: агымдан жаңыланган домен аралык экрандар үчүн окурмандардын көрүнүшү (read models).

Схемалар, индекстер жана эволюция

Схеманын версиясы: back-compat менен көчүрүү, коддогу feature-flags.
Шардалоонун ачкычтары жана тез-тез суроо-талаптар боюнча индекстер; cross-shard join болтурбоо (pre-join/denormalization).
JSON/док-сактоо үчүн - схемаларды (JSON-схема/Protobuf) жана "ызы-чуу" чогултуу үчүн TTL тастыктоо.

Онлайн масштабдоо жана resharding

пландаштыруу N ≫ учурдагы саны Virtual Shards (slots) → ийкемдүү ребаланс.
Consistent hashing же "Virtual Nodes" жумшак түйүндөрдү кошуу үчүн.

Online-resharding:

кош жазуу (эски + жаңы шард), ырааттуулук validation;
чанктардын арткы көчүрмөлөрү (logical dump/table move/streaming clone);
"маркер" + байкоо терезени которуу, андан кийин кош жазууну алып салуу.
Лидерди токтоп калбастан жылдыруу: ролдорду алмаштыруу, коннекшендерди дренаждоо.

SLO, байкоо жана алертинг

SLO жазуу/окуу: p99 ≤ X ms ысык таблицаларда, уруксат берилген lag реплика ≤ Y секунд, жеткиликтүүлүк ≥ Z.
Метриктер: TPS, p95/p99, replication lag, чыр-чатак (multi-лидер), retry rate, deadlocks, lock wait, cache hit ratio, IOPS/латенси диск.
Trace: DD суроо-жылы 'trace _ id', брокер/шина окуялар менен байланышкан.
Канар суроо-талаптар жана synthetic transactions эрте бузулуу аныктоо үчүн.

Коопсуздук жана талаптарга жооп

Тынч жана транзиттик шифрлөө (TLS), ачкычтарды айлантуу.
RBAC/ACL, домендер/тенанттар боюнча сегменттөө, төлөмдөр/CUS үчүн өзүнчө кластерлер.
Маалыматтарды локалдаштыруу (EU/TR/LATAM) - гео-шардинг менен ретенция политкаларын айкалыштыруу.
Аудит: ким жана эмне окудум/эрежелер; PII жашыруу; аудит экспорттоо.

Backup, PITR, DR

Толук + инкременталдык backaps, оффсайт сактоо.
PITR (point-in-time recovery) үчүн лидер кластерлер.

RPO/RTO:

Критикалык домендер (баланс/төлөм) - RPO ≈ 0-30с (жарым-sync же тез-тез WAL-shipping), RTO автоматтык failover менен ≤ мүнөт.
Азыраак критикалык - RPO мүнөт/саат.
DR-машыгуу (оюн күнү) жана документтештирилген runbook которуу.

Аткаруу жана тюнинг (кыскача)

Эс/кэш: Bufers жогорулатуу (shared buffers/innodb buffer pool), cache-хит ≥ 95%.
Журнал/кыймылдаткыч: тез NVMe, WAL/REDO үчүн өзүнчө том.
Байланыш бассейни (PgBouncer/Hikari).
Планировщик/Статистика: autovanaliza/autovacuum (Postgres), compaction/тюнинг GC (LSM-кыймылдаткычтар).
Кворумдар/реплика-фактор: p99 жана бузулууга туруктуулук ортосундагы баланс.

iGaming үчүн типтүү топологиялар

1) Баланстар жана төлөмдөр (CP-контур)

оюнчу аймакта лидер-Follower, жакын реплика үчүн жарым-sync.
Hash-шардинг 'account _ id'.
"Жазуудан кийин" окуу - лидерден; API-latency үчүн Redis проекциялары.
Outbox → эсептөөлөр/аналитика үчүн шина окуялар.

2) Коюмдардын тарыхы/оюн окуялары (AP-багытталган лог)

Range-шардинг убакыт же hash 'player _ id' колонка/LSM сактоо.
Отчет/OLAP үчүн асинхрондук репликалар.
Eventual consistency алгылыктуу, маанилүү өткөрүү жөндөмдүүлүгү.

3) Profiles/CRM (Multi-аймак окуу, локалдаштыруу)

Юрисдикция боюнча гео-шардинг, окуу үчүн жергиликтүү репликалар.
жакынкы лидер аркылуу жазуу; кросс-аймак - асинхрондук + чыр-чатактарды чечүү үчүн гана критикалык эмес талаалар.

Мисалдар (концептуалдык)

Postgres: 'player _ id' боюнча декларативдик шардинг

sql
CREATE TABLE player_wallet (
player_id BIGINT NOT NULL,
balance_cents BIGINT NOT NULL,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (player_id)
) PARTITION BY HASH (player_id);

CREATE TABLE player_wallet_p0 PARTITION OF player_wallet FOR VALUES WITH (MODULUS 32, REMAINDER 0);
--... p1..p31

-- Репликация: публикация WAL на реплики, синхронность для «горячего» региона.
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (replica_eu1, replica_eu2)';

Кворум жазуу (псевдо)


WRITE CL=QUORUM  -- запись подтверждена большинством реплик
READ CL=LOCAL_QUORUM -- локальный кворум для низкой задержки

Сага ордуна 2PC (жөнөкөйлөштүрүлгөн)

1. Shard-A (idempotent) депозиттик эсептен чыгаруу.
2. Иш-чараны жөнөтүү "алынып салынды" → төлөм кызматы (шард-B).
3. Эгерде 2-кадам ийгиликсиз болсо - 1-кадамды "кайтаруу" окуясы менен компенсациялоо.

Киргизүүнүн чек-тизмеси

1. Маалымат домендерин жана SLO (p99, RPO/RTO, лаг репликасы) аныктаңыз.
2. Репликация моделин (leader/follower, quorum) жана шардинг стратегиясын тандаңыз.
3. Charding ачкычтарын жана схемасын бекитүү (өзгөрүлбөгөн!).
4. read-after-write саясатын жана окуу багытын киргизүү.
5. онлайн resharding долбоорлоо (виртуалдык шарлар, кош жазуу).
6. Иш-чаралар/командалар үчүн жол-жоболоштуруу жана outbox кепилдик.
7. Backup, PITR, DR жана үзгүлтүксүз машыгууларды орнотуу.
8. Байкоо киргизиңиз: лаг, кворумдар, ысык ачкычтар, чыр-чатактар.
9. Runbook документтештирүү: failover, split-brain, деградация.
10. Беттеш чокуларынын астында жүктөө/башаламандык тесттерин өткөрүңүз.

Антипаттерндер

Бир алп шард "баарына" жана "андан кийин кесип".
Cross-shard join's ысык сурам жолунда.
read-after-write саясатынын жоктугу (сүзүүчү каталар).
көчүрүү схемалар "сындыруучу" ачкычтар шардинг.
Multi-лидер катуу чыр-чатактар жок акча эсептери үчүн.
Жок PITR/DR - логикалык катадан кийин калыбына келтирүү мүмкүн эмес.

Жыйынтыктар

Репликация окууга жана иштен чыгууга туруктуулукту чечет, шардинг - жазуулар жана көлөм. iGaming ийгиликтүү архитектура - бул так SLO жана PACELC-компромисстер, туруктуу ачкычтар, минималдуу кросс-шард координациясы (2PC ордуна сага), дисциплина read-after-write, жөндөлгөн онлайн-ресхардинг жана үзгүлтүксүз DR-машыгуулар. Бул ыкма турнирлердин туу чокусуна чейин масштабдалып, маалыматтарды локалдаштыруу боюнча жөнгө салуучу чектөөлөргө туруштук берет жана эксплуатацияда алдын ала айтууга болот.