شاردینگ و تکثیر پایگاه داده

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

برای سیستم عامل iGaming, رشد ترافیک (شرط, سپرده, PSP webhooks, رویدادهای بازی) و در دسترس بودن مورد نیاز (≈99. 9–99. 99٪) به سرعت به حد یک DB رسید. تکرار مقیاس خواندن افقی و تحمل خطا را فراهم می کند. شاردینگ - مقیاس افقی رکورد و داده ها. کلید سازش آگاهانه PACELC (پس از شکست: CA/P، در غیر این صورت: تاخیر در مقابل سازگاری)، SLOs روشن و نظم و انضباط طرح/کلید است.

شرایط و مدل ها

Replication: داده ها را بین سایت ها کپی می کند.

Leader-Follower (Primary-Replica): یک ورودی → بسیاری از خواندن.
چند رهبر (فعال): ورودی در مناطق مختلف، درگیری/ادغام.
اجماع تکرار (Raft/Paxos، NewSQL): رکوردهای حد نصاب (Cassandra/Scylla - AP quorums، CockroachDB/Yugabyte - CP quorums).
همگام سازی/نیمه همگام/Async: تعادل تاخیر در مقابل RPO.
Sharding - تقسیم افقی جداول/کلید توسط قطعات.

هش کردن مداوم

هش شاردینگ (یکنواختی، محدوده سخت تر).
محدوده شاردینگ (محدوده های کلیدی، خطر پایان گرم).
Geo-sharding (بر اساس منطقه/حوزه قضایی).
اشتراک گذاری عملکردی (بر اساس دامنه: پرداخت/نرخ/CRM).

چه زمانی و چه چیزی را در iGaming انتخاب کنید

فقط تکرار (بدون sharding) - زمانی که مشکل اصلی خواندن است: خوراک رویداد، گزارش ها، دایرکتوری های عمومی. سوابق در یک رهبر قرار می گیرند، از کپی ها خوانده می شوند.
Sharding - هنگامی که تنگنای نوشتن/نگهداری: جریان نرخ، معاملات ترازنامه، رویدادهای ماشه.

چند منطقه:

تاخیر پخش/PSP → خواندن محلی از کپی.
مقررات (محلی سازی داده ها) → geo-sharding.
DR بین منطقه ای → ماکت ناهمزمان + برنامه تعویض.

PACELC و خواص گارانتی

CAP: با یک شبکه تقسیم، C (سازگاری) یا A (در دسترس بودن) را انتخاب کنید.
PACELC: اگر هیچ خرابی وجود نداشته باشد، بین Latency (L) و Consistency (C) انتخاب کنید.
روش های نقدی: معمولا C گرا (CP/strict serializable یا Serializable + idempotency کسب و کار).
زیرسیستم های کمتر بحرانی (log clicks, directories): L-oriented (AP/EC, finally).

شیوه های تکرار

رهبر پیرو

Writes → leader, reads, خواندن scaling.
خواندن پس از نوشتن: برای عملیات کاربر، از رهبر بخوانید یا منتظر تاخیر باشید (چک کنید 'last _ committed _ lsn '/' wait _ for _ replay _ lag').
نیمه همگام سازی در مسیرهای بحرانی (کاهش RPO در هزینه تاخیر).
Failover: خودکار (هماهنگ کننده patroni/قایق) + شمشیربازی (به طوری که هیچ رهبر دوگانه وجود ندارد).

چند رهبر

مناسب برای تقسیم دامنه و درگیری کم (به عنوان مثال،. محتوا/تنظیمات)، اما نه برای یک بازیکن حساب بدون اقدامات خاص.
سیاست های ادغام: آخرین نوشتن برنده، CRDT، قوانین تثبیت دامنه.

اجماع/پایگاه داده حد نصاب

حد نصاب نوشتن (به عنوان مثال 'WRITE QUORUM')، quorum خوانده شده ('READ QUORUM') → سازگاری قوی/قابل تنظیم.
تأخیر بین AZ/منطقه و هزینه حد نصاب را در نظر بگیرید.

Sharding: استراتژی ها و انتخاب های کلیدی

چگونه یک کلید را انتخاب کنید

