教你从头写游戏服务器框架（二）

韩大wade 腾讯游戏学院 2019-05-28

关于作者：韩伟，腾讯互娱高级工程师，目前在Next产品中心研发创新类型游戏。

对象序列化

现代编程技术中，面向对象是一个最常见的思想。因此不管是 C++ Java C#，还是 Python JS，都有对象的概念。虽然说面向对象并不是软件开发的“银弹”，但也不失为一种解决复杂逻辑的优秀工具。回到游戏服务器端程序来说，自然我会希望能有一定面向对象方面的支持。所以，从游戏服务器端的整个处理过程来看，我认为，有以下几个地方，是可以用对象来抽象业务数据的：

数据传输

我们可以把通过网络传输的数据，看成是一个对象。这样我们可以简单的构造一个对象，然后直接通过网络收、发它。

数据缓存

一批在内存中的，可以用对象进行“抽象”。而 key-value 的模型也是最常见的数据容器，因此我们可以起码把 key-value 中的 value 作为对象处理。

数据持久化

长久以来，我们使用 SQL 的二维表结构来持久化数据。但是 ORM （对象关系映射）的库一直非常流行，就是想在二维表和对象之间搭起桥梁。现在 NoSQL 的使用越来越常见，其实也是一种 key-value 模型。所以也是可以视为一个存放“对象”的工具。

对象序列化的标准模式也很常见，因此我定义成：

class Serializable {
public:
/**
* 序列化到一个数组中
* @param buffer 目地缓冲区数组
* @param buffer_length 缓冲区长度
* @return 返回写入了 buffer 的数据长度。如果返回 -1 表示出错，比如 buffer_length 不够。
*/
virtual ssize_t SerializeTo(char* buffer, int buffer_length) const = 0;
/**
* @brief 从一个 buffer 中读取 length 个字节，反序列化到本对象。
*@return 返回 0 表示成功，其他值表示出错。
*/
virtual int SerializeFrom(const char* buffer, int length) = 0;
virtual ~Serializable(){}
};

网络传输

有了对象序列化的定义，就可以从网络传输处使用了。因此专门在 Processor 层设计一个收发对象的处理器 ObjectProcessor，它可以接纳一种 ObjectHandler 的对象注册。这个对象根据注册的 Service 名字，负责把收发的接口从 Request, Response 里面的字节数组转换成对象，然后处理。

// ObjectProcessor 定义
class ObjectProcessor : public ProcessorHelper {
public:
ObjectProcessor();
virtual ~ObjectProcessor();
// 继承自 Processor 处理器函数
virtual int Init(Server* server, Config* config = NULL);
// 继承自 Processor 的处理函数
virtual int Process(const Request& request, const Peer& peer);
virtual int Process(const Request& request, const Peer& peer, Server* server);
///@brief 设置默认处理器，所有没有注册具体服务名字的消息都会用这个消息处理
inline void set_default_handler(ObjectHandler* default_handler) {
default_handler_ = default_handler;
}
/**
* @brief 针对 service_name，注册对应处理的 handler ，注意 handler 本身是带对象类型信息的。
* @param service_name 服务名字，通过 Request.service 传输
* @param handler 请求的处理对象
*/
void Register(const std::string& service_name, ObjectHandler* handler);
/**
* @brief 使用 handler 自己的 GetName() 返回值，注册服务。
* 如果 handler->GetName() 返回 "" 字符串，则会替换默认处理器对象
* @param handler 服务处理对象。
*/
void Register(ObjectHandler* handler);
///@brief 关闭此服务
virtual int Close();
private:
std::map<std::string, ObjectHandler*> handler_table_;
Config* config_;
ObjectHandler* default_handler_;
int ProcessBy(const Request& request, const Peer& peer,
ObjectHandler* handler, Server* server = NULL);
int DefaultProcess(const Request& request, const Peer& peer, Server* server = NULL);
bool InitHandler(ObjectHandler* handler);
};
// ObjectHandler 定义
class ObjectHandler : public Serializable, public Updateable {
public:
ObjectHandler();
virtual ~ObjectHandler() ;
virtual void ProcessRequest(const Peer& peer);
virtual void ProcessRequest(const Peer& peer, Server* server);
/**
* DenOS 用此方法确定进行服务注册，你应该覆盖此方法。
* 默认名字为空，会注册为“默认服务”，就是所有找不到对应名字服务的请求，都会转发给此对象处理。
* @return 注册此服务的名字。在 Request.service 字段中传输。
*/
virtual std::string GetName() ;
int Reply(const char* buffer, int length, const Peer& peer,
const std::string& service_name = "", Server* server = NULL) ;
int Inform(char* buffer, int length, const std::string& session_id,
const std::string& service_name, Server* server = NULL);
int Inform(char* buffer, int length, const Peer& peer,
const std::string& service_name = "", Server* server = NULL);
virtual int Init(Server* server, Config* config);
/**
* 如果需要在主循环中进行操作，可以实现此方法。
* 返回值小于 0 的话，此任务会被移除循环
*/
virtual int Update() {
return 0;
}
protected:
Server* server_;
std::map<int, MessageHeader> header_map_;
Response response_;
Notice notice_;
};

