请教 sharetable 的使用方式

[tqing1128]

我想到 2 个方案，目前使用的是方案一。
方案一：
将所有配置表合并成一个 key，减少服务初始化时的 skynet.call，尤其是玩家 agent 服务，可能有几十个配置表。但是热更新调用 sharetable.update 时 replace_map 会很大，key 的数量可能在 10W+，导致内存暴涨，只能在调用 sharetable.update 后立即调用一次 gc。

方案二：
每张配置表一个 key，服务按需使用，热更新也比较轻量。但是使用配置表数量多的服务会影响初始化，比如玩家 agent，如果使用 skynet.request，在大量玩家 agent 初始化时，sharetabled 是否会成为单点而影响 agent 初始化？

[tqing1128]

简单来说就是，配置表是合在一起写入 sharetable 还是分开写入

[sniper00]

如果你能确保逻辑代码中不保存被共享的table，只是通过sharetable.query到的根对象使用， 可以用sharetable.query来更新，速度会快很多

[tqing1128]

这种方法使用不方便，使用方一旦保存下来就更新不到了，比较容易出 bug

[sniper00]

我们就是使用时只用root， 用起来还行，比较方便。 我测试过就算你每张表分开，10000个agent, update能耗时上分钟，服务器基本卡死

[tqing1128]

使用的时候每次都先调用获取 root 的函数吗

[aasdpiao]

之前我也想问这个问题。说一下我现在的用法共同探讨一下

sharetable.loadfile("script/config/item_config.lua")

然后在agent中做一个读取配置的代理

local ItemManager = class()

function ItemManager:ctor()
    self.__item_entrys = {}
end
function ItemManager:get_item_entry(item_index)
     if self.__item_entrys[item_index] then
        return self.__item_entrys[item_index]
    end
    local item_config = sharetable.query("script/config/item_config.lua")
    local entry_config = item_config[item_index]
    if not entry_config then 
        LOG_ERROR("get_item_entry item_index:%d",item_index)
        return
    end
    local item_entry = ItemEntry.new()
    item_entry:load_item_config(entry_config)
    self.__item_entrys[item_index] = item_entry
    return item_entry
end

其实我也不知道这样算对不对。

[cloudwu]

我觉得这个问题是：你需要用一个功能完备的 lua 代码生成一组数据(一个 table) ，然后被 sharetable 分享。

我觉得，你可以用任何现有手段生成这个 table ，然后序列化成一个 lua 函数，这个函数可以返回这个 table 。然后你就可以 loadstring 或 loadfile 这个函数了。

[Gowa2017]

loadtable 需要序列化传输 又反序列化 当然慢了

[tqing1128]

这是我的方案：
策划Excel--(转表工具)-->原始 lua--(检查逻辑)-->原始 lua--(重组逻辑)-->最终 lua 文件---->git 仓库

1. 整个流程执行由 jekins 实现
2. (检查逻辑) 是纯 lua 程序，以模块为单位，在 git 仓库中，与分支模块程序对应
3. (检查逻辑)  检查所有数据类型、范围和格式，如果发现错误，打印出所有的错误数据所在的表名、索引，最后抛出错误到聊天工具群
4. (重组逻辑) 是纯 lua 程序，以模块为单位，将多张表重组为程序方便索引的表，并序列化到 lua 文件
5. 项目启动时直接导入最终 lua 文件，无需其他的操作

我把配置表理解为程序的一个特殊输入(策划输入)，是程序启动前的一个输入，对输入数据进行类型和范围检查，只有数据符合 git 的分支中的配置表逻辑才可以提交

优点:
1. 项目程序不会因为配置表问题无法启动
2. 消除配置错误引起的和各种 bug

[Gowa2017]

我俩的动作有点相似我现在是：

1. 数据源分散定义在多个地方。可能是 excel 转的lua 可能是 lua写的脚本。
2. 定义一个加载器负责从目录内读取数据，返回一个表。数据合规性检查什么的在这就能做了。
3. share 这个加载器返回数据就行了。

[JieTrancender]

我觉得这个问题是：你需要用一个功能完备的 lua 代码生成一组数据(一个 table) ，然后被 sharetable 分享。

我觉得，你可以用任何现有手段生成这个 table ，然后序列化成一个 lua 函数，这个函数可以返回这个 table 。然后你就可以 loadstring 或 loadfile 这个函数了。

谢谢云大，按这种解决了

[tqing1128]

@cloudwu 云风大哥有没有更好的建议

[JieTrancender]

我们的使用方式和上面 @aasdpiao @sniper00 类似。

