用于（游戏）服务器通信的 Web 服务或共享数据库？
我们有 2 个服务器集群：第一个由 SQL 数据库支持的典型 Web 应用程序组成。第二个是高度优化的多人游戏服务器，它将所有数据保存在内存中。两个集群都通过 HTTP（Ajax 和 JSON）与客户端通信。在某些情况下，我们需要在两种服务器类型之间共享数据，例如，报告和存储游戏结果（最终应存储在数据库中）。
我们正在考虑几种服务器间通信的方法：
- 在集群之间共享 MySQL 数据库（向游戏服务器引入 SQL）
- 在分布式键值存储（如 Memcache、Redis 等）中共享数据。
- 使用 RPC 技术（如 Google ProtoBufs）或 Apache Thrift
- 使用 RESTful Web 服务（例如，游戏服务器将 POST 回 Web 服务器）
目前，我们倾向于 Web 服务或仅共享数据库。共享数据库似乎很容易，但我们担心这会增加额外的内存和对游戏服务器的新依赖。 Web 服务提供了良好的关注点分离并适合我们使用的现有 Ajax，但增加了复杂性、开销以及更多导致通信失败的方式。
还有其他充分的理由不使用其中一种方法吗？哪个更容易扩展？
We have 2 server clusters: the first is made up of typical web applications backed by SQL databases. The second are highly optimized multiplayer game servers which keep all data in memory. Both clusters communicate with clients via HTTP (Ajax with JSON). There are a few cases in which we need to share data between the two server types, for example, reporting back and storing the results of a game (should ultimately end up in the database).
We're considering several approaches for inter-server communication:
- Just share the MySQL databases between clusters (introduce SQL to the game servers)
- Sharing data in a distributed key-value store like Memcache, Redis, etc.
- Use an RPC technology like Google ProtoBufs or Apache Thrift
- Using RESTful web services (the game server would POST back to the web servers, for example)
At the moment, we're leaning towards web services or just sharing the database. Sharing the database seems easy, but we're concerned this adds extra memory and a new dependency into the game servers. Web services provide good separation of concerns and fit with the existing Ajax we use, but add complexity, overhead and many more ways for communication to fail.
Are there any other good reasons not to use one or the other approach? Which would be easier to scale?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
共享数据库带来了一个明显的缺点，即没有一个单元来控制进入数据库的数据。这可能是一个很大的麻烦，我建议构建一个应用程序层。
如果这个应用程序层是您的 Web 应用程序形成的，那么我认为在游戏服务器和 Web 应用程序之间实现客户端-服务器通信没有任何问题。让游戏服务器将数据推送到应用层并让他们订阅更新。这非常适合消息队列系统，但如果这更适合您当前的架构，您可以构建自己的基于 REST 的系统。
如果网络应用程序不形成应用程序层，我建议通过编写一个小应用程序来引入这样一个层，它隐藏了存储的细节。每一方都获取应用程序接口的句柄，并向其中写入数据。
为了在两个系统之间共享数据，应用层可以使用分布式数据库，例如 mnesia，或者实现具有复制功能的多级缓存系统。最简单的版本是时间触发的复制，例如您提到的 MySQL。其他选项包括消息队列、复制内存 (Terracotta) 和/或复制缓存 (memcached)，尽管它们不提供持久存储。
Sharing the DB brings the obvious drawback of not having one unit in control of the data going into the DB. This can be a big hassle, which is I would recommend building an application layer.
If this application layer is what your web applications form, then I see nothing wrong with implementing client-server communication between the game servers and the web apps. Let the game servers push data to the application layer and have them subscribe to updates. This is a good fit to a message queueing system, but you could get away with building your own REST-based system for instance, if this fits better with your current architecture.
If the web apps do not form the application layer, I would suggest introducing such a layer by writing a small app, which hides the specifics of the storage. Each side gets a handle to the app interface, and writes it data to it.
In order to share the data between the two systems, the application layer could then use a distributed DB, like mnesia, or implement a multi-level cache system with replication. The simplest version of this would be time-triggered replication with for instance MySQL as you mention. Other options are message queues, replicated memory (Terracotta) and/or replicated caches (memcached), although these do not provide persistent storage.
我还建议将 Redis 视为数据存储，并 nodered 用于分布式发布-订阅。
尽管 Redis 是内存中的 K/V 存储，但最新版本具有 VM 支持，其中键保存在内存中，但当内存压力达到可配置阈值时，值可能会被换出。它还内置了简单的主从复制和发布订阅功能。NodeRed
构建于 node.js 之上，这是一个可扩展且速度极快的服务器端 js 引擎。
I'd also suggest looking at Redis as a data store and nodered for distributed pub-sub.
Although Redis is an in-memory K/V store, the latest version has VM support where keys are kept in memory, but values may be swapped out as memory pressure hits a configurable threshold. It also has simple master-slave replication and publish-subscribe built in.
NodeRed is built on node.js which is a scalable and ridiculously fast server-side js engine.