-
我想到 2 个方案,目前使用的是方案一。 方案二: |
Beta Was this translation helpful? Give feedback.
Replies: 14 comments 81 replies
-
简单来说就是,配置表是合在一起写入 sharetable 还是分开写入 |
Beta Was this translation helpful? Give feedback.
-
如果你能确保逻辑代码中不保存被共享的table,只是通过sharetable.query到的根对象使用, 可以用sharetable.query来更新,速度会快很多 |
Beta Was this translation helpful? Give feedback.
-
之前我也想问这个问题。说一下我现在的用法共同探讨一下
然后在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 其实我也不知道这样算对不对。 |
Beta Was this translation helpful? Give feedback.
-
@cloudwu 云风大哥有没有更好的建议 |
Beta Was this translation helpful? Give feedback.
-
我们的使用方式和上面 @aasdpiao @sniper00 类似。
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
感谢大家的建议,我总结了下: 配置表管理方式: 2、大表少 key(极端情况所有配置表一个 key) 热更新方式: 2、使用 sharetable.update 热更新 每个玩家一个 agent 代理引起的问题: 2、热更新慢 3、内存可能暴涨 最终我选择,小表多 key 加 sharetable.update 热更新。 使用方式: 小表多 key 加 sharetable.query 热更新也是很好的方案,做好不引用到 local 变量使用比 sharetable.update 方式更好。 再次感谢大家的建议。 |
Beta Was this translation helpful? Give feedback.
-
。。把 共享表的指针,放到 C 内存,这样就会减少 RPC了,有人这样用过? |
Beta Was this translation helpful? Give feedback.
-
我的用法是这样的,在 preload.lua 中加入
在重新载入配置文件时调用
在各个功能模块初始化时,做一次 sharetable.query 缓存 table 数据的引用. |
Beta Was this translation helpful? Give feedback.
-
结合 @sniper00 和 @powerpeng 的思路,我在我的 skynet-demo 里实现了一个 sharetable 使用的 demo
代码位置: https://github.com/hanxi/skynet-demo/blob/master/lualib/staticdata.lua 欢迎试用 😄😄😄 |
Beta Was this translation helpful? Give feedback.
-
脑洞一下,不一定行。 考虑提供一个中间层?复制很多的服务类型也就那么几种,中间层保存一个服务名->config的表。 |
Beta Was this translation helpful? Give feedback.
-
不行,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: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
请教一下,sharetable能否用于频繁更新,比如集群配置更新 |
Beta Was this translation helpful? Give feedback.
-
sharetable 无法跨进程。 |
Beta Was this translation helpful? Give feedback.
感谢大家的建议,我总结了下:
配置表管理方式:
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 更新会排队,并不会造成进程 CP…