1. 按服务节点(进程)列出所有需要加载的模块配置
2. 根据渠道加载不同的配置文件并用sharetable共享
3. 服务使用配置时使用sharetable.query获取并在内存缓存(防止伪并发)
4. 热更配置时新起热更服务hotfixd执行耗时的sharetable.loadtable和sharetable.update操作，然后其他服务向该服务获取配置并放入内存缓存
5. 之所以使用sharetable.loadtable没用文档说的loadfile是因为我们是按模块来的，单个模块可能使用多张配置表，我们有中间lua文件整合处理配置

[tqing1128]

使用 fork 并行应该比串行 sharetable.query 好些（未测试）

[sniper00]

使用 fork 并行应该比串行 sharetable.query 好些（未测试）

每个agent的query请求是独立的，并不是串行

[tqing1128]

这是另外的因素了，数据库是可以提高 qps 的

[sniper00]

这是另外的因素了，数据库是可以提高 qps 的

如果有更多核心的测试机 情况应该会好点

[tqing1128]

我启动不加载数据库数据的空 agent 就是忽略掉数据库请求的影响

[zeroatom]

1. agent用法
   1. 一个agent管理多个玩家
   2. 根据分配的cpu数量控制agent数量
   3. 根据业务强度控制agent负载的玩家数量
   4. 周期性启动agent放入分配池，清理老的且无玩家的agent(控制agent总量)
2. sharetable用法
   1. 每个配置表一个key
   2. 使用的业务服务 配置服务主要的key, 业务服务启动准备对外使用时 根据配置的key缓存(所有的key第一次获取时均缓存)
   3. 热更时用法
      a. 基本只热更少量变更表
      b. hotfixd 通过 sharetable.loadfile 更新并控制速度节奏
      c. 数据表源更新完后, 通过shartable通知相关clients，本次热更的所有key, 并控制通知的速度
      d. 业务服务收到热更的key列表时，根据自己需要确定是否需要更新

[tqing1128]

我对 agent 使用方式不同，是一个玩家一个 agent

[tqing1128]

感谢大家的建议，我总结了下：

配置表管理方式：
1、小表多 key
优点：使用灵活，服务按需求初始化使用，更新也比较轻量
缺点：因为一个进程中 sharetable 服务只有一个，如果使用动态启动和释放的服务（如每个玩家一个 agent），在并发启动时，服务数量越多，服务使用的配置表越多，启动的时间越久。

2、大表少 key（极端情况所有配置表一个 key）
优点：服务初始化配置表速度快。
缺点：不适合使用 sharetable.update 热更新

热更新方式：
1、使用 sharetable.query 热更新
优点：热更新到所有服务速度很快，不需要替换数据，也不会引起内存上涨
缺点：使用时要从配置表的 root 进行索引，不可引用到 local 变量使用

2、使用 sharetable.update 热更新
优点：使用更灵活，可以保存配置到 local 变量
缺点：配置中的 table 数量越多，内存上涨越大，替换数据的时间越长。内存上涨是 sharetable.update 中 replace_map 和 resolve_replace() 引起。10w+ table 每个服务上涨 5m 左右内存。如果有数量较多的服务使用一个配置，热更新该配置时，进程内存可能暴涨。

每个玩家一个 agent 代理引起的问题：
1、并发启动 agent 时，因 sharetable 服务中有一个，会形成单点问题
解决：使用 agent pool 提前加载

2、热更新慢
解决：使用小表多 key。因为 sharetable 服务的单点问题，agent 更新会排队，并不会造成进程 CPU 超负载，不放心可控制更新频率。

3、内存可能暴涨
解决：sharetable.update 后 gc

最终我选择，小表多 key 加 sharetable.update 热更新。
选择理由：
1、使用方便，不会发生更新不到的情况。
2、历史原因。
3、热更新配置表频率低，只要不卡死进程，慢点可以接受。

使用方式：
1、每个模块一个 key，小表多 key
2、每个玩家一个 agent 代理，使用 agent pool 提前加载
3、使用一个组播来通知热更新
4、所有服务初始化时必须加载需要使用的配置，保证业务在使用配置时不会挂起（可加一层接口封装实现）
5、服务收到热更新通知时，只更新初始化过的配置
6、sharetable.update 执行后 gc 一次

小表多 key 加 sharetable.query 热更新也是很好的方案，做好不引用到 local 变量使用比 sharetable.update 方式更好。

再次感谢大家的建议。

[haoxianhan]

你改 xxx 的值，在其他服务 loadfile ，然后 你看你 xxx变没

如果不重新执行query是不会变。

