c++ - 为 MMO 游戏设计日志服务器

Question

我是游戏服务器设计的新手，现在分配了一项任务来重构我们的日志服务器。我为游戏服务器和日志服务器之间的通信创建了一个类日志。

class Log
{
    public:
        void    encode(Encoder& encoder) const;
        int     decode(Decoder& decoder);
    private:
        std::string sql_cmd;
}

在游戏服务器上，有一个向日志服务器发送日志请求的类。

class LogHelper
{
public:
        static void LogItemChange(const GameShare::GameItem& item, const PackageChangeDetails& pcd);
        {
                Log log(get_item_change_sql(item,pcd);
                send_to_log_server();
        }


private:
        static std::string get_item_change_sql(const GameShare::GameItem& item, const PackageChangeDetails& pcd);
}

问题是:

1. 我应该在游戏服务器上生成 sql 文本吗？如果在游戏服务器上生成sql文本，对游戏服务器的性能有影响吗？

2. 如果不在游戏服务器上生成sql文本，那么应该在日志服务器上生成sql文本。我应该将 GameItem 和 PackageChangeDetails 实例数据发送到日志服务器，这会使日志服务器复杂化，有人有好主意吗？

Answer 1

如果日志的 SQL 是由游戏服务器生成的，那么几乎不需要任何日志服务器代码，因为它成为数据库管理器部分的通路，游戏服务器几乎肯定已经知道(尽管我想它们可能是不同的数据库)，或者可以很容易地与之交互。

Log Server 应该是一个单独的组件，以您最方便的任何格式(性能、冗长、大小等)记录日志，只要 API 足够灵活，就可以编写底层实现可以在游戏服务器不知情的情况下被替换。

通过将底层实现的完整知识与游戏服务器代码相结合，您不仅可以防止 future 的此类工作，而且还可能将大量工作放入游戏服务器的代码中，而这些工作本可以由一个单独的线程完成日志服务器。更不用说，通过向 SQL 开放 API，您将潜在的错误置于整个游戏服务器代码中，否则这些错误将被集中。

在设计面向对象的系统时，前瞻性的、替换驱动的方法是理想的。如果你能避免耦合到 API 以外的任何东西，那么你总是可以替换 API 下的任何东西而不影响外部代码(忽略错误)，但这需要考虑到 API 中以确保它具有足够的灵 active 以应对 future .

关于这一点，我强烈建议您将 Logging API 实现为一个纯虚拟接口(interface)，然后在其之上编写一个与数据库对话的实现，可能还有一个单独的实现将日志记录到一个文本文件(例如方便的本地测试，无需访问数据库，如果这曾经是一个问题)以及无所事事的实现。记住前两个，它应该有助于指导您进行更好的设计，并避免耦合。

这也可能导致您的其他类实现的一些基本接口(interface)(例如，public: std::string to_log_string() const;)，然后 Logger 可以使用它来引入任何实现对象并快速将其转换为记录的消息。

所有这些就是说，将日志记录相关的 SQL 放在 Log Server 中，而不是放在 Game Server 中。游戏服务器不应该关心日志服务器除了一般的“日志记录”之外做了什么。