توزیع پایدار توسط player_id/ account_id/ bet_id.
اجتناب از کلیدهای یکنواخت (افزایش خودکار) در دامنه sharding - دم «داغ».
برای پرداخت - اغلب «بازیکن _ id» یا «حساب _ id» ؛ برای سیاهههای مربوط - 'event _ time' + bucketing ؛ برای محتوا - 'tenant _ id'.

استراتژی ها

هش شاردینگ توسط player_id: تعادل در جریان نرخ/تعادل.
sharding مبتنی بر زمان برای تجزیه و تحلیل/آرشیو.
Geo-sharding: بازیکنان اتحادیه اروپا → EU-shard (مطابق با قوانین محلی).
ترکیبی: هش در منطقه + جغرافیایی توسط صلاحیت.

مبارزه با کلید های داغ

نمک زدن کلید (نمک/سطل را به کلید اضافه کنید).
Write-throttling اساسا یک صف فرمان (مجری سریال) است.
«aggregates» (تعادل) را در یک ردیف جداگانه با یک صف دنباله ای تحقق بخشید.

عملیات کراس شارد

انتقال پول/جبران خسارت: اجتناب از 2PC در مسیرهای داغ.
الگوی حماسه: تقسیم به معاملات محلی + اقدامات جبرانی، idempotence سخت و صندوق خروجی.
پروتکل های 2PC/commit: نقطه مجاز (دسته های پشتی)، اما گران در تاخیر و تحمل خطا.
پیش بینی ها: مدل های خواندن برای صفحه نمایش های متقابل دامنه، به روز شده از جریان.

طرح ها، شاخص ها و تکامل

نسخه بندی طرح: مهاجرت از back-compat، پرچم های ویژگی در کد.
شاخص در کلید های sharding و نمایش داده شد مکرر ؛ اجتناب از پیوستن متقابل شارد (انجام قبل از پیوستن/denormalization).
برای JSON/docking storages - طرح های معتبر (JSON-Schema/Protobuf) و TTL برای مجموعه های پر سر و صدا.

مقیاس بندی آنلاین و دوباره سخت شدن

برنامه ریزی برای N≫tekushcheye تعداد قطعات مجازی (اسلات) → تعادل انعطاف پذیر.
هش کردن مداوم یا «گره های مجازی» برای اضافه کردن گره نرم.

مجدد آنلاین:

دو ورودی (قدیمی + shard جدید)، اعتبار سازگاری ؛
نسخه های پس زمینه از تکه های (منطقی تخلیه/حرکت جدول/کلون جریان) ؛
سوئیچ با «نشانگر» + پنجره مشاهده، سپس دو رکورد.
حرکت رهبر بدون خرابی: تغییر نقش ها، تخلیه اتصالات

SLO، قابلیت مشاهده و هشدار

SLO نوشتن/خواندن: p99 ≤ X ms در جداول داغ، کپی تاخیر معتبر ≤ Y ثانیه، در دسترس بودن ≥ Z.
معیارهای: TPS, P95/P99, تاخیر تکرار, چند رهبر, نرخ تلاش مجدد, بن بست, انتظار قفل, کش نسبت ضربه, IOPS/تاخیر دیسک.
ردیابی: 'trace _ id' در درخواست های پایگاه داده، با اتوبوس کارگزار/رویداد مرتبط است.
پرس و جو قناری و معاملات مصنوعی برای تشخیص زود هنگام تخریب.

امنیت و انطباق

رمزگذاری در حالت استراحت و حمل و نقل (TLS)، چرخش کلید.
RBAC/ACL، تقسیم بندی توسط دامنه/مستاجر، خوشه های جداگانه برای پرداخت/LCC.
محلی سازی داده ها (EU/TR/LATAM) - سیاست های جغرافیایی و نگهداری را ترکیب کنید.

حسابرسی: چه کسی و چه چیزی خواندن/قوانین ؛ ماسک PII ؛ حسابرسی صادرات

پشتیبان گیری، PITR، DR

پشتیبان گیری کامل + افزایشی، ذخیره سازی خارج از سایت.
PITR (بازیابی نقطه در زمان) برای خوشه های رهبر.

RPO/RTO:

دامنه های بحرانی (تعادل/پرداخت) - RPO≈0 -30s (نیمه همگام یا مکرر WAL حمل و نقل)، RTO ≤ دقیقه با شکست اتوماتیک.
کمتر بحرانی - RPO تا دقیقه/ساعت.
تمرینات DR (روز بازی) و یک دفترچه سوئیچ مستند.

عملکرد و تنظیم (کوتاه)

حافظه/کش: افزایش بافر (بافر مشترک/innodb استخر بافر)، مانیتور کش ضربه ≥ 95٪.
مجله/موتور: NVMe سریع، حجم جداگانه تحت WAL/redo.
استخر اتصال (PgBouncer/Hikari).
برنامه ریز/آمار: خودکار تجزیه و تحلیل/خودکار خلاء (Postgres)، فشرده سازی/تنظیم GC (موتورهای LSM).
حد نصاب/ماکت عامل: تعادل بین P99 و تحمل خطا.

توپولوژی های معمول برای iGaming

1) تعادل و پرداخت (CP-حلقه)

رهبر پیرو در منطقه بازیکن، نیمه همگام به یک ماکت نزدیک است.
هش شاردینگ با 'account _ id'.
خواندن «پس از نوشتن» - از رهبر ؛ پیش بینی ها به Redis برای API-latency.
Outbox → اتوبوس رویداد برای محاسبات/تجزیه و تحلیل.

2) تاریخ شرط بندی/رویدادهای بازی (ورود به سیستم AP گرا)

تقسیم محدوده توسط زمان یا هش توسط 'player _ id' در ذخیره سازی ستون/LSM.
کپی ناهمزمان برای گزارش/OLAP.
سازگاری احتمالی قابل قبول است، پهنای باند مهم تر است.

3) پروفایل/CRM (خواندن چند منطقه، محلی سازی)

Geo-sharding توسط حوزه قضایی، کپی های محلی برای خواندن.
ورود از طریق نزدیکترین رهبر ؛ cross-region - به صورت ناهمگام + حل تعارض فقط برای زمینه های غیر بحرانی.

مثال ها (مفهومی)

Postgres: اعلانی sharding توسط '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. ارسال رویداد «حذف» → سرویس پرداخت (shard-B).
3. اگر مرحله 2 با شکست مواجه شود، مرحله 1 را با یک رویداد «بازگشت» جبران کنید.

چک لیست پیاده سازی

1. دامنه داده ها و SLO ها را تعریف کنید (p99، RPO/RTO، replica log).
2. مدل تکرار (رهبر/پیرو، حد نصاب) و استراتژی sharding را انتخاب کنید.
3. تعمیر کلید sharding و طرح (تغییر ناپذیر!).
4. خط مشی خواندن پس از نوشتن و مسیریابی خواندن را تایپ کنید.
5. طراحی مجدد آنلاین (قطعات مجازی، دو ورودی).
6. اطمینان از idempotency و outbox برای رویدادها/دستورات.
7. پشتیبان گیری، PITR، DR و تمرینات منظم را تنظیم کنید.
8. شامل قابلیت مشاهده: تاخیر، quorums، کلید های داغ، درگیری.
9. سند اجرا: شکست، تقسیم مغز، تخریب.
10. انجام تست بار/هرج و مرج در زیر قله بازی.

ضد الگوهای

یک تکه بزرگ «برای همه چیز» و «سپس برش».
پیوستن به کراس شارد در راه داغ درخواست است.
بدون سیاست خواندن پس از نوشتن (اشکالات شناور).
مهاجرت طرح ها «شکستن» کلید های sharding.
چند رهبر برای حساب های نقدی بدون حل اختلاف شدید.
بدون PITR/DR - قادر به بازیابی از خطای منطقی نیست.

نتایج به دست آمده

تکرار خواندن و انعطاف پذیری را حل می کند، sharding نوشتن و حجم را حل می کند. معماری موفق در iGaming روشن است SLO و PACELC سازش، کلید sharding پایدار، حداقل هماهنگی متقابل shard (حماسه به جای 2PC)، خواندن پس از نوشتن نظم و انضباط، به خوبی عملکرد مجدد آنلاین و تمرینات DR به طور منظم. این رویکرد به قله مسابقات می رسد، در برابر محدودیت های قانونی در مورد محلی سازی داده ها مقاومت می کند و در عملیات قابل پیش بینی است.