AE-go_GameServer Player Cache 结构分析 笔记

AE-go_GameServer 是一个开源永恒之塔的模拟服务器项目(服务器端).

抱着之前对游戏数据缓存的问题看了一下对应的Player Cache相关的模块逻辑.

首先要了解一下java 几个特殊的References

网上有很多这类文章:http://blog.csdn.net/xtyyumi301/archive/2008/10/04/3015493.aspx

AE中用了两种引用类型 Weak reference(弱引用)和Soft reference(软引用),

简单的说下以上两种reference的区别:

一旦gc发现对象是weak reference可达就会把它放到ReferenceQueue中，然后等下次gc时回收它；

当对象是Soft reference可达时，gc可能会向操作系统申请更多内存，而不是直接回收它，当实在没辙了才回收它。像cache系统，最适合用Soft reference。

其中player Cache使用的是Soft refernece.

 

接下来就是player Cache的结构:

load

 

PlayerServic

有一个全局的Cache的容器,保存所有在游戏运行中的player对象==CacheMap<Integer,Player>playerCache

PlayerServic.getPlayer()//方法根据playerID和Account(账号信息)填充Player对象并保存到缓存,

对应的在玩家选择角色进入游戏前AionConnection会关联ActivePlayer,这样每个通讯连击都知道为谁服务.

以上都在CM_ENTER_WORLD协议中进行

 

update

 

PlayerService.playerLoggedIn()//设置相关的在线状态,并注册定时任务用于更新回写player的数据

     +Player.onLoggedIn()//向自己的Controller(控制器)添加数据定时回写任务,

ThreadPoolManager//线程池定时任务管理器

 

退出处理

PlayerServic.playerLoggedOut()

    +player.getController().delete();//控制器delete操作会停止所有相关的定时任务(包括数据定时同步的回写)

        +CreatureController.cancelAllTasks()//取消所有定时任务

 

一下是简单的结构类图,仅供参考

 

 

这个缓存结构最有意思的地方在于,使用了java reference其他类型Soft reference(我们通常使用的是strong references),把缓存的回收交给虚拟机去做,不用自己手动清理,从而提高效率.其实很多缓存工具也有用到类似原理.hibernate中就有.

 

但是在其他模块需要拿到Player对象的时候是在World.findPlayer(int objectId)这个接口获取.

有两个容器,FastMap    allObjects和PlayerContainer    allPlayers.

player同时保存在这两个容器中.还有

PlayerContainer//容器中保存了id,player和name,player的映射关系

 

对这样的设计 表示有质疑,多个容器存放相通的对象,要维护多个容器中引用的正确性比较麻烦.事实上AE也这样做了,登录的时候要清除之前容器所保存的对象,关联新对象引用

 

 

等等可能我之前的想法是错误的,playerCache只是用来管理refernece,而world中的 allObjects和allPlayers才是真在和业务相关的容器!