由于我们对于可序列化的对象，要求一定要实现 Serializable 这个接口，所以所有需要收发的数据，都要定义一个类来实现这个接口。但是，这种强迫用户一定要实现某个接口的方式，可能会不够友好，因为针对业务逻辑设计的类，加上一个这种接口，会比较繁琐。为了解决这种问题，我利用 C++ 的模板功能，对于那些不想去实现 Serializable 的类型，使用一个额外的 Pack()/Upack() 模板方法，来插入具体的序列化和反序列化方法（定义 ObjectHandlerCast 模板）。这样除了可以减少实现类型的代码，还可以让接受消息处理的接口方法 ProcessObject() 直接获得对应的类型指针，而不是通过 Serializable 来强行转换。在这里，其实也有另外一个思路，就是把 Serializable 设计成一个模板类，也是可以减少强制类型转换。但是我考虑到，序列化和反序列化，以及处理业务对象，都是使用同样一个（或两个，一个输入一个输出）模板类型参数，不如直接统一到一个类型里面好了。

// ObjectHandlerCast 模板定义
/**
* 用户继承这个模板的实例化类型，可以节省关于对象序列化的编写代码。
* 直接编写开发业务逻辑的函数。
*/
template<typename REQ, typename RES = REQ>
class ObjectHandlerCast : public ObjectHandler {
public:
ObjectHandlerCast()
: req_obj_(NULL),
res_obj_(NULL),
buffer_(NULL) {
buffer_ = new char[Message::MAX_MAESSAGE_LENGTH];
bzero(buffer_, Message::MAX_MAESSAGE_LENGTH);
}
virtual ~ObjectHandlerCast() {
delete[] buffer_;
}
/**
* 对于不想使用 obj_ 成员来实现 Serializable 接口的，可以实现此接口
*/
virtual int Pack(char* buffer, int length, const RES& object) const {
return -1;
}
virtual int Unpack(const char* buffer, int length, REQ* object) {
return -1;
}
int ReplyObject(const RES& object, const Peer& peer,
const std::string& service_name = "") {
res_obj_ = &object;
int len = SerializeTo(buffer_, Message::MAX_MAESSAGE_LENGTH);
if (len < 0)
return -1;
return Reply(buffer_, len, peer, service_name);
}
int InformObject(const std::string& session_id, const RES& object,
const std::string& service_name) {
res_obj_ = &object;
int len = SerializeTo(buffer_, Message::MAX_MAESSAGE_LENGTH);
if (len < 0)
return -1;
return Inform(buffer_, len, session_id, service_name);
}
virtual void ProcessRequest(const Peer& peer, Server* server) {
REQ* obj = req_obj_;
ProcessObject(*obj, peer, server);
delete obj;
req_obj_ = NULL;
}
virtual void ProcessObject(const REQ& object, const Peer& peer) {
ERROR_LOG("This object have no process handler.");
}
virtual void ProcessObject(const REQ& object, const Peer& peer,
Server* server) {
ProcessObject(object, peer);
}
protected:
REQ* req_obj_;
const RES* res_obj_;
private:
char* buffer_;
virtual ssize_t SerializeTo(char* buffer, int buffer_length) const {
ssize_t ret = 0;
ret = Pack(buffer, buffer_length, *res_obj_);
return ret;
}
virtual int SerializeFrom(const char* buffer, int length) {
req_obj_ = new REQ(); // 新建一个对象，为了协程中不被别的协程篡改
int ret = Unpack(buffer, length, req_obj_);
if (ret) {
delete req_obj_;
req_obj_ = NULL;
}
return ret;
}
};

