赌场如何通过桥梁连接直播提供商

什么是现场赌场背景下的桥梁

Bridge是运营商平台与实时提供商（Evolution，Pragmatic Live，Ezugi，TVBet等）之间的分层，可使API，事件，拼写和财务计算正常化。简而言之，桥使十几种不同的"视图"集成相同：单个投注合同，单个回合状态方案，单个webhooks和报告性。

为什么需要它

数十家提供商的单一合同（减少平台更改）。

相似性和双打防守（网络后卫，玩家重新侦察）。

目录正常化（表、限制、边框、位置）。

单一现金和风险规则（限制，AML/KYT，RG）。

跨供应商监视QoS流和SLA。

组件链

1.赌场平台（主机）：帐户，KYC/RG，奖金，钱包，前线。

2.桥：提供商适配器，事件总线，桌子/极限布局，结算，拼写，webhooks。

3.实时提供者：流（通常是WebRTC/HLS），游戏引擎，计算结果，经销商。

4.钱包：Seamless（资产负债表由运营商持有）或Transfer（由提供商存入游戏银行）。

5.可观察性：流度度量（FPS，RTT，缓冲区），业务度量（Bet，GGR，Hold）。

网络协议和会议

视频：

WebRTC-低延迟（100-500毫秒），需要ICE/STUN/TURN。
HLS/LL-HLS-延迟较高，但比CDN更简单。
费率和事件：WebSocket/HTTP-SSE/REST。
代币：短寿命的JWT/opaque（TTL 3-10分钟），根据提供商的要求轮换。

钱包模型

1） Seamless wallet（推荐）

利率/付款通过桥梁进入运营商的钱包。

优点：单一平衡,即时限制控制,简化RG。

缺点：严格的钱包可用性（SLA）要求。

2) Transfer wallet

玩家将资金从提供商转移到"桌子银行"。

优点：峰值期间操作员钱包的负荷较小。

缺点：更难回收、回收和AML控制,在UX中摩擦。

会话生命周期（seamless）

1./createSession → bridge创建"sessionId"，返回"streamUrl"，"betSocketUrl"。

2.前端打开播放器（WebRTC/HLS）和事件连接。

3.玩家在桥上押注"placeBet"（"idempotencyKey"，"roundId"，"selection"，"stake"）。

4.Bridge授权钱包中的金额（保留）→确认提供商。

5.提供商宣布"bettingClosed" → spin/deal → "roundResult"。

6.Bridge计算付款，注销/退回hold，生成"transactionId"。

7.Bridge将webhook平台放下（"roundId"，"result"，"payout"，"balanceAfter"），写信给ledger。

8.完成/重新连接-通过"sessionId"（平均）。

事件合同（示例）

桥梁→率（WS/REST）：

json
{
"type": "bet.place",  "idempotencyKey": "c0a4-77f…",  "sessionId": "sess_abc123",  "roundId": "R-2025-10-17-18:45:03-Table23",  "selection": [{"market":"roulette_straight","value":"17"}],  "stake": {"amount":"5.00","currency":"EUR"},  "limitsProfile":"VIP_A"
}

桥梁答案：

json
{
"status":"accepted",  "balanceHold":"-5.00",  "betId":"bet_9f2…",  "effectiveLimits":{"maxBet":"5000.00"}
}

回合结果→平台（webhook）：

json
{
"event":"round.settle",  "roundId":"R-2025-10-17-18:45:03-Table23",  "bets":[
{"betId":"bet_9f2…","stake":"5.00","payout":"180.00","outcome":"WIN"}
],  "transactions":[
{"id":"trn_bet_9f2…","type":"DEBIT","amount":"5.00"},   {"id":"trn_pay_9f2…","type":"CREDIT","amount":"180.00"}
],  "balanceAfter":"1320.40"
}

关键规则：

相似性：所有查询"idempotencyKey"。
明确的结果类型："WIN/LOSE/PUSH/VOID/RETRY"。
稳定标识符："roundId"是全局唯一的（表+时间+shard）。

目录和限制

Discovery： '/providers/： id/tables'-桌子列表、限制、边框、语言、时间表。

限制池："DEFAULT"，"VIP_A"，"VIP_B"，"Ultra"。

