第七章：“谁说它是随机的？”—— 棋牌源代码中的库存逻辑、AI决策与服务端行为架构

我们把它称为库存池。它像个“服务器账户余额”：每轮互动组件的结果都要参考它，太低就“节制发放”，太高就“适当回吐”。这其实和某些网络游戏的“经济系统”类似，保证整体池子不被玩穿。

17源码网

1003人浏览 · 2025-06-14 00:00:00

17源码网 · 2025-06-14 00:00:00 发布

“谁说它是随机的？”—— 棋牌源代码中的库存逻辑、AI决策与服务端行为架构

很多人以为，这类互动组件的结果都是“随机”的，随手一转，运气好就能连线爆奖。

但如果你真正翻过棋牌源代码的服务端逻辑，就会发现，所谓“随机”，其实是概率控制 + 状态同步 + 库存权重 + 玩家画像四位一体的结构。

也就是说，表面上你在点击，实际上后台已经为你铺好了一条“策略路径”。

本章，我们不讲任何敏感内容，也不分析算法公平性。我们只看源码：它是怎么构建这套系统的？这些库存、AI、结果生成，到底是怎么协作运行的？

一、库存是怎么定义的？它其实是一份实时预算表

在很多服务端源码中，我们都能看到类似下面的结构：

{
    roomId: 'R1001',
    currentStock: 850000,
    maxStock: 1000000,
    minStock: 100000,
    lastModifyTime: 1710000000
}

我们把它称为库存池。它像个“服务器账户余额”：每轮互动组件的结果都要参考它，太低就“节制发放”，太高就“适当回吐”。

这其实和某些网络游戏的“经济系统”类似，保证整体池子不被玩穿。

二、服务端结果生成流程：库存是第一参考，AI 是第二策略

在一个正常组件流程中，服务端的流程通常是这样：

玩家请求开始游戏；
服务端生成一个随机号；
判断库存是否允许；
如果允许，生成对应“中奖”结果；
如果库存不足，降级处理，甚至 AI 出手干预；
返回结果；
写入数据库。

一个示意结构：

socket.on('start_game', async (data) => {
    const uid = socket.uid;
    const roomId = await cache.getRoomIdByUid(uid);

    const stock = await db.getStock(roomId);

    const result = generateResult(stock);

    const adjusted = adjustByStock(result, stock);

    await db.saveGameResult(uid, adjusted);

    socket.emit('game_result', adjusted);
});

其中 adjustByStock 就是核心库存判断逻辑。

三、adjustByStock 实际上是一种“安全守门机制”

来看一个简单的库存调整逻辑：

function adjustByStock(result, stock) {
    if (result.reward + stock.currentStock > stock.maxStock) {
        // 奖励太大，超出库存
        result.reward = Math.floor(Math.random() * 50); // 伪奖
    } else if (result.reward === 0 && stock.currentStock < stock.minStock) {
        // 发点福利
        result.reward = 100 + Math.floor(Math.random() * 100);
    }
    return result;
}

当然真实逻辑要复杂很多，它还会考虑：

用户历史奖励记录；
当前房间全体玩家的平均胜率；
本轮操作前后的库存增减；
是否连续空奖；
玩家是否为 AI。

四、AI 决策模型：不是外挂，而是“角色模拟器”

AI 并不一定是“作弊”，它更像是系统中“让流程完整”的角色。

举个例子，在一个三人对战型组件中，如果房间只有两名真人，为了流程正常运行，就需要插入一个 AI：

function getRoomParticipants(roomId) {
    const users = db.getUsers(roomId);
    if (users.length < 3) {
        users.push(createAIUser());
    }
    return users;
}

AI 的决策逻辑一般由概率模型控制：

function decideAIAction(aiUser, roomState) {
    const rand = Math.random();
    if (rand < 0.3) return 'actionA';
    if (rand < 0.7) return 'actionB';
    return 'pass';
}

高级一点的项目会读取玩家行为模型来“模仿”。

五、库存同步机制：Redis 是调度核心，Mongo 是日志记录

在高并发的组件中，库存数据不能写死在 Mongo 中读取。读取慢、不同步、冲突风险大。

所以我们会设计这样的流程：

Redis 中保存库存数据，每次请求前读取、处理、写回；
Mongo 只记录最终结果，方便审计与查错。

库存结构示例：

{
    "stock:R1001": {
        current: 850000,
        lastReward: 200,
        recentUsers: [1001, 1002, 1003]
    }
}

Redis 操作函数封装：

async function getRoomStock(roomId) {
    const json = await redis.get(`stock:${roomId}`);
    return JSON.parse(json);
}

async function updateRoomStock(roomId, change) {
    const stock = await getRoomStock(roomId);
    stock.current += change;
    await redis.set(`stock:${roomId}`, JSON.stringify(stock));
}

每个操作都要 await 保证执行顺序。

六、多人流程下的库存一致性：加锁是必须的

两个玩家同时触发流程，如果库存是共享的，怎么防止“你抢了我这笔钱”？

答案就是Redis 锁。

async function tryLock(roomId) {
    const res = await redis.set(`lock:${roomId}`, 1, 'NX', 'EX', 2);
    return res === 'OK';
}

流程示意：

if (await tryLock(roomId)) {
    const stock = await getRoomStock(roomId);
    const result = adjustByStock(originalResult, stock);
    await updateRoomStock(roomId, -result.reward);
    unlock(roomId);
}

这样你就不会在多人同时操作时把库存打乱。