任何类型的对象，如果想要在这个框架中以网络收发，只要为他写一个模板，完成 Pack() 和 UnPack() 这两个方法，就完成了。看起来确实方便。（如果想节省注册的时候编写其“类名”，还需要完成一个简单的 GetName() 方法）

当我完成上面的设计，不禁赞叹 C++ 对于模板支持的好处。由于模板可以在编译时绑定，只要是具备“预设”的方法的任何类型，都可以自动生成一个符合既有继承结构的类。这对于框架设计来说，是一个巨大的便利。而且编译时绑定也把可能出现的类型错误，暴露在编译期。对比那些可以通过反射实现同样功能的技术，其实是更容易修正的问题。

缓冲和持久化

数据传输的对象序列化问题解决后，下来就是缓存和持久化。由于缓存和持久化，我的设计都是基于 Map 接口的，也就是一种 Key-Value 的方式，所以就没有设计模板，而是希望用户自己去实现 Serializable 接口。但是我也实现了最常用的几种可序列化对象的实现代码：

固定长度的类型，比如 int 。序列化其实就是一个 memcpy() 而已。
std::string 字符串。这个需要使用 c_str() 变成一个字节数组。
JSON 格式串。使用了某个开源的 json 解析器。推荐 GITHUB 上的 Tencent/RapidJson。

数据缓冲

数据缓冲这个需求，虽然在互联网领域非常常见，但是游戏的缓冲和其他一些领域的缓冲，实际需求是有非常大的差别。这里的差别主要有：

游戏的缓冲要求延迟极低，而且需要对服务器性能占用极少，因为游戏运行过程中，会有非常非常频繁的缓冲读写操作。举个例子来说，一个“群体伤害”的技能，可能会涉及对几十上百个数据对象的修改。而且这个操作可能会以每秒几百上千次的频率请求服务器。如果我们以传统的 memcache 方式来建立缓冲，这么高频率的网络 IO 往往不能满足延迟的要求，而且非常容易导致服务器过载。

游戏的缓冲数据之间的关联性非常强。和一张张互不关联的订单，或者一条条浏览结果不一样。游戏缓冲中往往存放着一个完整的虚拟世界的描述。比如一个地区中有几个房间，每个房间里面有不通的角色，角色身上又有各种状态和道具。而角色会在不同的房间里切换，道具也经常在不同角色身上转移。这种复杂的关系会导致一个游戏操作，带来的是多个数据的同时修改。如果我们把数据分割放在多个不同的进程上，这种关联性的修改可能会让进程间通信发生严重的过载。

游戏的缓冲数据的安全性具有一个明显的特点：更新时间越短，变换频率越大的数据，安全性要求越低。这对于简化数据缓冲安全性涉及，非常具有价值。我们不需要过于追求缓冲的“一致性”和“时效”，对于一些异常情况下的“脏”数据丢失，游戏领域的忍耐程度往往比较高。只要我们能保证最终一致性，甚至丢失一定程度以内的数据，都是可以接受的。这给了我们不挑战 CAP 定律的情况下，设计分布式缓冲系统的机会。

基本模型

基于上面的分析，我首先希望是建立一个足够简单的缓冲使用模型，那就是 Map 模型。

