继上篇《GGTalk 开源即时通讯系统源码剖析之：服务端全局缓存》详细介绍了 GGTalk 对需要频繁查询数据库的数据做了服务端全局缓存处理，以降低数据库的读取压力以及加快客户端请求的响应，接下来我们将进入GGTalk服务端的虚拟数据库。
GGTalk V8.0 除了支持真实的数据库外，还内置了虚拟的数据库，仅仅通过一行配置便可以启动虚拟的数据库，无需部署真实数据库便能体验GGTalk的全部功能。若只是需要做简单的演示，这将极大地简化服务端的部署过程，使得服务端能立即运行起来。
这篇文章将会详细的介绍GGTalk虚拟数据库的设计和实现。还没有GGTalk源码的朋友，可以到 GGTalk源码下载中心 下载。
一. 启用虚拟数据库
为了方便大家能够快速、零成本地将 GGTalk 运行起来，并且体验GGTalk的全部功能，GGTalk服务端在内存中内置了一个虚拟的数据库可以替代真实的数据库以方便测试。接下来将会介绍如何启用虚拟数据库运行GGTalk。
1. 修改服务端配置文件
首先找到 GGTalk.Server 目录下的 App.config 文件。
在 App.config 配置文件中，找到关于UserVirtualDB的配置，将其值修改为true，如上图所示。
2. 启动服务端程序
在修改完服务端配置文件后，启动服务端程序，如此，服务端使用的就是内存中的虚拟数据库。
若能看到这个窗口弹出，则代表服务端程序运行成功。
注意：由于服务端使用的是在内存中模拟出来的虚拟数据库，故服务端退出时，内存将被释放，虚拟数据库中的一切数据都会被清除。
二. 如何做到切换为虚拟数据库
在计算机科学中有一句经典名言：
计算机科学领域内的任何问题，都可以通过增加一个间接的中间层来解决。
在面向对象设计（OOP）中，这句名言所表达的含义通常是通过抽象出一个接口（interface）来完成的。
基于这份了解，为了能切换真实数据库与虚拟数据库，我们将数据库访问层抽象为一个接口 IDBPersister，在服务端所有访问数据库的地方都通过调用 IDBPersister 接口来实现。
真实数据库访问 DBPersister 和虚拟数据库 MemoryPersister 都实现 IDBPersister 接口，这样一来，在程序启动的时候，就可以自由决定是使用 DBPersister 还是 MemoryPersister 了。
三. 虚拟数据库的实现
关于这部分的代码位于
GGTalk/GGTalk.Server/MemoryPersister.cs。
虚拟数据库的设计原理很简单，接下来我们看看其具体是如何实现的。
1. MemoryPersister类
MemoryPersister 类实现了GGTalk服务端中的虚拟数据库，让我们来看看它到底是如何实现的吧。
public class MemoryPersister : OfflineMemoryCache, IDBPersisterExtend {
//...
private ObjectManager<string, GGUser> userManager = new ObjectManager<string, GGUser>();
private ObjectManager<string, GGGroup> groupManager = new ObjectManager<string, GGGroup>();
//string : requesterID + "-" + accepterID
private ObjectManager<string, AddFriendRequest> addFriendRequestManager = new ObjectManager<string, AddFriendRequest>();
//string : requesterID + "-" + groupID
private ObjectManager<string, AddGroupRequest> addGroupRequestManager = new ObjectManager<string, AddGroupRequest>();
//string : groupID + "-" + userID
private ObjectManager<string, GroupBan> groupBanManager = new ObjectManager<string, GroupBan>();
//...
}
以上是就MemoryPersister类的部分定义，也是实现虚拟数据库的核心内容。可以观察到，这个类继承了OfflineMemoryCache类，同时还实现了IDBPersisterExtend接口。OfflineMemoryCache类的作用是用于在内存中存储离线消息和离线文件条目，这个不是本篇文章关注的重点，我们重点来看一下IDBPersisterExtend接口，以下是关于这个接口的定义：
public interface IDBPersisterExtend: IDBPersister<GGUser, GGGroup> {
/// <summary>
/// 根据用户ID获取其手机号
/// </summary>
/// <param name="userID"></param>
/// <returns></returns>
string GetPhone4UserID(string userID);
/// <summary>
/// 更新用户手机号
/// </summary>
/// <param name="userID"></param>
/// <param name="phone"></param>
void UpdateUserPhone(string userID, string phone, int version);
}
我们可以发现，这个接口实现了IDBPersister<GGUser, GGGroup>接口，再分析一下这个接口的命名，我们很容易就知道这个接口仅仅是对IDBPersister接口的一个拓展，因此我们继续分析IDBPersister接口，这个接口定义了大量操作数据库的方法。现在让我们把思绪收回来，也就是说MemoryPersister类最终实现了IDBPersister<GGUser, GGGroup>接口。因此，在MemoryPersister类也将会存在大量操作数据库的方法，如下图所示：
结果很显然，MemoryPersister 类中实现了很多操作数据库的方法，等等，到这里只能说明 MemoryPersister 类仅仅只是实现了IDBPersister<GGUser, GGGroup>接口，仅仅只是约定了方法的名字、方法参数和返回值，内部的实现一定是操作数据库吗？接下来让我们随便点开一个方法看看具体实现：
很容易看出，这是一个更新用户信息的方法，方法接收一系列和用户有关的字段，然后从userManager上调用 Get 方法，似乎返回了一个包含用户信息的对象，类型是 GGUser。然后更新这个对象的信息。很好，现在让我们把关注点放在这个userManager上，明白了它代表什么，那么就能知道这个方法究竟是不是在操作数据库了。来到它的定义的地方：
可以发现，它是MemoryPersister类内部的一个私有字段，类型为ObjectManager<string, GGUser>，ObjectManager 是对 Dictionary 的二次封装，支持多线程安全，相比Dictionary，使用起来也更方便。
到这里，首先我们明白，上述的UpdateUserInfo方法和数据库一点关系都没有。而这个类的作用是将数据存储到内存中，如果你有了解《GGTalk 开源即时通讯系统源码剖析之：服务端全局缓存》的话，你会发现 ObjectManager 也正是实现服务端缓存的那个类。而GGTalk虚拟数据库中的数据也是通过这个类的实例来存储的。
而这里userManager其实就是用来存储用户数据和操作用户数据。一个东西，它既能存储数据，也能操作数据，那这个东西的作用是不是和数据库很类似呢？没错，这正是GGTalk虚拟数据库的设计，将数据存储在内存中，并且定义了一系列能够操作数据的方法（有没有感觉像sql语句）。
现在让我们再来回顾 MemoryPersister 类的定义：
public class MemoryPersister : OfflineMemoryCache, IDBPersisterExtend {
//...
private ObjectManager<string, GGUser> userManager = new ObjectManager<string, GGUser>();
private ObjectManager<string, GGGroup> groupManager = new ObjectManager<string, GGGroup>();
//string : requesterID + "-" + accepterID
private ObjectManager<string, AddFriendRequest> addFriendRequestManager = new ObjectManager<string, AddFriendRequest>();
//string : requesterID + "-" + groupID
private ObjectManager<string, AddGroupRequest> addGroupRequestManager = new ObjectManager<string, AddGroupRequest>();
//string : groupID + "-" + userID
private ObjectManager<string, GroupBan> groupBanManager = new ObjectManager<string, GroupBan>();
//...
}
在了解GGTalk虚拟数据库的设计后，现在再来看就很清晰了，各个字段的作用如下所示：
userManager：用于管理用户数据的实例对象，内含数据和操作数据的方法；groupManager：用于管理群组数据的实例对象，内含数据和操作数据的方法；addFriendRequestManager：用于管理添加好友请求数据的实例对象，内含数据和操作数据的方法；addGroupRequestManager：用于管理添加群组请求数据的实例对象，内含数据和操作数据的方法；groupBanManager：用于管理群组禁言数据的实例对象，内含数据和操作数据的方法。
这些字段便是GGTalk虚拟数据库的核心实现了。
2. 初始化虚拟数据库
在了解完GGTalk虚拟数据库的核心实现后，现在我们来看一看GGTalk虚拟数据库是在哪里进行初始化的：
在MemoryPersister类的构造函数中，我们可以发现，userManager字段中被插入了11个用户的数据，groupManager字段中被插入了两个群组的数据。接下来我们再来到MemoryPersister实例化的地方：
我们分析这段程序，首先定义了一个persister 变量，然后去读取项目的App.config配置文件中的UseVirtualDB 配置，若是为true，则将persister变量赋值为MemoryPersister类的实例。
其实这段程序的意思就是通过读取配置文件来决定是否启用虚拟数据库，而这个 UseVirtualDB配置 则是是否启用虚拟数据库的关键配置，也是文章开头为了启用虚拟数据库而修改的那个配置。到了这里，是不是豁然开朗了呢。
四. 结语
本篇建议结合 GGTalk的源代码 进行阅读，为了方便大家理解GGTalk虚拟数据库的设计思路，本文刻意没有将比较复杂的部分进行展开讲解，同时也是为了控制文章篇幅，例如 MemoryPersister 类中的 messageRecordMemoryCache 字段，此字段的作用是在内存中存储聊天记录，对其有兴趣的可以看看它的设计和实现。最后，希望本篇文章对你有所帮助。
在接下来的一篇我们将介绍GGTalk客户端的全局缓存以及客户端本地存储。
敬请期待：《GGTalk 开源即时通讯系统源码剖析之：客户端全局缓存及本地存储》