加密賭場

Torrent Gear

大獎系統API如何工作

文章全文

💡 18+.材料是工程和應用的，沒有遊戲要求。術語：平臺-PAM/錢包/現金/獎金/RG；RGS-遠程遊戲服務器（工作室遊戲的核心）；聚合器-集合RGS的統一層；JP是jackpot服務。

1）什麼是頭獎系統，它站在生態系統中

頭獎系統是一項單獨的服務（有時是服務集群），可從費率中收集捐款，管理獎金池和觸發器，計算獎金分配並通過運營商的付款回路啟動付款。它集成了：

帶有RGS（利率/結果和資格報告），帶有平臺/錢包（註銷捐款和獎金貸款），帶有聚合器（來自多個工作室/品牌的路由器），帶有BI/監管器（遙測和報告）。

2）頭獎類型（以及在API中更改的內容）

1.固定（固定）：預先知道的獎金金額。API中沒有池，只有條件檢查和信用。

2.進步（Progressive）：池從利率貢獻增長。我們需要捐款和公布目前的數額。

3.多層（Multi-tier： Mini/Major/Grand）：多個並行池具有不同的機會和引擎蓋。

4.本地vs網絡：一個運營商/品牌的本地池；網絡-多個運營商/品牌/地區的總和（多重性和復制至關重要）。

5.時間/活動：帶截止日期或時間表的池（需要計時器和自動抽獎）。

3）現金不變量

平衡真理的來源是平臺的錢包/ledger。JP僅存儲池和承諾的狀態。

所有現金交易都是偶數的（鍵'jp_contrib_id'、'jp_trigger_id'、'jp_payout_id'）。

「損失/重復付款」=0。補償僅是事件（傳奇），不是DB手動編輯。

將分費（貢獻）、觸發器（觸發器）和付款（付費）分為具有自己遙測功能的獨立交易。

4） API參考合同

4.1個RGS/聚合器 → JP（貢獻和觸發器）

「POST/v1/jp/contributions」-計算池貢獻

json
{
"jp_contrib_id": "uuid-1",  "tenant_id": "brand-42",  "pool_id": "grand-eu-01",  "player_id": "p_abc",  "game_id": "studio:slot_777",  "round_id": "r_123",  "bet": {"amount": 2.00, "currency": "EUR"},  "contrib": {"amount": 0.02, "currency": "EUR"},  "occurred_at": "2025-10-23T15:12:05Z",  "idempotency_key": "round_r_123"
}

「POST/v1/jp/candidates」-申請/條件驗證（可選）

答案是：「eligible： true/false」，重量或機會，規則。

「POST/v1/jp/triggers」-確定觸發事實

json
{
"jp_trigger_id": "uuid-2",  "pool_id": "grand-eu-01",  "reason": "random_hit",  "selector": {"player_id": "p_abc", "round_id": "r_123"},  "occurred_at": "2025-10-23T15:12:06Z",  "idempotency_key": "jp_t_grand_r_123"
}

💡 註意：在某些型號中，觸發器由JP本身（內部輪盤）發起，RGS僅報告該回合。然後，「觸發器」被JP→platforma調用，RGS訂閱該事件。

4.2 JP →平臺（付款/準備金）

「POST/v1/wallet/reserve」-（可選）未來付款的準備金

「POST/v1/wallet/credit」-獎金給玩家

json
{
"jp_payout_id": "uuid-3",  "tenant_id": "brand-42",  "player_id": "p_abc",  "pool_id": "grand-eu-01",  "amount": {"amount": 500000.00, "currency": "EUR"},  "meta": {"tax": "withheld=false", "tier": "grand"},  "idempotency_key": "jp_p_grand_r_123"
}

Platphoma的答案：'Credit.ok	failed'，帶有原因代碼（RG/AML，撤軍限制，制裁，地理區塊）。

4.3發布池狀態（用於前端/小部件）

「GET/v1/jp/pools/{pool_id} 」→當前大小，種子，帽子，參與者人數，ETA等。

「GET/v1/jp/pools」 →按品牌/區域列出的具有過濾器的池列表。

5）事件模型（Kafka/Pulsar）和電路

基本拓撲：

`jp.contribution.recorded`
`jp.pool.updated'（尺寸、競爭性升級）
`jp.triggered`

`jp.payout.requested	credited	failed`
`wallet.credit. '（sag鏡像）
`rg.limit.hit`, `aml.alert.opened'（如果付款被阻止）
`audit.config.changed'（限制,種子,cap,分布）

合同：Avro/JSON Schema+Schema Registry，「tenant_id」，「pool_id」，「player_id」分期付款密鑰。轉化是可逆的。

6）觸發算法（高級）

概率（p持續性）：對於每個合格回合，我們都會產生概率「p」（取決於池/級別類型）的命中率。

