چگونه API جکپات کار می کند

مقاله کامل

💡 18+. مواد مهندسی اعمال می شود، بدون تماس به بازی. شرایط: پلت فرم - PAM/کیف پول/میز نقدی/پاداش/RG ؛ RGS - Remote Game Server (هسته اصلی بازی های استودیویی) ؛ aggregator - لایه یکپارچه برای RGS چندگانه ؛ JP - خدمات برنده تمام پولها.

1) سیستم جکپات چیست و در کجای اکوسیستم قرار دارد

سیستم جکپات یک سرویس جداگانه (گاهی اوقات خوشه ای از خدمات) است که مشارکت ها را از شرط ها جمع آوری می کند، استخر ها را مدیریت می کند و برنده می شود، توزیع جوایز را محاسبه می کند و پرداخت ها را از طریق حلقه پرداخت اپراتور آغاز می کند. ادغام می شود:

با RGS (پیام های مربوط به نرخ/نتایج و مدارک)، با یک پلت فرم/کیف پول (نوشتن سهم و اعتبار برنده)، با یک جمع کننده (مسیریابی از بسیاری از استودیوها/مارک ها)، با BI/تنظیم کننده (تله متری و گزارش).

2) انواع جکپات (و چه تغییراتی در API)

1. ثابت - مقدار جایزه شناخته شده در پیشبرد. هیچ استخر در API وجود ندارد، فقط چک کردن شرایط و اعتبار.

2. مترقی: استخر از سهم شرط رشد می کند. ما به نقاط پایانی سهم و انتشار اندازه فعلی نیاز داریم.

3. چند لایه (چند لایه: مینی/عمده/بزرگ): چند استخر موازی با شانس و کلاه های مختلف.

4. شبکه محلی در مقابل: استخر محلی - یک اپراتور/نام تجاری ؛ شبکه - کل برای بسیاری از اپراتورها/مارک ها/مناطق (چند اجاره و تکرار حیاتی هستند).

5. زمان/رویداد: یک استخر با مهلت و یا در یک برنامه (تایمر و خودکار تساوی مورد نیاز است).

3) ناورداهای پولی

منبع حقیقت در تعادل کیف پول/دفتر کل پلت فرم است. JP فقط وضعیت استخرها و بدهی ها را ذخیره می کند.

تمام معاملات پول بی نظیر هستند (کلید «jp _ curb _ id»، «jp _ trigger _ id»، «jp _ payout _ id»).

پرداخت های از دست رفته/تکراری = 0. جبران خسارت - فقط توسط رویدادها (sagas)، نه ویرایش دستی پایگاه داده.

سهم جداگانه، ماشه و پرداخت به عنوان معاملات مستقل با تله متری خود را.

4) قراردادهای مرجع API

4. 1 RGS/→ جمع کننده JP (مشارکتها و محرکها)

'POST/v1/JP/مشارکت' - حسابداری برای سهم استخر

جی سون
{
« :» uuid-1 «،» : «brand-42»، « :» grand-eu-01 «،» : « »: «uuid-1»، «bet»: {«مقدار»: 2. 00, «ارز»: «EUR»} «, و»: {«مقدار»: 0. 02, "ارز": "EUR"} ", :"  "" : "
}

'POST/v1/jp/candidates' - درخواست برای مشارکت/تأیید شرایط (اختیاری)

پاسخ: «واجد شرایط: درست/غلط»، وزن یا شانس، قوانین.

'POST/v1/jp/triggers' - ضبط واقعیت عملیات