class DataMap : public Updateable {
public:
DataMap();
virtual ~DataMap();
/**
* @brief 对于可能阻塞的异步操作，需要调用这个接口来驱动回调。
*/
virtual int Update(){ return 0; }
/**
* @brief 获取 key 对应的数据。
* @param key 数据的 Key
* @param value_buf 是输出缓冲区指针
* @param value_buf_len 是缓冲区最大长度
* @return 返回 -1 表示找不到这个 key，返回 -2 表示 value_buf_len 太小，不足以读出数据。其他负数表示错误，返回 >= 0 的值表示 value 的长度
*/
virtual int Get(const std::string& key, char* value_buf, int value_buf_len) = 0;
virtual int Get(const std::string& key, Serializable* value);
/**
* @brief 异步 Get 的接口
* @param key 获取数据的 Key
* @param callback 获取数据的回调对象，如果 key 不存在， FetchData() 参数 value_buf 会为 NULL
* @return 返回 0 表示发起查询成功，其他值表示错误。
*/
virtual int Get(const std::string& key, DataMapCallback* callback) = 0;
/**
* @brief 覆盖、写入key对应的缓冲数据。
* @return 成功返回0。返回 -1 表示value数据太大，其他负数表示其他错误
*/
virtual int Put(const std::string& key, const char* value_buf, int value_buf_len) = 0;
virtual int Put(const std::string& key, const Serializable& value);
/**
* 写入数据的异步接口，使用 callback 来通知写入结果
* @param key 数据 key
* @param value 数据 Value
* @param callback 写入结果会调用此对象的 PutResult() 方法
* @return 返回 0 表示准备操作成功
*/
virtual int Put(const std::string& key, const Serializable& value, DataMapCallback* callback);
virtual int Put(const std::string& key, const char* value_buf, int value_buf_len, DataMapCallback* callback);
/**
* 删除 key 对应的数据
* @return 返回 0 表示成功删除，返回 -1 表示这个 key 本身就不存在，其他负数返回值表示其他错误。
*/
virtual int Remove(const std::string& key) = 0;
virtual int Remove(const std::string&key, DataMapCallback* callback);
/**
* 是否有 Key 对应的数据
*@return 返回 key 值表示找到，0 表示找不到
*/
virtual int ContainsKey(const std::string& key) = 0;
/**
* 异步 ContainsKey 接口，如果 key 不存在， FetchData() 参数 value_buf 会为 NULL。
* 如果 key 存在，value_buf 则不为NULL，但也不保证指向任何可用数据。可能是目标数值，
* 也可能内部的某个空缓冲区。如果是在本地的数据，就会是目标数据，如果是远程的数据，
* 为了减少性能就不会传入具体的 value 数值。
*/
virtual int ContainsKey(const std::string& key, DataMapCallback* callback) = 0;
/**
* 遍历整个缓存。
* @param callback 每条记录都会调用 callback 对象的 FetchData() 方法
* @return 返回 0 表示成功，其他表示错误。
*/
virtual int GetAll(DataMapCallback* callback) = 0;
/**
* 获取整个缓存的数据
* @param result 结果会放在这个 map 里面，记得每条记录中的 Bytes 的 buffer_ptr 需要 delete[]
* @return 返回 0 表示成功，其他表示错误
*/
virtual int GetAll(std::map<std::string, Bytes>* result);
private:
char* tmp_buffer_;
};

这个接口其实只是一个 std::map 的简单模仿，把 key 固定成 string ，而把 value 固定成一个 buffer 或者是一个可序列化对象。另外为了实现分布式的缓冲，所有的接口都增加了回调接口。

可以用来充当数据缓存的业界方案其实非常多，他们包括：

堆内存，这个是最简单的缓存容器
Redis
Memcached
ZooKeeper 这个自带了和进程关联的数据管理

由于我希望这个框架，可以让程序自由的选用不同的缓冲存储“设备”，比如在测试的时候，可以不按照任何其他软件，直接用自己的内存做缓冲，而在运营或者其他情况下，可以使用 Redis 或其他的设备。所以我们可以编写代码来实现上面的 DataMap 接口，以实现不同的缓冲存储方案。当然必须要把最简单的，使用堆内存的实现完成： RamMap

分布式设计

如果作为一个仅仅在“本地”服务器使用的缓冲，上面的 DataMap 已经足够了，但是我希望缓存是可以分布式的。不过，并不是任何的数据，都需要分布式存储，因为这会带来更多延迟和服务器负载。因此我希望设计一个接口，可以在使用时指定是否使用分布式存储，并且指定分布式存储的模式。