範圍（必須下降）：池必須下降到cap總和或截止日期-我們將內部範圍保持在［min, max］範圍內，我們發布cap/ETA。

悉尼和內陸控制：服務器種子+環繞鹽；拒絕為頭獎提供客戶座位。所有種子更改均在WORM審核下進行。

誠實：觸發器不應取決於玩家的特定身份（地理/許可/資格規則除外）。任何「個人」目標都是禁忌。

7） SLO和性能

p95 'contribution' <120 ms, p99 <250 ms.

p95' trigger→credit '<500 ms（沒有外部收費跳線）。

「損失/重復付款」=0（通過合同測試檢查）。

將活動交付給BI ≤ 5分鐘。

關鍵路徑的JP API可用性≥ 99。95%.

8）安全和合規性

所有S2S呼叫上的mTLS+簽名（HMAC/EdDSA）；短壽命令牌。

零信任：網絡策略/mesh，最低特權，按地區劃分。

WORM審核限制，公式，seed/entropy，池配置的更改。

GDPR/數據駐留/PCI：PII和徽標-在該地區；敏感場標記化；禁止跨區域閱讀。

RG/AML：支付時的同步停止信號；SAR/STR卸載是自動化的。

9）一致性和傳奇

會費（「貢獻」）-記錄在JP中，我們發布「jp」。contribution.recorded`.

觸發器（「觸發器」）-產生承諾；JP發起「payout」傳奇。

付款（'payout。requested → wallet.credit.ok'）-完成傳奇；faille-重復數據消除後繼。

Outbox/CDC是發布事件的唯一途徑。沒有「旁路」記錄器。

10）遙測和行車記錄儀

業務：

`pool_size`, `contrib_rate`, `avg_contrib_per_bet`, `time_to_drop`, `payouts_count/sum`, `tier_distribution`.

技術性：

p50/p95/p99 по `contribution`, `trigger`, `payout`;
error rate с типами (5xx/4xx/business), retry storms, queue lag;
`wallet.credit` latency/ok-rate;池更新沖突。

Alerts：

payout的增長。failed'>X%按品牌/地區,'pool_size'> cap-Y%時間（配置錯誤）,在'pool_size'和>Z ppm核對貢獻金額之間漂移。

11）多重性和隔離

所有查詢和事件均標有「tenant_id/brand_id/license/region」。

本地/網絡池在物理上（DB/cluster）在不同的許可/區域上分開。

Row-level security （RLS）和BI店面中的蒙版。

每個品牌/地區的單個密鑰/秘密和示意圖空間。

12）與獎金/錦標賽集成

貢獻不會直接增加vager；對獎金的貢獻-來自費率而不是貢獻。

錦標賽可以為「參加JP」或「獲得最高貢獻」獲得積分。來源是'jp事件。contribution.recorded` и `jp.triggered`.

強制性規則：頭獎力學不會改變遊戲的基本RTP；否則需要單獨的認證。

13）測試和混亂做法

合同測試RGS↔JP↔koshelyok：雙發、延遲、訂單外、回滾。

負載測試：投註風暴和觸發器，擴大池操作員。

混沌教義：JP地區的衰落，離線錢包，時間同步化；檢查出口和退化（pause triggers/no new contributions）。

14）支票單

對於工作室/RGS

等效的「貢獻」和正確的「round_id」/「bet_id」。
沒有出版物「繞過」交易（僅限outbox/CDC）。
雙/重復觸發/補償測試。
max bet限制/資格轉讓給JP。

對於操作員/平臺

Ledger是真理的來源，"wallet。信用與重復數據消除。
RG/AML腳在付款時處理；SAR/STR報告。
Dashbords p95' trigger→credit',error rate,池對賬。

對於JP所有者

WORM審核公式/種子/限制更改。
註冊和版本中的事件圖。
DR：RPO ≤ 5分鐘，RTO ≤ 30分鐘；定期演習。
按品牌/許可證劃分的RLS/隔離；按區鍵或秘密。

15）紅旗（反模式）

在DB中手動編輯池大小和付款。

缺乏相容性→信用雙倍。

在沒有outbox/CDC的情況下發布遙測→「丟失」的貢獻/觸發器。

PII和不同地區的貨幣數據的混合。

在沒有新認證的情況下影響基礎遊戲RTP的頭獎。

沒有錢包和池；報告是根據戰鬥OLTP構建的。

頭獎系統API是工作室，平臺和運營商之間的貨幣事件合同。它的基礎是：等效性和傳奇，硬性貨幣隔離，清晰的事件模式，安全性和WORM審計，可觀察性和SLO。在這種設計中，虛構/漸進式池和網絡池可以預測地擴展，付款保持正確，監管和業務報告透明且可靠。