摘要：
在对游戏进行测试时，发现在某台服务器上，经常会出现一个错误，而其他服务器表现正常，于是分析日志文件，发现以下错误：{badarg,[{erlang,is_process_alive,[<6703.38.0>],[]}检查代码后，发现错误发生在如下的情景下：玩家连接tcpserver，tcpserver产生玩家状态机实例，然后在状态机中rpc call大厅服务，大厅服务保存了当时的玩家状态机pid，之后的操作均会用到这个pid。当进行开启了2个tcpserver（即多用户入口）时，由于使用了is_process_alive来确保pid是可用的，导致这个函数直接报错。erlang在节点 阅读全文
摘要：
最近在使用idea进行一些开发，之前都是在ide里写代码，运行均是手动在shell中，在idea里尝试直接运行，实际上相当于在命令行中使用-run 或-s ，却发现有2个问题。1、使用io:format输出时，和shell中的结果不一样。-s:ddd["1"]shell:ddd12、使用递归函数时，报参数匹配错误{badarith,[{tc,a,1,[{file,"f:/qinyuxi/tset1/src/tc.erl"},{line,13}]}写了一个测试程序检查-module(tc).-export([a/1]).a(10)->10;a(A)- 阅读全文
摘要：
为了验证高并发下gen_server的处理性能，写了一个测试程序，如下：1-module(testserver).23-behaviour(gen_server).4-export([start_link/0]).567-export([init/1,handle_call/3,handle_cast/2,handle_info/2,terminate/2,code_change/3]).89-record(state,{users}).10-record(user,{id,pid}).1112start_link()->13gen_server:start_link({local,?M 阅读全文
摘要：
前面分析的几种情况，归纳一下，其实就是一种，一个提供服务的gen_server，自身处理的时间本来在一个很低的范围内，但由于高并发带来的消息队列，造成处理的时间成几何级数增长，goolge了一下，没找到相关的内容，只能自己做一些细节上的努力。1、gen_server中收到消息后，只进行必要的处理，将广播消息放入新进程中处理，虽然增加了整个游戏的进程数，但这也是erlang的推荐方式，但同时，只能用于一些不需要返回给调用者的处理。2、同步改异步，既然同步调用会超时，那么改为异步请求，你处理好了再给我，这种方式缺点很明显，需要修改大量代码，也会把一些顺序逻辑变成触发式的逻辑，就算付出时间修改好了， 阅读全文
摘要：
最新的一个游戏项目，是一个单服游戏，也即整体游戏只有一个服，也代表着它需要一个高在线，高并发的服务端。游戏本身的结构很像一个棋牌类游戏，拥有大厅、房间等概念，也可以看做类似C9一样的房间内战斗的RPG游戏，玩家选择一个频道（大厅）进入，同在一个频道的玩家才能互相看到以及组队，但不同频道的玩家仍然数据是相通的，可以进行查找、聊天等活动，也有一些所有玩家数据都会参与的计算，比如排行榜之类的。由于是单服，游戏的常规在线人数在2万人左右，虽然Erlang在并发上有天生的优势，但各位先辈们的作品中，似乎还没有人数如此高的在线游戏，接下来就一步步的往这个目标进行努力。 阅读全文
摘要：
经过一段时间开发，大部分功能已经完成，开始了性能测试以及调优，遇到一些性能热点：1、主游戏服务由于每个玩家是单独的状态线程，表现良好，但其中的一个玩家数据管理服务（主要提供查找以及广播）出现了调用超时。2、大厅的数据管理服务（主要提供查找以及动态创建、销毁）出现了调用超时。3、数据服务出现了调用超时。以上测试均在开启了5000个玩家机器人，每秒并发200-300时进行。而超时错误一般都是由于处理速度远低于消息队列形成，而增大超时设置（默认是5秒）是极不推荐的做法，应该从根源上进行分析：1、经过性能分析检查，发现在世界聊天广播时消耗的时间过大， 最大值达到了7秒，而正常测试时，给5000人发一个 阅读全文
摘要：
首先在架构设计上，利用Erlang的特点，采用分布式构成，分为4个节点：数据服务、房间、大厅、主逻辑处理。其中：数据服务：提供对数据库的读写操作。房间：通过一个房间管理器，动态的创建、管理房间。大厅：通过一个大厅管理器，动态的创建、管理大厅。逻辑：也即游戏主服务，socket管理，玩家数据管理。数据库选用了mongodb，主要原因是性能比较高，不需要添加缓存层，还有一个是支持接近sql的查询，目前大多数人都是多年使用关系数据库的经验，这样过渡比直接到key/value型更为适应一些。 阅读全文