网络链接优化在游戏方面主要就是因为有网络攻击还有积分墙等，当时我们有一个网络攻击是山东的一个孩子，他连上断开连上断开，当时网络底层是Net1.5的时候，它断开的处理没有完全释放，是半连接的状态，如果是完全释放就简单了。所以好多网络攻击，就是受到攻击的时候基本上都是自己的逻辑不够缜密。
撞库也是要命的，因为游戏最好获利，撞库之后帐号里有金币什么的就直接卖掉了，现在因为好多库已经被地下卖，每个系统上线的时候尤其是涉及到利益的时候，他撞你的库绝对是为了利益。因为MMO是有分析过，每秒的登录数是你注册人数的8，就是非常稳定的值，比如说数据库里面有一千万个注册用户，每秒登录几千个人很正常，但是突然开始狂飙，数据库开始报警，数据库接口服务器也开始报警，这时候就发现好多人在撞库，现在就只能错IP了，然后就是加验证码。
这是线程的优化，有几个地方会用多线程：一是网络，一次交换收到的消息到处理线程;二是数据库，游戏里面写比读要频繁，所以分成读写锁，而且不能在关键节点存档;三是内部log系统，一次交换到写线程批次写入;四是游戏场景，不同的游戏有不同的操作，有的是多进程有的是多线程，不频繁操作，注意锁定时间。这里面有一个小的技巧，就是线程数要控制，因为我们做压力测试是有机器人的，机器人开太多之后机器人每跑一个，它的效率主要消耗在CPU轮片了，要保存在当前场景然后再切换调度，时间都消耗在那里了，所以线程数目控制在你认为合理的范围内就可以了。
存档数据库优化，因为这个库就相当于咱们银行里的存款，所以这个点的优化大概有几个点：一是缓存存档，我们专门做了一个缓存服务器出来，缓存存档还做了一个队列，队列里面会对存档次数包括它的一些算法保证优先级高的放在存档队列的最前端，让它优先存档，比如定时存档、升级存档是有一些优先级的;二是关键点存档，就是某些动钱的地方，关键的道具升级存档;三是压缩数据，因人而异，因为压缩和解压缩是有效率损失的。存档优化的一个目的就是保证不回档，好多时候有些外部因素是不可避免的，当时我们有一个在上海的，农民盖房子，一爪下去我们的服务器就疯狂报警了;还有按战区分档数据库，类似于，存不了就只能分库，这里主要讲的是思想。
关于内存优化我不重点讲了，内存分配使用我们这边就是每一次内存分配都会记录下来，哪个地方每天分配了多少次，消耗了多少内存，是不是有内存泄漏，对于申请特别频繁的地方就会使用内存池。
我接下来讲一下log系统的优化，因为强调log系统是分析问题的基础，并且这么多年我一直对下面的兄弟对于log的系统是很严格的。比如我们的log有几种，一种是写在数据库里的，直接通过我们的运营分析系统走策略服务器分析出来，一种是写到本地让运维系统去拿，不管哪种，都要在出问题时，第一时间定位出来为什么出问题了;大量log写入，分批次持续写入;log系统分级，控制写入阀值。比如玩家捡到100就不计log1万才记;同步，时间点选择，好多东西其实和研发团队没有关系，它是运维部署上的一些问题，有的运维会在晚上几点钟的时候把数据同步走，比如说备份或者进行其它的操作，如果要和产品进行沟通，会有活动或者再进行操作，或者是一些比较费的事情造成卡，当时运维在3点会有一个log的提取进行备份，然后程序那边认为凌晨3点没有人，会跑自己的一些东西，所以这个其实是一些沟通的问题，和优化没有关系。
调用第三方API优化，不要因为第三方影响你的系统。当时我们和马来西亚合作，他的API不稳定，一方面他的网络不太好，另一方面就是他动的时候不告诉你，但是我们的监控会自个儿监控出来。比如，我调这个API出来的时候预计有700到1000毫秒一个值就回来了，结果突然就暴到5000秒，结果发现是他们在调API的接口，所以对他们的接口还是要有一些log的记录。所以说尽量以一种不信任他们的态度去做咱们的系统，比方说第三方的一些超时、失败都要统计出来。
和业务上配合的优化，咱们的开发或者说咱们的架构是和业务相互促进的，好多时候其实它就到了一个极限值了，每一个计算机绝对有一个极限值，要突破这个极限值，好多时候就是一个业务上的调整了。比如游戏里面有一个叫做虚假繁荣点的设定，就是做假的，让玩家觉得人多，这属于一个不算是投机取巧，只能说是一个核心业务上配合的优化，不可能说计算机系统就一直把它优化到最牛，当然这不是跟产品的兄弟扯皮，能做的咱们尽量做，当达到一个极限的时候，或者有更好解决的时候，和业务上的优化是可以想一想的。活动修改，错峰进行，在游戏中有很多活动，包括网站上也有很多活动，比如打折、优惠券，比如我抢个7，抢7的时候如果这个活动跟你同时进行，再发个2000块钱的优惠券，这个时候网站就把数据飙起来了，当然这你可能错一下，从业务上就把这个东西解决了。
这里是与其它互联网产品一些互通性的思考，我特意加的一个东西，因为我是做游戏的，虽然做了十多年游戏，但是隔行如隔山，我始终认为性能大会上可能做互联网和移动互联网的比较多。我觉得高性能的设计是一种意识，而不单单是功能上的实现，就是说做的时候就想到了，我会算出来能承载多少人，IO是多少，CPU是多少，内存使用是多少，而不是说出了问题之后再优化。架构上设计的高效和可扩展性是基础，如果开始的时候没有想到扩展，上线的时候产品变化非常快，如果扩展性不强，加班熬夜就是咱们的常态。
所以，我想了一个东西叫做利用流程规避现在的风险。我这边做了一些流程，比如说设计文档，在每一个系统做的时候，任何一个小的系统我都会让下面的人写设计文档，设计文档其实是让大家输入自己的思路，我这边有一个模板，把这些模板做了，设计的承载、内存、网络、IO、数据操作频率都会考虑，我想用流程保证一个新入职的程序员写了这个东西他会考虑系统上线之后的效果。举个例子，当时我们有一个程序员其实还算比较可以的，写帮会系统，当时帮会系统是没有任何问题的，开始运行的时候也没有问题，但运行了一个多月的时候出问题了，玩家上线的时候点开帮派NPC瞬间掉线。当时那个帮会的数据容量大到一个程度，就是点击的时候瞬间会发送2-的数据包，socket底层缓存瞬间增满，然后网络层就把他踢掉了，这个时候他没有想这块承载需要多少个帮会，比如设计一千个帮会或者一万个帮会，一个帮会占多少内存？那这个帮会要往下刷新的时候会有多少的网络包往下发，这个时候如果把文档写完了就会规避这个问题，所以我说用流程规避风险。
然后是过程监督，虽然设计文档已经足够细化，你把模板做得足够的细，你要关心的那些点，比如说调数据库请求有一个事务操作，你就告诉他每秒请求多少次，你在什么时候的极限值是多少，超过这个极限值你是不是写log，你把这个都给规划出来之后，这个系统就不会把整个系统拖死掉，这是一个思想上的东西，我觉得这个思想可能各个行业用到，不光是游戏里面。
然后就是定期利用一些分析工具去诊断效率问题。我们有一个管理配置小组，它有两个职责，一是规范、优化流程，开发和发布都会定期发布一些新的工具或者想办法优化一下，这个时候就会定期利用诊断工具诊断这个效率，我们现在是每两周跑一次，每发布版本跑一次。说到这可以再扩展一下，不光是效率的问题，我们还有一些静态的代码分析工具和动态代码分析工具都可以定期去跑。跑完之后最起码我们的内存泄露包括一些空指针，一些非法的引用都可以规避掉，所以我感觉这也是一种思想。
真实的外网测试环境，这个是什么意思？有的东西不到外网是看不出来的，好多差距就是网络差距。现在好多测试公司会在全国各地给你布网，去测你在某个节点的反馈是多少，我们2006年的时候写了一个网络引擎，在内网测没有任何问题，5000人在线，在内网来回大概心跳包的数值在30个毫秒。然后就上到外网去了，外网一压是600，怎么回事？分析半天最后发现在外网握手时要有一些确认值，因为网络差异会让包的确认时长非常长。不过现在中国的网络已经好多了，我们跟柬埔寨有合作，跟缅甸那边都有合作，柬埔寨维护的产品兄弟提前给我们发邮件说我们明天全国断网，所以中国的网络确实已经好很多了。
这个是log系统，我对log一直比较看重，因为log确实是分析问题的最后一个办法，因为它不像网站可以随时更新，可以调，服务器流程比较长，经过的部门也比较多，所以我们这边设置一些log等级。比如，实时记录log的等级，包括分、分功能的统一分析，比如说道具的获取、金钱的获取、升级。再一个是峰值、均值、执行次数等统计，我觉得log凡是能想到的都把它记下来，因为你会有用到的那一天。还有特殊性指定记录，某特定行为等。所以说系统的log是我特别看重的点，我不知道在座的是怎么想的，这是我的心得。
灵活可控的开关系统和配置文件。随时指定某个模块开放或关闭，因为游戏是实时运行的，比如三千个玩家在线是不能把游戏关掉然后上传新的版本启动的，这个时候对于一些不重要的系统，比如邮件或者聊天就关掉。当时有一个非常简单的小bug，就是序列化的问题，一个邯郸的玩家在全服聊天，他利用道具的bug，一点所有的客户端全部掉线，他就跟我们说我要炸服，他这话是周四说的，我们周六已经预定了两百万的广告要推广了，我们给玩家打电话问他怎么弄的，他说就是聊天，但是非常简单，我直接就在服务器上把聊天功能关掉了。
随时控制物品的产生，可能现在和咱们这个确实不太搭，随时控制物品的产生，什么意思？比如说咱们有一些抽奖，会控制一个物品产生的概率，因为原来比如说概率是十万分之一，结果少了一个零，变成了万分之一，所以说拿个开关把他控制一下把他关掉，这个东西就不许出。当你做产品做到高级别的时候，你会发现自己不光是技术，绝对和业务相关。
随时控制任务ID的完成和接取，他用任务的原因就是他有利益，任何玩家去的某一个漏洞的时候都是因为利益，不光是网站或者说移动互联网，原来咱们有刷任务，刷金币，就是把任务完成之后通过NCP转一圈再刷金币，这个时候怎么办？就把任务关掉，不能维护服务器，维护服务器成本太高。
虽然是跨行业，但是不知道大家有什么想了解的可以聊一聊，确实十多年，不论是做程序还是做技术还是做管理，有什么想问的都可以聊一下。
Q&A
Q1：因为你一直在强调写log，大量写log对应用的性能其实会有一些影响，尤其游戏里面影响可能更大，在这个里面你们是怎么平衡的？
田博辉：是这样，写log的时候确实流量会比较大，我大概每天会有40G的log，第一我会把log分级，会写重要级的log，最严重级的log，严重级的log，警告级的log，会根据不同级别写下来。然后还有事务级的log和系统级log，事务级的log比如掉了一万块钱的金币，我可能只记两万的，这个一万的就不记。然后我们在每个道具身上会有一个道具估值，当道具估值低于阀值也不会记log，有一些任务log也会有一些估值，log系统我们也有开关，比如log量太大了我们可能把log关闭掉，现在我们这边log是单独有一台服务器来做的，现在的方式暂时没有出问题，因为log发的时候确实有一些性能损失，但是没有想的那么多。
Q2：其实我比较关心的不是性能，而是你说的逻辑，我比较关心逻辑这方
