|
|
代码安全指南:
|
|
|
https://github.com/Tencent/secguide
|
|
|
|
|
|
本地 dns 系统:
|
|
|
https://github.com/mafintosh/dns-discovery
|
|
|
|
|
|
https://github.com/cloudwu/skynet/issues/288
|
|
|
|
|
|
启动服务器流程要理清楚(架构图)
|
|
|
|
|
|
凡是 道具生成都是 一套 掉落系统
|
|
|
|
|
|
分布式 事件系统
|
|
|
|
|
|
属性 同步
|
|
|
|
|
|
aoi 服务 独立处理 做为 大脑来用 它还同时调度 所有 战斗 地图
|
|
|
相关 服务的 分布式 时钟(tick)
|
|
|
|
|
|
aoe 技能的拾取是 一帧内的下一tick 处理 以引用计数来统计
|
|
|
是否已经达到下一步的要求
|
|
|
|
|
|
数据库操作 key 都以 crc16 算法确定链路 而且都是 encode 完再
|
|
|
发到 对应的db 服 这样会减少2次 打包 table的 cpu 开销
|
|
|
玩家以 hash 类型 存储 可以 按 核心 活动 或者其他的 分为 多个 hash 值
|
|
|
这样能保证 key 太多的问题 在 加载的时候 可以 利用 redis pipe 加快访问
|
|
|
并且 数据缓存 需要 按 只查询 和 可读写来划分隔离出来2部分通过
|
|
|
lru 来管理 要不然会把 老数据残留的问题
|
|
|
|
|
|
战斗 都以 buff 来处理
|
|
|
当然不能局限于战斗,本身就是一种设计局限了
|
|
|
抱着这个思想,天然就无法应对策划千奇百怪的需求
|
|
|
就看怎么理解的了. 有的人认为buff是战斗专用的.
|
|
|
但有的人认为buff只是对状态的抽象.
|
|
|
而且传统的组队认证在底层跟用buff基本一样。而且用buff更灵活
|
|
|
人家魔兽世界万物皆技能或Buff 开个门都是buff
|
|
|
https://blog.codingnow.com/2007/11/inertia_thinking.html
|
|
|
|
|
|
逻辑状态在哪 复杂度就在哪边
|
|
|
|
|
|
启动配置 需要 分为 开发 和 发布 两种
|
|
|
|
|
|
|
|
|
- 切换增量GC: `collectgarbage("incremental", pause, stepmul, stepsize)`
|
|
|
- pause 间歇率,垃圾收集器间歇率控制着收集器需要在开启新的循环前要等待多久。 增大这个值会减少收集器的积极性。 当这个值比 100 小的时候，收集器在开启新的循环前不会有等待。 设置这个值为 200 就会让收集器等到总内存使用量达到 之前的两倍时才开始新的循环。
|
|
|
- stepmul 垃圾收集器步进倍率控制着收集器运作速度相对于内存分配速度的倍率。 增大这个值不仅会让收集器更加积极，还会增加每个增量步骤的长度。 不要把这个值设得小于 100 ， 那样的话收集器就工作的太慢了以至于永远都干不完一个循环。 默认值是 200 ，这表示收集器以内存分配的“两倍”速工作。
|
|
|
- stepsize 步长“大小”由 arg 控制。 传入 0 时，收集器步进（不可分割的）一步。 传入非 0 值， 收集器收集相当于 Lua 分配这些多（K 字节）内存的工作。
|
|
|
这三个参数只对 增量 有用
|
|
|
|
|
|
|
|
|
- 切换分代GC: `collectgarbage("generational", minor_multiplier, major_multiplier)`
|
|
|
- minor_multiplier 控制年轻对象收集倍率，对于一个倍率`X`, 新的`minor collection`将会在内存使用比上次`major collection`后增长`X%`时完成. 默认值是20，最大值200
|
|
|
- major_multiplier 控制年老对象收集倍率，对于一个倍率`X`, 新的`major collection`将会在内存使用比上次`major collection`后增长`X%`时完成. 默认值是100，最大值1000
|
|
|
|
|
|
分代GC 是用这两个参数控制
|
|
|
|
|
|
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
|
|
|
|
|
|
Filebeat+Kafka+Logstash+ElasticSearch+Kibana 日志采集方案
|
|
|
|
|
|
- skynet debug console 使用
|
|
|
- https://blog.hanxi.cc/p/73/
|
|
|
|
|
|
玩家有很多情况下都可能掉线，比如3G信号不稳定或者接电话是我们最需要考虑的情况。根据这个情况，划分为临时掉线和彻底掉线。 假设所有掉线都进入临时掉线状态，然后经过指定之间计时后自动进入彻底掉线模式。 彻底掉线后，游戏服务器应该清理掉 {user_id}@{shard}@{gate}@subid:handshakeid:randomkey，若客户端回来则会触发客户端进行Auth阶段认证和Login登录.
|
|
|
|
|
|
如果客户端想重复和游戏服务器建立连接，它不需要再次去登陆服务器登陆。只需要把上次的 handshakeid 递增，并重新生成一个 randomkey ，去和游戏服务器（或者Gate）握手即可。 小于当前handshakeid的请求都不进行处理。
|
|
|
|
|
|
如何判断临时掉线状态发生？玩家心跳超时是玩家掉线的唯一标志！ 玩家主动退出怎么处理？如果客户端有主动退出功能，应该由客户端主动发出logout消息给游戏服务器 |