我打算使用小表多key，local table1= sharetable.query("table1")，table1作为业务服务下的全局变量给各模块使用，配置有需要更新时，管理进程loadfile后通知每个业务服务重新执行query。请问这种做法会有什么问题么？

[sniper00]

没啥问题，已经上线应用这种方式。 update方式性能太低，5000个agent要卡将近1分钟。

[tqing1128]

你改 xxx 的值，在其他服务 loadfile ，然后 你看你 xxx变没

如果不重新执行query是不会变。

我打算使用小表多key，local table1= sharetable.query("table1")，table1作为业务服务下的全局变量给各模块使用，配置有需要更新时，管理进程loadfile后通知每个业务服务重新执行query。请问这种做法会有什么问题么？

使用的时候通过接口获取，不要在文件头引用到 local 变量中

[zhangshiqian1214]

你改 xxx 的值，在其他服务 loadfile ，然后 你看你 xxx变没

如果不重新执行query是不会变。
我打算使用小表多key，local table1= sharetable.query("table1")，table1作为业务服务下的全局变量给各模块使用，配置有需要更新时，管理进程loadfile后通知每个业务服务重新执行query。请问这种做法会有什么问题么？

使用的时候通过接口获取，不要在文件头引用到 local 变量中

如果使用的时候用sharetable.query取数据，是否会每次取数都会skynet.call一次，是否和把表存在单独的一个服务里，每次skynet.call取数据没什么区别？

[tqing1128]

只有初始化和热更新的时候调用 sharetable.query

[Gowa2017]

。。把 共享表的指针，放到 C 内存，这样就会减少 RPC了，有人这样用过？

[terry8210]

我是类似这样的方式

[powerpeng]

我的用法是这样的，在 preload.lua 中加入

                    local function init()
                        local debug = require "skynet.debug"
                        local sharetable = require "skynet.sharetable"
                        local function reload(...)
                            sharetable.update(...)
                            skynet.ret(skynet.pack(nil))
                        end
                        debug.reg_debugcmd("reload", reload)
                    end
                    skynet.init(init)

在重新载入配置文件时调用

			local srvs = skynet.call(".launcher", "lua", "LIST")
			for k in pairs(srvs) do
				skynet.call(k,"debug","reload",  "table1", "table2", ...)
			end

在各个功能模块初始化时，做一次 sharetable.query 缓存 table 数据的引用.

[tqing1128]

sharetable.update 后建议执行一下 gc

[ImSven]

sharetable.update 后执行一下 gc 确定可以释放掉old_table 吗？ 看云大的博客，共享table 设置了特殊的标记跳过gc 流程了。

[ImSven]

https://blog.codingnow.com/2019/04/share_table.html

[tqing1128]

sharetable.update 后执行一下 gc 确定可以释放掉old_table 吗？ 看云大的博客，共享table 设置了特殊的标记跳过gc 流程了。

gc 的是在 update 过程中的临时 table

[hanxi]

结合 @sniper00 和 @powerpeng 的思路，我在我的 skynet-demo 里实现了一个 sharetable 使用的 demo

1. 使用 sharetable.query 接口更新本地引用
2. 使用 reg_debugcmd 给每个服务注册热更接口

代码位置： https://github.com/hanxi/skynet-demo/blob/master/lualib/staticdata.lua
使用介绍： https://github.com/hanxi/skynet-demo#策划导表配置热更

欢迎试用 😄😄😄

[sniper00]

结合 @sniper00 和 @powerpeng 的思路，我在我的 skynet-demo 里实现了一个 sharetable 使用的 demo

1. 使用 sharetable.query 接口更新本地引用
2. 使用 reg_debugcmd 给每个服务注册热更接口

代码位置： https://github.com/hanxi/skynet-demo/blob/master/lualib/staticdata.lua 使用介绍： https://github.com/hanxi/skynet-demo#策划导表配置热更

欢迎试用 😄😄😄

我们是内存中维护目录文件所有的MD5,需要更表时,对比所有MD5,找出需要更新的文件

[sniper00]

结合 @sniper00 和 @powerpeng 的思路，我在我的 skynet-demo 里实现了一个 sharetable 使用的 demo

1. 使用 sharetable.query 接口更新本地引用
2. 使用 reg_debugcmd 给每个服务注册热更接口

代码位置： https://github.com/hanxi/skynet-demo/blob/master/lualib/staticdata.lua 使用介绍： https://github.com/hanxi/skynet-demo#策划导表配置热更

欢迎试用 😄😄😄

queryall 实现其实也很简单

        local all_ptr = {} --返回这个table即可
        for filename in pairs(files) do
            local _, name = fs.split(filename)
            all_ptr[name] = query_file(source, filename)
        end

