游戏服务端开发-一

数据存储服务器

游戏中的数据大致分为静态配置数据和动态的玩家数据。这里主要讨论玩家数据存储的解决方案。

虽然游戏应用的写操作要多于读操作，但是加入缓存层仍然有其必要性。多个应用服务器启动时从数据库读取数据会在瞬间给数据库造成巨大压力，如果将相对静态的数据以文件的形式放在应用服务器本地，可以避免这个问题，但同时带来的另一个问题是静态数据的维护成本增加。

引入静态数据缓存层，避免集中访问对数据库产生的压力，同时方便对数据的维护。数据在被修改后即可通知曾读取过数据的所有的应用服务器。

另一方面，执行一次SQL语句，不论是单个还是批量都一次相当耗时的通信，因为客户端在收到数据库服务器的响应之前程序流是被阻塞的，这是典型的cpu因为等待io而空闲。虽然设计者大可以使用异步线程来执行sql，但异步使用cpu就可以不再精打细算吗？

如果把同步玩家数据由执行sql变为一次应用服务器和数据存储服务器的应用协议通信，情况就会不一样，设计者可以将之设计成异步的，甚至是有问无答的。

缓存玩家数据用以支持同步玩家数据的应用协议，内存永远比磁盘快。此外玩家下线并不会立即将之从缓存中移除，而是将其归入一个离线玩家集合，因为相逢的人会再相逢，离线的人很有可能会短时间内再上线。

 

将玩家分类（登录时线路/门派/性别）缓存，可以缩短查找时间。

 

 

在之前的一个项目中设计思想是玩家数据（属性，物品）有更新发生就会产生一条sql语句，定时地一次性批量执行这些sql。这里有两个值得改进的地方。1对于一个玩家有多个sql，而且这些sql会覆盖上一个sql执行的结果，无谓的加大数据库负担，增大连接占用时间。2如果玩家人数众多，行为多，将在在短时间内大量难以消化的sql，对内存对存储系统的造成隐患。

 

应用程序使用源内存进行业务计算（面向客户端的读写功能），Cache子系统分类管理源内存的句柄（面向数据存储的只读功能）。Cache子系统定时将玩家数据结构做一分快照同步到数据服务器或者当更新的玩家人数达到一个阀值时做及时同步，另凡涉及到玩家交易的数据更新要做同步并留下业务log。

上述设计没有考虑应用服务器的人数负载。如果游戏应用负载很大的话，在定时同步的时间点可能会产生大量难以消化的sql。我们说每隔一定时间会将玩家的数据同步到存储系统，但是没有说所有玩家的数据都在同一时间点进行同步。我们有理由相信玩家在职业上的分布是大体相似的，所以先同步和尚，再同步道士，再同步乞丐，最后解决捕快，也不失是一种解决的方法。

这个思路同时适用于应用服务器和数据存储服务向下层的写入应用。