年中小结

简单的总结下这半年，新项目开始，需求单不是很多，我主要的工作是做些基础工作支持，负责些英雄技能的开发，线上的问题负责，人物技能的需求，和性能优化，其他的是看些技能/BUFF和移动同步实现等已有的模块；
工作之外，技术这块其实没有大的推进，基本是回顾之前分析过的，再理解下；看了些文章；

一）工作小结
这段时间在做优化相关的工作，这一周处理流量相关的优化，之前已经完善了机器人统计相关的工作，发的上行包和收到的下行包，包量及流量，以及有效载荷。上了机器人压力测试，一场持续两分钟的战斗，发现机器人收到很多广播包，后来估算了下，50人一场的战斗，每分钟大概有16MB的下行流量下来，是很吓人，还有些行为目前机器人暂时没模拟，这部分没统计进来，可能更多；然后对照着统计出的协议相关信息，针对每一个协议，查看是否都是必要字段，以及有些是否都有变化才同步的；因为业务层已经做了一些处理比如定时刷新，因为你在一秒内更新十次，和取最后一次，效果一样的，在客户端那边看来，其他玩家的前几次更新并不是我关心的结果；再然后还有些其他不错的优化方法，准备下周进行优化并压测；这里个人预测流量会降低60%～70%，后续再跟进；

CPU方面的优化，因为在LUA这边没有较完善的工具来很好的定位热点，根据二八原则，但目前看处处都是热点；之前写的C++版本LUA性能分析工具，统计出的结果不是很准确，毕竟统计代码也会占用一定的消耗；目前只进行了一些不必要的计算优化，比如原来查找周围的玩家，筛选时使用两层遍历，接着再遍历一个个处理（由于特殊的业务场景及历史原因，要找出周围有没有敌人，进而能不能释放技能），比如群战50人打架，那么聚集在一起，就是一次释放技能时的判断要扫描2*50+50/2，然后在技能开始具体效果时，又是那么多次...

那这里可以优化成1+50（可能是50+50/2），因为有些逻辑只是判断能不能进行后续动作，找到一个直接return，而这里却要先处理三遍，是不划算的，后被筛选优化成一层，处理时直接先判断上一次的结果是否有效，无效再走原来的逻辑，因为从业务层来看，是等价的；这样从遍历规模上，直接降低50%+；另外，因为有些接口是高频次调用，且存在遍历行为；还有对一些只有玩家的行为进行虚拟化和收发包序列化；至于提升多少，这块后续再测试下；

怎么讲呢，其实知道这里有问题，不该这么写，虽然有更好的方案下，但是个人很难说服去修改其他合理的方案，没办法的；

以上是性能测试的阶段性总结，因为每调整一个参数，都会有不同的性能数据报告，比如改一下配置技能释放次数及检查个数；或者改改配置性能会有一丁点的提升；在稳定性及正确性的前提下，每优化的逻辑，都要进行回归测试及对比；

二）重新review skynet设计
因为使用skynet已经快三年，大部分时间只是用于它作为底层框架，之前也分析过它的源码实现及一些思考；这里再次回顾下它的设计和在使用中遇到的问题，改进他是否可行；

一个service即是一个虚拟机，跟skynet_context绑定，使用handle去grab这个对象，这种设计是有好处的；skynet_context中有重要的比如message_queue及回调callback；service的消息由worker thread调度，从消息的处理上来看，是公平的，不会造成饥饿，但是如果处理此消息的时候，时间过久，那么会饿死其他的消息，比如不小心造成死循环，当然skynet重新写了LUA相关的设计，只要发送个signal给这个service，判断下即可跳出死循环；新创建的service是不会挂到全局队列中的，这样不会造成线程的空调度；如果有消息push到service时，如果之前不在全局队列，则会挂到全局队列中去；

全局队列是由多线程竞争的，但是临界区很小，几个指针的修改；然后竞争到该service后，把他从全局队列中移走，这样防止被其他线程调度，造成消息处理的乱序；接着grab此service并进行引用计数，这里会有读写锁和原子操作；因为此service可能会被其他线程release，所以需要这么做；

接着加spinlock从该service的消息队列头pop一条消息，临界区非常小，因为有其他线程可能会往该service push消息；在dispatch相关的回调函数时，此时已经是串行处理该service了，当然虚拟机service中会有很多的协程；回调结束后，判断是否能pop其他service的消息队列，能的话把之前service的消息队列挂载到全局队列上去，这里也会有次全局竞争；

总的来说，因为充分利用多核且单进程多线程，无法避免有锁的使用，但是并不是说有锁就是性能低，还是要看是否竞争激烈，通过profile来下结论；大部分时候，如果没有玩家的请求消息，service的消息队列是空的，内部基本是定时相关的处理，不会造成消息队列的负载过大；从框架层面考虑，能优化的地方也是有的，但是没必要，如果出现问题，往往是因为上层业务写的有问题，导致影响框架层；

三）七分实力 三分运气
其实自己运气一直不太好，有时候你很认真努力，但看不到期望的结果。

四）计划
目前有空闲时间的话，准备看下LUA的一些设计实现，比如GC，TABLE，目前在使用LUA语言方面，熟悉度还是一般般，虽然大概知道一些设计及怎么使用好，但还是想多看看；还有GO语言；