[hanxi]

结合 @sniper00 和 @powerpeng 的思路，我在我的 skynet-demo 里实现了一个 sharetable 使用的 demo

1. 使用 sharetable.query 接口更新本地引用
2. 使用 reg_debugcmd 给每个服务注册热更接口

代码位置： https://github.com/hanxi/skynet-demo/blob/master/lualib/staticdata.lua 使用介绍： https://github.com/hanxi/skynet-demo#策划导表配置热更
欢迎试用 😄😄😄

我们是内存中维护目录文件所有的MD5,需要更表时,对比所有MD5,找出需要更新的文件

对比 MD5 值的方案很好，不用另外写一个配置文件了。

[tqing1128]

建议：

1. 把 service2datalist 移除，可以交给配置表层（负责 md5 验证、检查、转表、分组等）
2. 使用 cs 模式（类似 multicast），逻辑更清晰，封装性也会更好

service:
init(key, data) -- 想要批量操作可以用使用数组，数组格式好点，因为可能有按顺序初始化的需求
update(key, data) -- 想要批量可以使用 keys，并且使用数组，因为可能有按顺序更新的需求
-- todo 也可以提供一组只有 key 的，在服务中使用 sharetable.loadfile()

client:
init(key) -- 初始化热更方式：1. debug.reg_debugcmd 2. multicast
preload(key) -- 显式加载数据
get(key) -- 使用数据，不挂起

这样适用范围也更广些，比如枚举也可以用

如果要保留 service2datalist

1. M.loadfiles 函数中可以用 table 参数代替 data.service2datalist, 减少不必要的路径关联
2. sharetable_update 中 arrlist 使用数组，因为可能有按顺序更新的需求

[Scannery]

脑洞一下，不一定行。

考虑提供一个中间层？复制很多的服务类型也就那么几种，中间层保存一个服务名->config的表。
config也是一个table，保存该类服务需要的所有表，的原生指针(matrix:ptr)。
每次agent启动只需要一次skynet.call中间层找到config, 再对每项sharetable.core.clone拆就行

[JieTrancender]

我们是按节点来的，不同用途的节点是加载不同的配置表；使用的时候通用(必需)的走预加载，然后其他的就用时再加载(query的意思)。

[sniper00]

不行，old table可能其它服务在引用 发自我的 iPhone 在 2023年2月9日，21:21，zhangshaobing ***@***.***> 写道：  https://blog.codingnow.com/2019/04/share_table.html — Reply to this email directly, view it on GitHub<#1429 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADDQZK5JWWJ6PLBTVRZXTOTWWTVO5ANCNFSM47G57IQQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ImSven]

核心原因是:old_table 的跳过gc的标记没被恢复掉， 看云大博客的意思不立即恢复的原因也是old_table中有short string 可能被引用。

请问，还有其他共享数据的方案吗？感谢分享！

[zhangshiqian1214]

请教一下，sharetable能否用于频繁更新，比如集群配置更新

[terry8210]

为啥不用etcd zk这类东西呢

[zhangshiqian1214]

不想把etcd和zk集成到skynet，一个简单的中心服就够我用了，想用sharetable只是希望进程的服务能像用配置一样使用集群配置, 现在想想，如果用sharetable做共享，更新的时候还是要通知各个服务update，所以还是给每个服务发消息做同步算了，另外如果5秒钟同步一次服务器集群配置和机器负载，sharetable更新不知道会不会导致内存一直上涨或者更新卡很久的问题

[terry8210]

更新频率不大的情况下，数据量不多，只是配置信息，其实没什么压力的。

[zhangshiqian1214]

每5秒钟同步一次，频率还不大吗？给玩家分配服务时，从内存和cpu中找到最空闲的那个分配给玩家。

local cluster_config = {
    host = "127.0.0.1",
    port = 1234,
    serverId = 1,  --服务器id
    serverType = "game",  --表示进程节点类型
    cpu = 0.35,    --表示cpu35%
    mem = 0.55,   --表示内存55%
}

[cloudwu]

sharetable 无法跨进程。

[zhangshiqian1214]

sharetable 无法跨进程。

用一个center进程做集群管理，sharetable用于各节点进程内配置共享，如果集群规模比较大，配置更新比较频繁，能否用sharetable做进程内的共享

[cloudwu]

是否可以用的依赖因素太多：多频繁，总体数据有多大，查询频率，对查询的要求 ……

易变的状态，建议你先用消息做同步，不要一开始就考虑 共享数据 这种方式。然后再考虑遇到的问题。