جی سون
{
« :» uuid-2 «،» : «grand-eu-01»، «دلیل»: « » «انتخاب»: {«player _ id»: « » « »
}

توجه: در برخی از مدل ها، ماشه توسط خود JP (رولت داخلی) آغاز می شود و RGS فقط دور را گزارش می دهد. سپس «triggers» نامیده می شود JP → platforma و RGS به این رویداد مشترک است.

4. 2 JP → پلت فرم (پرداخت/مقررات)

'POST/v1/wallet/reserve' - (اختیاری) ارائه برای پرداخت آینده

'POST/v1/کیف پول/اعتبار' - بازیکن برنده اعتبار

جی سون
{
" :" uuid-3 "،" : "نام تجاری 42"، " :"  ":" grand-eu-01 "،" مقدار ": {" مقدار ": 500000. 00, "ارز": "EUR"} ", متا": {"مالیات": "محفوظ = نادرست", "ردیف": "بزرگ"} ", idempotency_key": "jp_p_grand_r_123"
}

پاسخ های پلت فرم: "اعتبار. بسیار خوب	با کدهای منطقی (RG/AML، محدودیت های خروج، تحریم ها، جغرافیایی بلوک) شکست خورده است.

4. 3 انتشار وضعیت استخر (برای جبهه/ویدجت)

GET/v1/jp/pools/{ pool _ id} → اندازه فعلی، دانه، کلاه، تعداد شرکت کنندگان، ETA و غیره

'GET/v1/jp/pools' → فهرست استخرها بر اساس نام تجاری/منطقه با فیلتر.

5) مدل رویداد (کافکا/پولسار) و نمودارها

موضوعات اصلی:

جی پی. سهم. ثبت شده "
جی پی. استخر. به روز رسانی (اندازه، به روز رسانی رقابتی)
جی پی. بمب گذاری شده

جی پی. پرداخت. درخواست شده	اعتبار	شکست خورده
تمام شد. اعتبار. (بازتاب برای ساگا)
آ ره. محدود کردن AML را بزنید. هشدار. باز "(اگر پرداخت مسدود شده است)
بله، بله. پیکربندی کنید. تغییر (محدودیت ها، بذر، کلاه، توزیع)

قراردادها: Avro/JSON Schema + Schema Registry، کلیدهای مشارکت 'tenant _ id'، 'pool _ id'، 'player _ id'. نسخه - سازگار با عقب.

6) الگوریتم های ماشه (سطح بالا)

احتمالاتی (p-stable): برای هر دور واجد شرایط ما یک ضربه با احتمال 'p' (بسته به نوع استخر/سطح) تولید می کنیم.

Range (must-drop): استخر باید به cap-sum یا deadline برسد - تصادفی داخلی را در محدوده [min، max] نگه دارید، کلاه/ETA را منتشر کنید.

مدیریت دانه و آنتروپی: بذر سرور + نمک در هر دور ؛ ترک صندلی برنده تمام پولها مشتری. تمام تغییرات در بذر تحت حسابرسی WORM است.

صداقت: ماشه نباید به شخصیت خاص بازیکن (به غیر از قوانین جغرافیایی/مجوز/صلاحیت) بستگی داشته باشد. هر هدف «شخصی» تابو است.

7) SLO و عملکرد

«مشارکت» p95 <120 ms، p99 <250 ms.

p95 «ماشه → اعتبار» <500 ms (بدون هاپ پرداخت خارجی).

«پرداخت از دست رفته/تکراری» = 0 (چک شده توسط آزمون قرارداد).

تحویل رویداد به BI ≤ 5 دقیقه.

در دسترس بودن JP API برای مسیرهای بحرانی ≥ 99. 95%.

8) ایمنی و انطباق

mTLS + signatures (HMAC/EdDSA) در تمام تماس های S2S کوتاه مدت نشانه.

اعتماد صفر: سیاست های شبکه/مش، حداقل امتیازات، تقسیم بندی بر اساس منطقه.

ممیزی WORM از تغییرات به محدودیت ها، فرمول ها، بذر/آنتروپی، پیکربندی استخر.

GDPR/اقامت داده/PCI: PII و سیاهههای مربوط - در منطقه ؛ نشانه گذاری زمینه های حساس ؛ ممنوعیت خواندن بین منطقه ای.

RG/AML: چراغ ترمز همزمان در پرداخت ؛ آپلود SAR/STR به صورت خودکار انجام می شود.

9) انسجام و sagas

مشارکت ('مشارکت') - ثابت در JP, انتشار 'JP. سهم. ضبط شده است.

Trigger («trigged») - یک تعهد ایجاد می کند ؛ JP «پرداخت» را راه اندازی می کند.

پرداخت ("پرداخت. درخواست → کیف پول. اعتبار. خوب ') - به پایان می رسد حماسه ؛ با جعلی - retrai با deduplication.

Outbox/CDC تنها راه برای انتشار رویدادها است ؛ بدون «دور زدن» loggers.

10) تله متری و داشبورد

کسب و کار:

«pool _ size», «> rate», «avg _> _ per _ bet», «time _ to _ drop», «payouts _ count/sum», «tier _ distribution».

فنی:

p50/p95/p99 по 'مشارکت', 'ماشه', 'پرداخت';
نرخ خطا с типами (5xx/4xx/business)، طوفان های مجدد، تاخیر صف ؛
تمام شد. اعتبار 'تاخیر/نرخ خوب ؛ درگیری به روز رسانی استخر.

هشدارها:

رشد در راه است. شکست خورده '> X٪ با نام تجاری/منطقه،' pool _ size '> کلاه - Y٪ زمان (خطای پیکربندی)، رانش بین' pool _ size 'و مقدار مشارکت آشتی> Z ppm.

11) چند اجاره و انزوا

تمام درخواست ها و رویدادها 'tenant _ id/brand _ id/license/region' مشخص شده اند.

استخرهای محلی/شبکه به صورت فیزیکی (DB/cluster) تحت مجوز/مناطق مختلف جدا می شوند.

امنیت سطح ردیف (RLS) و پوشش در فروشگاه های BI.

کلید های فردی/اسرار و فضاهای شماتیک در هر نام تجاری/منطقه.

12) ادغام با پاداش/مسابقات

کمک ها به طور مستقیم افزایش نمی یابد ؛ کمک به پاداش - از شرط می آید، نه از سهم.

مسابقات ممکن است امتیازاتی را برای «مشارکت JP» یا «مشارکت برتر» اعطا کنند. "منبع - رویدادهای 'JP. سهم. ضبط شده 'и' jp. باعث شد.

قانون اجباری: مکانیک برنده تمام پولها RTP اساسی از بازی را تغییر دهید; در غیر این صورت گواهینامه جداگانه مورد نیاز است.

13) شیوه های تست و هرج و مرج

تست های قرارداد RGS↔JP↔koshelyok: تحویل دوگانه، تاخیر، عدم سفارش، بازپرداخت.

تست بار: طوفان شرط و ماشه، پوسته پوسته شدن کارگران استخر.

تمرینات هرج و مرج: سقوط منطقه JP، کیف پول آفلاین، زمان desynchronization ؛ چک کردن جعبه و تخریب (مکث باعث/بدون مشارکت جدید).

14) چک لیست

برای استودیو/RGS

Idempotent «سهم» و اصلاح «round _ id »/« bet _ id».
بدون انتشار «دور زدن» معاملات (outbox/CDC تنها).
تست تکراری/تکرار باعث/جبران.
حداکثر محدودیت شرط/صلاحیت به JP منتقل.

برای اپراتور/پلت فرم

لجر منبع حقیقت است، کیف پول. اعتبار 'با deduplication.
توقف RG/AML در پرداخت پردازش می شود ؛ گزارش های SAR/STR
p95 "ماشه → داشبورد اعتباری، نرخ خطا، آشتی استخر.

برای مالک JP

ممیزی WORM تغییرات فرمول/بذر/حد.
طرح رویداد در رجیستری و نسخه.
DR: RPO ≤ 5 دقیقه، RTO ≤ 30 دقیقه ؛ تمرینات منظم
RLS/انزوا با نام تجاری/مجوز ؛ کلید/اسرار در هر منطقه.

15) پرچم های قرمز (ضد الگوهای)

ویرایش دستی اندازه استخر و پرداخت در پایگاه داده.

فقدان idempotence → وام های تکراری.

انتشار تله متری بدون outbox/CDC → مشارکتها/محرکهای «از دست رفته».

مخلوط کردن PII و داده های پولی مناطق مختلف.

برنده تمام پولها که RTP بازی پایه بدون صدور گواهینامه جدید تاثیر می گذارد.

بدون کیف پول و استخر آشتی ؛ گزارش ها بر اساس مبارزه با OLTP است.

Jackpot Systems API یک قرارداد رویداد پولی بین یک استودیو، پلت فرم و اپراتور است. پایه و اساس آن: idempotence و sagas، جداسازی دقیق پول، طرح های رویداد روشن، امنیت و حسابرسی WORM، قابلیت مشاهده و SLO. در این طراحی، ثابت/مترقی و استخر شبکه مقیاس قابل پیش بینی، پرداخت درست باقی می ماند، و گزارش نظارتی و کسب و کار شفاف و قابل اعتماد هستند.