4.1 原来的定时器调度机制 * 简单的轮询遍历式定时器： * 在线程循环中，每隔一定的时间间隔，调用一次OnTimer * 在OnTimer中按照管理器、对象、对象的成员等逐层遍历所有OnTimer void ThreadProcess() { while (true): { // do something... // 经过一个周期，触发定时器轮询 if (curTime - lastTime >= 750/*ms*/) { // 遍历所有管理器，调用OnTimer foreach xxxMgr: xxxMgr.OnTimer() } // do something else... } } // 管理器的定时器实现 void

原有日志接口的问题 * 写日志耗时高 * 实时写入文件单行 LOG，耗时约 0.25ms（1KB 以内的 LOG 长度并不会显著的影响写入文件的耗时，固态硬盘和机械硬盘也没有显著的差异） * * 异常时日志丢失 * 缓存型日志，单文件 4K 缓存，可以极大的减少写入文件的开销，但是宕机时，可能导致文件内容丢失 解决方案 * 降低写日志开销 * 异步化 * 防止日志丢失 * 共享内存 具体实现 * 数据结构： typedef struct AsyncLogInfo_s { ASYNC_LOG_OPT_TYPE nOpt; // 操作类型 DWORD dwData2; // 自定义数据 int64_t i64Data1; // 自定义数

从六月份开始开发账号服务器到今天，账号服务器的大体功能也算完善了，账号服务器的开发暂时告一段落，预计下周又回去开发游戏服务端了。 一直想写一篇文章总结一下账号服务器开发过程的经验和教训，迟迟没有时间动笔，今天正好借这个机会写一下。虽然不是什么高大上的东西，但是我们的项目还在运营，另外也有商业秘密的原因，设计到具体实现细节的这里不会描述，也不用来问我，我也没法告诉你。 起因 公司本来已经有了一套比较成熟的账号服务器了，不过一直是端游在用的。而我们是手机游戏，许多需求和端游不同： 1. 手游常常需要接入各个第三方渠道 2. 登录验证方式不同，手游的第三方渠道账号登录以后需要通过HTTP协议到第三方平台进行账号验证 3. 手游有混服登录的需求（即多个第三方渠道的账号登录同一台游戏服务器） 4. 原有账号服务器掌握在别的部门手上，每次功能修改和开发都需要耗费大量时间沟通协调，自己开发维护响应会比较迅速 虽然有这么多需求，早期我们也没打算自己开发账号服务器，而是在游服上直接做，然后用一个数据库对账号进行重新编号排序。这种做法，在内测阶段只有一两台服务器当然没有太大问题

传统死循环问题检测排查的困境 游戏服务端开发维护过程中，经常会碰到死循环或者游服性能问题，此类问题一般存在本机或者QA内部环境极难重现，难以定位和排查的问题。一般能采用的方式，只有： 1. 静态代码审查 2. 在可能出问题或者可能耗时较多的代码部分添加LOG，然后经过测试后上线观察，再加LOG，再观察。 以上这些传统方案不仅定位效率低，准确度低，而且问题的解决周期长，碰到影响恶劣的问题，还可能引起重大项目事故。 本方案解决的问题 1.实现精确到功能点级的故障定位，极大缩短了定位问题的时间。一般故障报出以后，当下查看LOG即可定位到问题所在。 2.实现精确到功能点级的耗时检测，和函数级的LUA脚本函数调用检测，并从时间段累计调用次数，累计调用耗时，单次调用平均耗时等方面综合监测性能问题，检测时间精确到tick。 方案应用后极大的提高外服死循环和性能问题的排查效率，目前已通过该方案查出数个死循环和性能问题。 实现方案 游服的业务驱动，一般来自这么几个部分： 1.