海量在线，意味着海量的数据，比如10M的在线人员的个人资料。如果处理呢？依赖数据库可不行，那肯定被拉死了。更可怕的是，所有的数据还必须是实时的。当一个人从地上捡取一个金币的话，那么他的金币总额必然要增加。这个稍微简单点，因为只要在原有数据上加个值就可以了。但是，他要是捡取一个设备时，稍微要复杂点。因为要添加这个设备的部分属性到该角色上。还有更复杂的是，即时战斗中，生命或者魔法值都必须在很短时间内被处理。当一个人中了个火球，一秒钟后才被扣除生命，这个显然是个笑话。

在单一世界中，关于数据的管理，我们首先要将他按变化频率划分为几种类型：

1、活性数据，这种数据要求在很短时间被计算和更新，比如生命值，在战斗的时候，变化频率非常高的。

2、惰性数据，有种数据很少发生改变或者只能在某些情况下发生改变，比如装备。我不知道怎么定义他，所以使用惰性这个化学上概念感觉蛮合适的。

3、持久数据，还有些数据更难发生变化，比如角色名称。

其次，我们将数据的实时性划分为几种类型：

1、即时数据，这种数据在计算时，必要要求马上被得到，比如生命值。

2、延时数据，这种数据一般不参与实时计算，允许延时得到响应，比如好友列表。

3、历史数据，这种数据多数用于审计或者后续计算等，比如充值历史。

从这2大类划分，我们可以得到这么个策略。我们把历史数据、惰性数据、持久数据放入到数据库中，这没有关系。我们把即时数据、延时数据、活性数据放入到内存中。这样就很简单了，不过还有个问题，我们划分的标准是不一样的，持久数据也可能是即时数据，比如角色名，他要随时显示在角色的边上。这意味着，存在交叉情况。1、纯粹的内存数据，比如生命值；不过生命上限必须从数据库中获取。2、纯粹的数据库数据，比如充值历史。没有必要放在内存中，不过计算按时收费是要用的，比如魔兽世界的点数。3、存储在数据库中，但必须拉到内存中，比如名称或者实时点数。

说了一大堆，实际上只为了说明2点，一个是如何管理内存数据，第二个是如何管理数据库到内存的数据。这2个问题本身就复杂，如果放在海量的在线数上就更加的复杂。

我们首先探讨登录过程中，面临的海量个人资料问题，因为角色名称这个数据具有多种特性。既是持久数据，又是即时数据，他需要从数据库直接拉到内存中。当登录时候，需要个人资料，包括角色名称。在登录管理中，我们已经实现了如何分配服务器来负载均衡，这里我们要探讨海量数据的检索架构。

第一，海量数据被存储，导致磁盘阵列或者其他高级的存储架构会被采用。

第二，集群或者分布的方式，在这里是个可行的方案。特定的角色或者用户被按特定的策略被划为到某个IP的服务器上。比如，首先对角色名进行hash，得出一个值，然后存储到到和hash值相匹配的数据库上。当然，还可以更高级的策略，比如GFS等，但这种简单的策略应该是足够了。

第三、内存数据库，和传统方式的数据库，将数据存储在磁盘不同，内存数据库完成将数据存储在内存。10M的在线，需要多少内存呢？以每个在线数1K的内存使用量，那么10M只需要10G的内存，呵呵，好像也不是很大啊。

当数据导入到内存后，刷新完成可以在内存中完成，不过应该注意到，必须保证数据的一致性和故障导致的灾难。如果一台机器突然宕机了，那么内存中的数据将全部丢失，这是个很可怕的灾难。更详细的探讨，请参见我的博客，关于高可用高性能的探讨。

第四、内存数据库的一致性，这个本来是数据库的事情，但由于关系重大，所以要拿出来说。由于海量的数据，导致内存数据库必须具备分布的特性。这有2个问题，必须关注。

1、数据更新的主动通知。数据库必须记录，还有哪些其他数据库引用了本数据库的数据，一旦更新了，显然要通知他们。

2、数据的唯一检索路径。由于一份数据可能分布在多个地方。但关键数据必须只有一个地方是权威的。

1主多从，是通常被采用的处理方法，在这里可能被扩展为多主多从，但原理是一样的。对于某个特定的用户来说，依然是1主多从。我们将关键的逻辑依赖于主数据库，其他的依赖于从数据库。比如，我们更改了名称，那么所有看到该角色的人都同时看到这个角色名称的变更，但其他没有在线或者在其他地方的好友却没有必要马上看到，那么这种延时是可以容忍的。