用于(游戏)服务器通信的Web服务还是共享数据库？
我们有两个服务器集群:第一个是由SQL数据库支持的典型web应用程序组成的。第二个是高度优化的多人游戏服务器，它将所有数据保存在内存中。两个集群都通过HTTP (Ajax和JSON)与客户端通信。在一些情况下，我们需要在两种服务器类型之间共享数据，例如，返回和存储游戏结果(最终应该在数据库中结束)。
我们正在考虑几种服务器间通信的方法：
- 只需在集群之间共享MySQL数据库(将SQL引入游戏服务器)
- 在诸如Memcache、Redis等分布式密钥值存储中共享数据。
- 使用RPC技术，如Google、ProtoBufs或Apache
- 使用RESTful web服务(例如，游戏服务器将回发到web服务器)
目前，我们倾向于web服务，或者只是共享数据库。共享数据库似乎很容易，但我们担心这会给游戏服务器增加额外的内存和新的依赖关系。Web服务提供了良好的关注点分离，并与我们使用的现有Ajax相匹配，但增加了复杂性、开销和更多的通信失败方式。
是否有其他好的理由不使用其中一种或另一种方法？哪一种更容易扩展？
回答 2
Stack Overflow用户
发布于 2010-05-14 07:54:54
共享DB带来了一个明显的缺点，即没有一个单元来控制进入DB的数据。这可能是一个大麻烦，这是我建议构建一个应用层。
如果这个应用层是您的web应用程序的形式，那么我认为在游戏服务器和web应用程序之间实现客户机-服务器之间的通信没有什么问题。让游戏服务器将数据推送到应用层，并让他们订阅更新。这是一个非常适合消息排队系统，但您可以通过构建您自己的基于REST的系统，例如，如果这更适合您当前的体系结构。
如果网络应用程序不构成应用层，我建议通过编写一个小应用程序来引入这样一个层，它隐藏了存储的细节。每一方获取应用程序接口的句柄，并将数据写入应用程序接口。
为了在两个系统之间共享数据，应用层可以使用分布式DB (如mnesia )，或者实现具有复制的多级缓存系统。最简单的版本将是时间触发的复制，例如，正如您提到的MySQL。其他选项是消息队列、复制内存(Terracotta)和/或复制缓存(memcached)，尽管它们不提供持久存储。
Stack Overflow用户
发布于 2010-05-14 23:06:36
我还建议将Redis作为一个数据存储区，将点名作为分布式pub-sub的数据存储。
尽管Redis是一个内存中的K/V存储区，但最新版本支持在内存中保存键的VM，但是当内存压力达到可配置的阈值时，值可能会被交换掉。它还内置了简单的主从复制和发布订阅。
NodeRed是建立在node.js之上的，它是一个可伸缩且速度惊人的服务器端js引擎。
https://stackoverflow.com/questions/2832560
复制相似问题
腾讯云开发者
