前言因为很多人反馈，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，使其更易理解

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

前言使用skynet开发都会启动多个lua服务，如果加上使用远程集群调用的话，服务就更多了，如果被调用方存在多链路，出问题时，无法快速定位问题源头。链接追踪通过给处理添加全局唯一的tag标记，在链路上加上详细的日志，从而达到通过日志快速分析问题的手段。云大为skynet增加过链路追踪，通过使用者主动调用skynet.trace，从而开启一次详细的trace日志。trace_tag是服务地址加递增编

前言因为skynet中单进程写业务也容易遇到异步重入问题，写简单个人系统也得警惕此问题，着实让人难受。索性直接用queue包裹一些执行入口，这样简单个人系统没有跨服的业务根本无需考虑此问题了。 实现方案大厅服的业务函数处理通常以player_id为第一参数用来处理玩家个人系统的数据。我们以player_id来区分不同的队列，这样既可以有效利用skynet多携程优势，又能避免个人系统的重入问题。而对

前言游戏服务器免不了需要记录大量玩家数据变化、玩家操作行为、对局战斗数据等等数据的记录以及后台提供数据的查询入口。我遇到过两种做法。 方案一 手动创建数据表结构。 服务器代码拼接sql调用插入。 后台再根据表结构定义写查询页面。 方案二 服务器先写本地json文件。 再选用某种日志采集方案采集日志。 采集那边也需要定义表结构，然后插入数据库。 后台再根据表结构定义写查询页面。 总的

前言最近有空在给skynet_fly_demo增加用户日志相关，用于记录游戏中产生的日志，比如用户登录登出记录，道具增加，减少记录。我的想法是把用户日志对接上orm，这样写的日志的方便日志服采集后，根据orm设定的字段索引信息直接构建对接数据库的orm，从而实现日志服无需修改就能采集新增或者变更的日志数据。这个过程就遇到一个问题，日志服如何同步到其他服务的日志orm信息。之前的subsyn监听同步

guid_util function M.fly_guid()描述 fly风格GUID参数 返回值 string 32字节的guid

orm支持创建普通索引orm支持普通索引，并提供相关查询和删除函数。普通索引查询是不会走缓存的，直接先查询数据库。 用户日志支持内置按天写入，保留天数支持。 支持批订阅同步。 fix 订阅同步时滚服热更frpc_client_m同步停止问题。解决contriner_client对象使用不活跃导致旧服务长时间不销毁。删除contriner_client:CMD函数 skynet_util.set_c