根据经验，在游戏领域中，分布式存储一般有以下几种模式：

本地模式

如果是分区分服的游戏，数据缓存全部放在一个地方即可。或者我们可以用一个 Redis 作为缓存存储点，然后多个游戏服务进程共同访问它。总之对于数据全部都缓存在一个地方的，都可以叫做本地模式。这也是最简单的缓冲模式。

按数据类型分布

这种模式和“本地模式”的差别，仅仅在于数据内容不同，就放在不同的地方。比如我们可以所有的场景数据放在一个 Redis 里面，然后把角色数据放在另外一个 Redis 里面。这种分布节点的选择是固定，仅仅根据数据类型来决定。这是为了减缓某一个缓冲节点的压力而设计。或者你对不同数据有缓冲隔离的需求：比如我不希望对用户的缓冲请求负载，影响对支付服务的缓冲请求负载。

按数据的 Key 分布

这是最复杂也最有价值的一种分布式缓存。因为缓冲模式是按照 Key-Vaule 的方式来存放的，所以我们可以把不同的 Key 的数据分布到不同节点上。如果刚好对应的 Key 数据，是分布在“本地”的，那么我们将获得本地操作的性能！这种缓冲

按复制分布

就是多个节点间的数据一摸一样，在修改数据的时候，会广播到所有节点，这种是典型的读多写少性能好的模型。

在游戏开发中，我们往往习惯于把进程，按游戏所需要的数据来分布。比如我们会按照用户 ID ，把用户的状态数据，分布到不同的机器上，在登录的时候，就按照用户 ID 去引导客户端，直接连接到对应的服务器进程处。或者我们会把每个战斗副本或者游戏房间，放在不同的服务器上，所有的战斗操作请求，都会转发到对应的存放其副本、房间数据的服务器上。在这种开发中，我们会需要把大量的数据包路由、转发代码耦合到业务代码中。

如果我们按照上面的第 3 种模型，就可以把按“用户ID”或者“房间ID”分布的事情，交给底层缓冲模块去处理。当然如果仅仅这样做，也许会有大量的跨进程通信，导致性能下降。但是我们还可以增加一个“本地二级缓存”的设计，来提高性能。具体的流程大概为：

1.取 key 在本地二级缓存（一般是 RamMap）中读写数据。如果没有则从远端读取数据建立缓存，并在远端增加一条“二级缓存记录”。此记录包含了二级所在的服务器地址。

2.按 key 计算写入远端数据。根据“二级缓存记录”广播“清理二级缓存”的消息。此广播会忽略掉刚写入远端数据的那个服务节点。（此行为是异步的）

只要不是频繁的在不同的节点上写入同一个 Key 的记录，那么二级缓存的生存周期会足够长，从而提供足够好的性能。当然这种模式在同时多个写入记录时，有可能出现脏数据丢失或者覆盖，但可以再添加上乐观锁设计来防止。不过对于一般游戏业务，我们在 Key 的设计上，就应该尽量避免这种情况：如果涉及非常重要的，多个用户都可能修改的数据，应该避免使用“二级缓存”功能的模型 3 缓存，而是尽量利用服务器间通信，把请求集中转发到数据所在节点，以模式 1 （本地模式）使用缓冲。

以下为分布式设计的缓冲接口：

