关于 bson encode 的数据无法通过 skynet.call 传输的问题

[hanxi]

我现在想实现一个 mongodb service 连接池子，所有的 db 操作都通过 skynet.call 或者 skynet.send 传输到这些池子里来执行。对于普通的接口没有什么问题，但是对于 raw_safe_insert 这样的接口有点问题， bson_encode 的结果无法正常通过 lua-seri 序列化。因此我先对 bson_encode 的结果执行 tostring ，然后在接收方再通过对这个字符串重新构造一个 userdata 结果来实现。

示例代码：

调用服务

function coll_mt:safe_insert(doc)
    local conn_obj = self.db:_route()
    return skynet.call(conn_obj.addr, "lua", "raw_safe_insert", self.coll, tostring(bson_encode(doc)))
end

池子服务

function CMD.raw_safe_insert(coll, bson_str)
    local col_obj = g_db[coll]
    local bson_str_obj = bson_meta(bson_str)
    return col_obj:raw_safe_insert(bson_str_obj)
end

通过新增一个 bson_meta 接口来重新构造 userdata :

diff --git a/lualib-src/lua-bson.c b/lualib-src/lua-bson.c
index 29d6c70..2f44e39 100644
--- a/lualib-src/lua-bson.c
+++ b/lualib-src/lua-bson.c
@@ -978,6 +978,19 @@ lencode(lua_State *L) {
        return 1;
 }

