删除所有 容器和镜像

docker stop $(docker ps -a -q) && docker system prune --all --force

配置中心(apollo)
ELK

代码安全指南:
https://github.com/Tencent/secguide

本地 dns 系统:
https://github.com/mafintosh/dns-discovery

100个gdb小技巧
https://github.com/hellogcc/100-gdb-tips

Modern Unix Command
https://github.com/ibraheemdev/modern-unix

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消息给游戏服务器