GMG的观测站把每局房间日志切成三类事件：开房请求、房间确认、选手进桌。正常情况下这三条应该在800毫秒内串成一条线。但如果你经手的是新老夫子房卡代理这类中间环节，这条线经常断在第二跳。
新老夫子房卡代理在赛事数据站里的异常对账：七局房间日志与三方时间戳
短讯 · 2026-10-16 20:52:39
上周有人在社群里问：新老夫子房卡代理在赛事数据站里到底看不看得到开房动作。这个问题其实问偏了——能看到，但看到的不是「谁开了房」，而是三套时钟互相打架之后留下的一串时间戳。
七局样本里，时间差不是随机的
我们拉了最近七局有代理环节介入的开房记录，统计了「客户端本地时间」和「房间服务器回执时间」的差值。结果不是正态分布，而是明显分了三档：
- 第一档：47到82毫秒，四局，基本可以忽略；
- 第二档：210到340毫秒，两局，集中在晚间高峰段；
- 第三档：一局跳到900毫秒以上，回执和观测节点时间戳直接对不上号。
第三档那局最值得看。客户端日志写的是21:14:03开房，房间服务器确认在21:14:04.1，而赛事观测节点抓到的进桌时间是21:14:03.7。进桌比确认还早——这在物理上不可能，只说明观测节点用的是另一套授时源。
代理环节到底改了什么
把新老夫子房卡代理拆开看，它实际夹在开房请求和房间确认之间，做的事情是转发和换绑。转发本身加不了多少延迟，真正动时间戳的是换绑那一步：代理侧会用自己的会话标识替换原始请求里的房间凭证，而这个替换动作的时间点，客户端本地不记录。
换句话说，你在客户端看到的开房时间，和代理实际完成换绑的时间，中间隔着一次没有落盘的IO。七局里有两局的差异超过300毫秒，根源都在这里。
对分析师来说，这意味着什么？如果你用客户端时间去做选手指纹对齐，在代理局里会系统性偏移。偏移量不固定，但方向一致：客户端时间偏早。
三条数据车道怎么对齐
GMG的做法是把房间日志里所有时间戳统一映射到观测节点授时，而不是取客户端时间。具体三步：
- 先按房间ID把客户端日志、代理转发日志、房间服务器回执三份数据拉到同一张表；
- 以房间服务器回执时间为基准，反向修正客户端时间的偏移量；
- 修正后的时间再喂给经济曲线模块，避免开房时刻的经济快照取错帧。
这套流程跑下来，七局样本里原本对不齐的三条车道，有六局能收敛到误差150毫秒以内。剩下那局卡在900毫秒档的，回执本身就有问题，只能标记为异常局，不纳入选手指纹计算。
判断代理质量，先看回执抖动
如果你想评估一个新老夫子房卡代理环节稳不稳，别只看它成不成，要看回执时间的抖动幅度。同一时段连续开五局，如果回执时间标准差超过120毫秒，说明转发链路在高峰期会积压。这个指标比「能不能开」有用得多。
GMG观测站里有个现成的视图可以看这个：把房间服务器回执时间按分钟聚合，画成抖动带。代理环节健康的时候，这条带子应该窄且平；一旦出现台阶式抬升，就是链路在排队。
房卡代理本身不是问题，问题在于它把时间戳链条拉长了一环，而这一环默认不落盘。做赛事数据的人要做的，就是把这环补回来。