/**
* 定义几种网络缓冲模型
*/
enum CacheType {
TypeLocal, ///< 本地
TypeName, ///< 按 Cache 名字分布
TypeKey, ///< 先按 Cache 名字分布，再按数据的 key 分布
TypeCopy ///< 复制型分布
};
/**
* @brief 定义了分布式缓存对象的基本结构
*/
class Cache : public DataMap {
public:
/**
* @brief 连接集群。
* @return 返回是否连接成功。
*/
static bool EnsureCluster(Config* config = NULL);
/**
* 获得一个 Cache 对象。
* @attention 如果第一次调用此函数时，输入的 type, local_data_map 会成为这个 Cache 的固定属性，以后只要是 name 对的上，都会是同一个 Cache 对象。
* @param name 为名字
* @param type 此缓存希望是哪种类型
* @param local_data_map 为本地存放的数据容器。
* @return 如果是 NULL 表示已经达到 Cache 数量的上限。
*/
static Cache* GetCache(const std::string& name, CacheType type,
DataMap* local_data_map);
/**
* 获得一个 Cache 对象。
* @param name 为名字
* @param local_data_map 为本地存放的数据容器。
* @note 如果第一次调用此函数时，输入的 type, class M 会成为这个 Cache 的固定属性，以后只要是 name 对的上，都会是同一个 Cache 对象。
* @return 如果是 NULL 表示已经达到 Cache 数量的上限。
*/
template<class M>
static Cache* GetCache(const std::string& name, CacheType type,
int* data_map_arg1 = NULL) {
DataMap* local_data_map = NULL;
std::map<std::string, DataMap*>::iterator it = cache_store_.find(name);
if (it != cache_store_.end()) {
local_data_map = it->second;
} else {
if (data_map_arg1 != NULL) {
local_data_map = new M(*data_map_arg1);
} else {
local_data_map = new M();
}
cache_store_[name] = local_data_map;
}
return GetCache(name, type, local_data_map);
}
/**
* 删除掉本进程内存放的 Cache
*/
static void RemoveCache(const std::string& name);
explicit Cache(const std::string& name);
virtual ~Cache();
virtual std::string GetName() const;
protected:
static std::map<std::string, Cache*> cache_map_;
std::string name_;
private:
static int MAX_CACHE_NUM;
static std::map<std::string, DataMap*> cache_store_;
};

持久化

长久以来，互联网的应用会使用类似 MySQL 这一类 SQL 数据库来存储数据。当然也有很多游戏是使用 SQL 数据库的，后来业界也出现“数据连接层”（DAL）的设计，其目的就是当需要更换不同的数据库时，可以不需要修改大量的代码。但是这种设计，依然是基于 SQL 这种抽象。然而不久之后，互联网业务都转向 NoSQL 的存储模型。实际上，游戏中对于玩家存档的数据，是完全可以不需要 SQL 这种关系型数据库的了。早期的游戏都是把玩家存档存放到文件里，就连游戏机如 PlayStation ，都是用存储卡就可以了。

一般来说，游戏中需要存储的数据会有两类：

玩家的存档数据
游戏中的各种设定数据

对于第一种数据，用 Key-Value 的方式基本上能满足。而第二种数据的模型可能会有很多种类，所以不需要特别的去规定什么模型。因此我设计了一个 key-value 模型的持久化结构。