Mapping规则：国家/货币/KYC状态→允许的桌子和限制配置文件。

热极限变化：事件极限。更新"而不重新启动桌面。

流的可观察性和质量（QoS）

玩家指标：

投注信号的RTT（目标<150 ms WebRTC）。
Dropped frames / buffer events.
Bitrate/Resolution改编。
投注窗口（在"bettingOpen"和实际投注之间的时间）。

提供商/桌子上的指标：

桌子的上限，简易的回合，后期设置，"VOID"频率。
博彩结束后平均计时。
QoS alerta：FPS降解，"retry"爆发。

合规与安全

KYT/AML：存款来源分析、"高风险"标志→现场投注禁令。

RG（负责任的游戏）：超时，限制，自我体验-在"placeBet"之前应用。

数据驻留：逻辑和PII存储在操作员中；桥仅存储技术。杂志和单位。

运输安全：mTLS/IP-whitelist到提供商,HMAC请求签名,短令牌的TTL。

审计：leder不可变（WORM/仅append-only），通过"roundId"/"sessionId"导出。

计算、重新计算和退款

飞行设置：每个结果的即时借记/信用。

Batch reconcile：提供商报告（hourly/daily）与bridge ledger （P&L,佣金）核对。

VOID/REFUND脚本：流失、经销商错误、争议-部分/完全退货,有明确的原因代码。

Dispute center： "roundId"捆绑包↔录制视频映射（超时代码）,以便支持快速解决提卡问题。

性能和容错能力

标量：提供商的静态适配器+Kafka/NATS作为事件总线。

存储：用于会话/限制的热（Redis），用于ledger的热（Postgres），用于日志的冷（S3）。

Folbacks：如果钱包没有响应-带有后退的"SOFT_DECLINE"；如果提供商不可用-关闭大厅中的桌子/隐藏。

难得的回程：通过网络时间表重复"placeBet"/"settle"是安全的。

UX： 前端模式

时钟同步：使用桥上的"serverTime"进行"通过关闭博彩……"计时器。

本地化：经销商语言≠接口语言；显示字幕/术语表。

流播放器：网络较差时自动倒置WebRTC → LL-HLS。

错误UI：易懂的代码（"LBRG-401 TOKEN_EXPIRED'，"LBRG-429 LIMIT_EXCEEDED'，"LBRG-503 PROVIDER_DOWN')。

多重性：快速刷桌而不会打断会话（reuse 'sessionId'）。

反模式

将长寿令牌存储在客户端上。

在"bettingClosed"之后接受赌注，因为经销商-争议得到保证。

没有"idempotencyKey" →回避时被淘汰。

在"roundId"和报告中混合时间区。

在没有配置文件和KYC状态的情况下设置"眼睛"限制。

忽略流的QoS是移动网络上的高教堂。

逐步实施计划（支票单）

体系结构和合同

记录单个事件合同：'bet。place`, `bet.accepted`, `bet.rejected`, `round.settle`, `limits.update`, `session.close`, `provider.error`.
定义idempotency和"roundId"、"betId"、"transactionId"格式。
选择一个钱包模型（优先无塞姆）。

安全性

mTLS给提供商,HMAC签名网络手册,TTL令牌≤ 10分钟。
RG/AML/KYT的利率准入政策，审核日志。

目录和限制

限额表和配置文件的导入,按国家/货币/CUS排列。
桌子极限和状态的热更新。

弗龙滕德

WebRTC播放器带有LL-HLS后卫，定时时钟，稳定投注计时器。
错误代码和人文信息。

测试计划

High-latency/packet-loss脚本,reconnection,不损失赌注。
双重投注点击→一次借记（平均水平）。
VOID/REFUND,有争议的回合,报告差异。

可观察性

[] Дашборд QoS: RTT, dropped frames, aborted rounds, time-to-settle.

Alerta通过提供商的SLA，reconcile报告。

Bridge将实时集成的"动物园"转换为托管系统：单一投注，单一计算，可预测的UX和透明的流质量控制。通过正确设计的桥梁，运营商可以更快地连接新的实时提供商，降低技术风险，并通过等效性，严格的限制和可观察性来保护P＆L。