这个月零零碎碎都不知道干了些什么 对接的多
主要做了机器人 测试服务器的 要感谢同事之前的工作 我也是在基础上进行的
mmo 主要瓶颈在于网络处理
机器人模拟玩家进行游戏，主要流程当然是登录选择角色，进入游戏，移动，打怪
，获取装备，穿上装备，跑npc,接任务，完成任务。我们主要的目的是让机器人模拟玩家 跑完主线任务即可
游戏内容模拟玩家方面，完成任务，接收任务，获取装备 这三个走gm命令
打怪 走到怪物附近，在技能范围内 释放技能，给服务器发送各种指令
聊天等同样，从配置文件中获取，取随机发言内容，发到公屏
移动依然采用原来的办法，发送移动指令，收到服务器返回，发送下一步移动
下面主要说下结构。
我的想法是，网络部分，一个机器人一个tcp连接，我们游戏上本来就是一个玩家一个连接，
游戏服务器比如连接500个玩家，那么他维护500条连接，假设玩家是均匀分布在不同的地图，
不同线程，他们也不是同时发送消息比如移动，对这500条连接，用多路复用select epoll
20个线程，500人的话一个多路复用器管理25个连接，某个链接需要读了 需要写了，multiplexor
分配给连接对应的processor进行处理，processor也是20个线程，一个processor负责25个连接的消息处理
这样做，消息处理和消息读取 不在一个线程，目的是不让消息处理阻塞网络并发部分的速度。
游戏服的特点是下发消息非常大，收到来自玩家的消息比较少，下行远大于上行，因为AOI的消息很多
同屏情况下 100个玩家移动一步，服务器收到上行消息100条，但是需要同步下发10000条，每个连接的消息
都给同步给视野内玩家,多路复用器大部分时间是在下发消息
机器人进程
加100个机器人，100条连接，我没有每个连接单独监听，也是使用了select epoll,
但是优势并不大，因为机器人测试，每个连接几乎一直在发送消息，一直活跃，同屏的情况每条连接要收到
更加海量的消息。select epoll适用于连接数很多，活跃百分比较少，这样才能充分体现多路复用的优势
机器人进程，上发给服务器的消息几乎一直有，移动消息几乎一直在发，打怪、跑任务、换装、聊天消息较少，
单连接几乎一致活跃，同时，服务器下发给机器人进程的消息，同屏情况下就非常非常大了。同屏情况下 200个机器人移动打怪，
机器人进程就已经开始卡，游戏服务器也开始出现瓶颈。
机器人逻辑采用简单的状态机，移动，打怪，休息，找任务,机器人逻辑线程默认10个，
线程数目的取舍，多路复用器我用了30个，processor30个，
线程多的时候，切换代价也是非常大的，多了反倒影响性能。
单独一个线程定时读取配置文件，比如更改机器人数目，登出多少机器人，机器人移动到某个地点
打怪，做任务的概率配置等，改变配置文件，改变机器人的群体行为
复用器，处理器，机器人逻辑线程数目，启动时候也从这里读
现在的话，测试方面同屏200人，极限了。我是本地windows服务器测试的，还没在linux上测，
卡的时候也搞不清unity客户端对下发消息处理的问题，还是机器人进程的问题，还是真的游戏服务器扛不住了。
另外模拟真实情况，玩家多地图分布，整体容纳人数还没有进行测试。理论上一个服容纳1000个玩家还是可以的
接下来几天再详细测一下。
之前有一个问题是几十个机器人，进程cpu占用率飙到了100,一直没找到原因，
后来查找发现是多路复用器的线程的占用，为什么它会占CPU这么高，而且和人数无关，有时候几个人就这样了
网上一篇文章提醒了我，select水平触发模式，如果没有收到了消息，没有吧里面的内容recv，就会造成一直触发
想想也确实。select epoll监听socket句柄，内容不从内核拷贝到用户空间，它会一直认为有消息。
那就是消息处理那里的问题，后来发现是接收那里逻辑写的不对，当粘包的时候会造成，下一次消息解析错误。
一般这种几率不大，除非一次服务器下发消息很大，一个包装不下，才会分开两个大包，这样我接收那里没有
处理好，就出现了问题，没有recv出来，导致select一直触发，cpu直接飙到了100，类似没有sleep的死循环
说的挺乱，唉，月初想重头研究下数据结构，学了几天平衡树，插入，删除，红黑树还是没有搞懂，高了一半
想哪一天有时间实现一个stl类似的map。后来有个机器人的需求，项目现在也比较紧张。看以后吧
转载自原文链接, 如需删除请联系管理员。
原文链接：关于测试机器人的记录，转载请注明来源！