/**
* @brief 由于持久化操作一般都是耗时等待的操作，所以需要回调接口来通知各种操作的结果。
*/
class DataStoreCallback {
public:
static int MAX_HANG_UP_CALLBACK_NUM; // 最大回调挂起数
std::string key;
Serializable* value;
DataStoreCallback();
virtual ~DataStoreCallback();
/**
* 当 Init() 初始化结束时会被调用。
* @param result 是初始化的结果。0 表示初始化成功。
* @param msg 是初始化可能存在的错误信息。可能是空字符串 ""。
*/
virtual void OnInit(int result, const std::string& msg);
/**
* 当调用 Get() 获得结果会被调用
* @param key
* @param value
* @param result 是 0 表示能获得对象，否则 value 中的数据可能是没有被修改的。
*/
virtual void OnGot(const std::string& key, Serializable* value, int result);
/**
* 当调用 Put() 获得结果会被调用。
* @param key
* @param result 如果 result 是 0 表示写入成功，其他值表示失败。
*/
virtual void OnPut(const std::string&key, int result);
/**
* 当调用 Remove() 获得结果会被调用
* @param key
* @param result 返回 0 表示删除成功，其他值表示失败，如这个 key 代表的对象并不存在。
*/
virtual void OnRemove(const std::string&key, int result);
/**
* 准备在发起用户设置的回调，如果使用者没有单独为一个回调事务设置单独的回调对象。
* 在 PrepareRegisterCallback() 中会生成一个临时对象，在此处会被串点参数并清理。
* @param privdata 由底层回调机制所携带的回调标识参数，如果为 NULL 则返回 NULL。
* @param init_cb 初始化时传入的共用回调对象
* @return 可以发起回调的对象，如果为 NULL 表示参数 privdata 是 NULL
*/
static DataStoreCallback* PrepareUseCallback(void* privdata,
DataStoreCallback* init_cb);
/**
* 检查和登记回调对象，以防内存泄漏。
* @param callback 可以是NULL，会新建一个仅仅用于存放key数据的临时callback对象。
* @return 返回一个callback对象，如果是 NULL 表示有太多的回调过程未被释放。
*/
static DataStoreCallback* PrepareRegisterCallback(
DataStoreCallback* callback);
protected:
static int kHandupCallbacks; /// 有多少个回调指针被挂起，达到上限后会停止工作
};
/**
*@brief 用来定义可以持久化对象的数据存储工具接口
*/
class DataStore : public Component {
public:
DataStore(DataStoreCallback* callback = NULL)
: callback_(callback) {
// Do nothing
}
virtual ~DataStore() {
// Do nothing
}
/**
* 初始化数据存取设备的方法，譬如去连接数据库、打开文件之类。
* @param config 配置对象
* @param callback 参数 callback 为基本回调对象，初始化的结果会回调其 OnInit() 函数通知用户。
* @return 基本的配置是否正确，返回 0 表示正常。
*/
virtual int Init(Config* config, DataStoreCallback* callback);
virtual int Init(Application* app, Config* cfg){
app_ = app;
return Init(cfg, callback_);
}
virtual std::string GetName() {
return "den::DataStore";
}
virtual int Stop() {
Close();
return 0;
}
/**
* 驱动存储接口程序运行，触发回调函数。
* @return 返回 0 表示此次没有进行任何操作，通知上层本次调用后可以 sleep 一下。
*/
virtual int Update() = 0;
/**
* 关闭程序，关闭动作虽然是异步的，但不再返回结果，直接关闭就好。
*/
virtual void Close() = 0;
/**
* 读取一个数据对象，通过 key ，把数据放入到 value，结果会回调通知 callback。
* 发起调用前，必须把 callback 的 value 字段设置为输出参数。
* @param key
* @param callback 如果NULL，则会回调从 Init() 中传入的 callback 对象。
* @return 0 表示发起请求成功，其他值为失败
*/
virtual int Get(const std::string& key, DataStoreCallback* callback = NULL) = 0;
/**
* 写入一个数据对象，写入 key ，value，写入结果会回调通知 callback。
* @param key
* @param value
* @param callback 如果是 NULL，则会回调从 Init() 中传入的 callback 对象。
* @return 表示发起请求成功，其他值为失败
*/
virtual int Put(const std::string&key, const Serializable& value,
DataStoreCallback* callback = NULL) = 0;
/**
* 删除一个数据对象，通过 key ，结果会回调通知 callback。
* @param key
* @param callback 如果是 NULL，则会回调从 Init() 中传入的 callback 对象。
* @return 表示发起请求成功，其他值为失败
*/
virtual int Remove(const std::string& key,
DataStoreCallback* callback = NULL) = 0;
protected:
/// 存放初始化传入的回调指针
DataStoreCallback* callback_;
};

针对上面的 DataStore 模型，可以实现出多个具体的实现：

文件存储
Redis
其他的各种数据库

基本上文件存储，是每个操作系统都会具备，所以在测试和一般场景下，是最方便的用法，所以这个是一定需要的。

在游戏的持久化数据里面，还有两类功能是比较常用的，一种是排行榜的使用；另外一种是拍卖行。这两个功能是基本的 Key-Value 无法完成的。使用 SQL 或者 Redis 一类 NOSQL 都有排序功能，所以实现排行榜问题不大。而拍卖行功能，则需要多个索引，所以只有一个索引的 Key-Value NoSQL 是无法满足的。不过 NOSQL 也可以“手工”的去建立多个 Key 的记录。不过这类需求，还真的很难统一到某一个框架里面，所以设计也是有限度，包含太多的东西可能还会有反效果。因此我并不打算在持久化这里包含太多的模型。

·END·

▼查看更多游戏干货内容