+static int
+lmeta(lua_State *L) {
+    size_t sz = 0;
+    const char * str = luaL_checklstring(L, 1, &sz);
+    if (sz == 0) {
+        return luaL_error(L, "empty string cannot be converted to bson userdata");
+    }
+    void * ud = lua_newuserdatauv(L, sz, 1);
+    memcpy(ud, str, sz);
+    bson_meta(L);
+    return 1;
+}
+
 static int
 encode_bson_byorder(lua_State *L) {
        int n = lua_gettop(L);
@@ -1340,6 +1353,7 @@ luaopen_bson(lua_State *L) {
                { "objectid", lobjectid },
                { "int64", lint64 },
                { "decode", ldecode },
+               { "meta", lmeta },
                { NULL,  NULL },
        };

我的问题是：还有没别的更合适的方案？

[cloudwu]

lua 5.5 支持了 external string ，稍后我加一个接口直接把 bson encode 成 string 。

不过这里跨服务传输，我觉得 encode 成 lightuserdata 接收方 free 可能更好一点。

[hanxi]

进程内确实 lightuserdata 更合适。

[fanyh]

encode 成lightuserdata 然后用 skynet.redirect把数据转发到db 实例 这样应该差不多了

[cloudwu]

如果能管理好生命期，目前什么都不用改，直接转指针就可以。

[hanxi]

使用指针也是需要简单改下才能正常运行：

1. 发送方把 userdata 转成 lightuserdata ;
2. 接收方需要用 bson_meta 把 lightuserdata 处理下;
3. append_one 接口需要处理 LUA_TLIGHTUSERDATA 类型。

diff --git a/lualib-src/lua-bson.c b/lualib-src/lua-bson.c
index 29d6c70..21914c6 100644
--- a/lualib-src/lua-bson.c
+++ b/lualib-src/lua-bson.c
@@ -327,6 +327,7 @@ append_one(struct bson *bs, lua_State *L, const char *key, size_t sz, int depth)
        case LUA_TNUMBER:
                append_number(bs, L, key, sz);
                break;
+       case LUA_TLIGHTUSERDATA:
        case LUA_TUSERDATA: {
                append_key(bs, L, BSON_DOCUMENT, key, sz);
                int32_t * doc = (int32_t*)lua_touserdata(L,-1);
@@ -978,6 +979,20 @@ lencode(lua_State *L) {
        return 1;
 }

+static int
+lmeta(lua_State *L) {
+       lua_settop(L,1);
+       bson_meta(L);
+       return 1;
+}
+
+static int
+lto_lightuserdata(lua_State *L) {
+       void *p = lua_touserdata(L, 1);
+       lua_pushlightuserdata(L, p);
+       return 1;
+}
+
 static int
 encode_bson_byorder(lua_State *L) {
        int n = lua_gettop(L);
@@ -1340,6 +1355,8 @@ luaopen_bson(lua_State *L) {
                { "objectid", lobjectid },
                { "int64", lint64 },
                { "decode", ldecode },
+               { "meta", lmeta },
+               { "to_lightuserdata", lto_lightuserdata },
                { NULL,  NULL },
        };

生命周期还是原来的 userdata 的生命周期，使用 skynet.call 应该是没问题的，使用 skynet.send 就可能会被提前释放。

[ibitcat]

这里不能简单的 to_lightuserdata，call 也无法保证，被调用方会出现 endless 或者 decode时 coredump，现场如下：

实验步骤如下：

-- 调用方服务
function DBProxy:rawSafeUpdate(colName, query, update, upsert, multi)
    local updateBin = bson.encode({
        q = query,
        u = update,
        upsert = upsert,
        multi = multi,
    })

    local ud = bson.to_lightuserdata(updateBin)
     --- 这里call出去后，userdata 因为无引用，可能会被gc
    skynet.error("-------->>>bson", tostring(ud))
    return self:call(dbAddr, "rawSafeUpdate", dbName, colName, ud)
end


--- db 服务
function DbServerApi:rawSafeUpdate(dbName, colName, update_bin)
    local col = mongocli[dbName][colName]
    skynet.error("---------------->>> rawSafeUpdate begin", dbName, colName, tostring(update_bin))
    --- 为了必现，这里call阻塞10s
    skynet.sleep(1000)
    skynet.error("---------------->>> rawSafeUpdate end")
    col:raw_safe_update(update_bin)
end

为了测试方便，给bson ud 加一个 __gc 打印：

static int bson_gc(lua_State *L) {
	struct bson *lbson = (struct bson *)luaL_checkudata(L, 1, "bson");
	printf("bson gc %p\n", lbson);
	return 0;
}

static void
bson_meta(lua_State *L) {
	if (luaL_newmetatable(L, "bson")) {
		// ...
		lua_setfield(L, -2, "__gc");
	}
	lua_setmetatable(L, -2);
}

在调用方call之后，debug 上去执行一下gc，打印如下：

[25-12-05 23:54:20.92] [:0000001b] @./common/proxy/db.lua:215 vars:
  .var#01 = -------->>>bson
  .var#02 = userdata: 0x7b9ad854c138
[25-12-05 23:54:20.92] [:00000014] @./app/db/api/server/api.lua:184 vars:
  .var#01 = ---------------->>> rawSafeUpdate begin
  .var#02 = center_1
  .var#03 = tbl_brief
  .var#04 = userdata: 0x7b9ad854c138

-- 这里执行gc后，可以看到 full userdata 已经被free了。
bson gc 0x7b9ad854c138
[25-12-05 23:54:23.43] [:00000011] GC 101.54 Kb -> 93.18 Kb, cost 0.00 sec
[25-12-05 23:54:23.43] [:00000004] GC 58.57 Kb -> 58.44 Kb, cost 0.00 sec
[25-12-05 23:54:23.43] [:00000007] GC 62.12 Kb -> 61.93 Kb, cost 0.00 sec
[25-12-05 23:54:23.43] [:00000006] GC 57.21 Kb -> 57.08 Kb, cost 0.00 sec
[25-12-05 23:54:23.43] [:00000008] GC 57.65 Kb -> 57.52 Kb, cost 0.00 sec
[25-12-05 23:54:23.43] [:0000000a] GC 226.25 Kb -> 222.04 Kb, cost 0.00 sec

-- 10s 阻塞完毕
[25-12-05 23:54:30.92] [:00000014] @./app/db/api/server/api.lua:186 ---------------->>> rawSafeUpdate end

[ibitcat]

我重新实验了一下，确实是尾调用栈帧覆盖的原因，昨晚思考时没有往这个方向上想，后续得强化这个注意点。

btw, #2075 这里的使用示例是不是也存在同样的问题？可能 @hanxi 使用时要注意一下。

[hanxi]

我也没考虑到 tail call 的问题 😂

这样写能应对任意数量返回值的情况，就是不太好看。

local bson_encode = bson.encode
local to_lightuserdata = bson.to_lightuserdata
function coll_mt:safe_insert(doc)
    local conn_obj = self.db:_route()
    local bson_obj = bson_encode(doc)
    local ret = {skynet.call(conn_obj.addr, "lua", "raw_safe_insert", self.coll, to_lightuserdata (bson_obj))}
    return table.unpack(ret, 1, ret.n)
end

raw_safe_insert 是返回3个值的，直接写死3个值好一点：

local bson_encode = bson.encode
local to_lightuserdata = bson.to_lightuserdata
function coll_mt:safe_insert(doc)
    local conn_obj = self.db:_route()
    local bson_obj = bson_encode(doc)
    local ok, err, r = skynet.call(conn_obj.addr, "lua", "raw_safe_insert", self.coll, to_lightuserdata (bson_obj))
    return ok, err, r
end

[cloudwu]

你并不需要 pack/unpack 绕开 tailcall 的（用 {} pack 也是错的，这样没有 ret.n ）。以前面的例子：

local function ret(...)
	return ...
end

function f()
	local obj = object()
	return ret(foo())
end

这样就可以避免 tailcall 造成的 obj 的生命期提前。因为 foo() 的整个调用发生在 tailcall 之前。

[hanxi]

又学到了，这个 ret 函数妙。

[hanxi]

更正上面的不确定返回值数量的写法:

local bson_encode = bson.encode
local to_lightuserdata = bson.to_lightuserdata
local function ret(...)
    return ...
end
function coll_mt:safe_insert(doc)
    local conn_obj = self.db:_route()
    local bson_obj = bson_encode(doc)
    return ret(skynet.call(conn_obj.addr, "lua", "raw_safe_insert", self.coll, to_lightuserdata(bson_obj)))
end

[253980289]

我有个疑惑，在跨服执行db操作时，为什么要先将数据用bson.encode处理再发到db操作服去而不是将原生数据发过去而在db操作服进行bson.encode处理呢？
我们也是用的独立的db代理服模式，但都是发的原始数据，不知道前者的优势是什么？

[hanxi]

不是有啥优势，是我用了 orm ，必须在有 orm schema 的服务上才能正确的序列化数据。
https://github.com/hanxi/skyext/blob/f731945ae95b5322c14415e1001731642389e033/lualib/orm/init.lua#L224-L232

[253980289]

我个人是感觉在lua这种动态语言中直接使用mongo就蛮不错了，再弄orm机制增加复杂性有些得不偿失的感觉。以前用mysql时我也是做过orm机制的，虽然效果还不错，但也增加了不少复杂性，某些特别场景下还可能因为元表的涉及使原本简单的lua表操作带来一定风险。

[hanxi]

跟mysql那种拼接sql的orm有点不一样，正式因为有lua的元表特性加上mongo的差异写入，才能实现写游戏逻辑不操心数据加载和落地，逻辑操作完内存数据，内存数据直接定时差异落地。

[JackLeeDev]

想法是挺好的，但是性能方面可能是个大问题，如果是c++可能还好，lua的话性能太差了，之前也写过一个类似的库，压测严重不达标，后续弃用了，最终的方案是玩家养成系统数据放agent(自动加载、定时存档)，排行榜、公会、全局活动等数据手动操作实时存档，做了下取舍。

[JackLeeDev]

大部分游戏中，基于玩家的养成系统、活动等数据可能占总数据量的90%以上，这部分放agent自动管理，剩下的10%手动操作数据库，对开发效率影响其实并不大。