前言在skynet_fly的微服务架构中，数据通常由一个节点的ORM服务管理（例如玩家数据由game节点的orm_agent负责）。但其他节点（如大厅、匹配服务）也经常需要读取这些数据。传统方案有两种： 按需RPC查询 —— 每次需要时远程调用获取数据，延迟高 全量推送 —— 把数据推给所有需要的节点，浪费带宽 orm_frpc_client走的是第三条路：按需订阅 + 增量同步。订阅某个主键

前言之前skynet_fly的定时器是用一个间隔60秒的check循环来实现的，这样做的好处是避免了skynet注册长时间定时器占用lua携程的问题。但随着使用场景的增多，这种实现暴露出了一些不足：1是精度被限制在check间隔内；2是取消操作需要遍历查找；3是大量定时器时check开销增大。所以决定把底层换成经典的分级时间轮（Hierarchical Timing Wheel），对标Linux内

orm_frpc_client.lua用于远程同步和调用其他节点的orm数据，基于watch_client实现增量同步，支持新增、修改、删除回调。 创建与获取 M:new(svr_name, svr_id, orm_entity_instance_name) 描述: 创建远程orm访问对象 参数: - svr_name (string): 远程结点名称 - svr_id (number)

前言之前skynet_fly的subsyn监听同步机制只支持发布和更新，但实际业务中经常会遇到需要取消已发布数据的场景。比如一个玩家下线了，它的状态信息不再有效，需要通知所有监听方”这个数据已经作废了”。之前的做法只能发布一个空数据或者约定一个特殊值表示”无效”，这样不够优雅也不够明确。所以决定给subsyn加上unpubsyn取消同步的能力，让推送端能主动通知所有监听端“数据已取消”，监听端可以

orm_table_client用于同步和调用远程的orm function M:new(svr_name, svr_id, orm_entity_instance_name)描述 创建远程orm访问对象参数 svr_name string 结点名称 svr_id string 结点ID orm_entity_instance_name string orm instacne_name 返回值

优化write_config可填充任意skynet_env参数fix client rpc_server session各服务消化快慢不一，导致session冲突room_game_table_m 增加桌子销毁动作room_game_table_m 增加销毁房间的接口. fix room_game_table_m 应该enter成功后才记录player信息增加方便获取share_config_m

前言因为很多人反馈，frpc API 过于复杂，太绕，不易理解，仔细看看，确实有优化的空间，这里记录下，优化的点，以及更加详细拆解下API的使用。 旧版本API回顾frpc 远程调用是区分了one(简单负载均衡),all(广播)，byid(指定节点ID) 3个模式，API分别对应： one(简单负载均衡)one_balance_sendone_balance_callone_mod_sendon

前言skynet_fly有3种热更。 make/script/check_reload.sh 检测可热更服务新服替代旧服。可以认为是进程内灰度更新。 make/script/check_hotfix.sh 检测可热更服务可热更脚本更新，不会刷旧服务，可以认为是刷脚本。 make/script/upsharedata.sh 检测配置更新，可以认为是更新配置。 之前3种更新方式，可以说是完全独立，

sharedata支持跟hotfix同步更新优化调整frpc的API，使其更易理解fix rpc_pack.pack_push异步后，连接断开，导致报错

前言队列中的处理函数调用call最终调用到进入相同队列的处理函数，就会形成环队列，call调用在等结果，结果处理函数却在call调用处理后面排队，就形成了互相等的队列死机状态。这种状态是非常严重的，整个队列阻塞，后续进队列的还会持续累计，最终可能因内存不足而宕机。发生事故时，我们通常仅仅会认为是内存泄漏导致。因为出现这种情况，日志上不会有什么反应。可能通过debug_console查看stat能够