MMORPG的NoSql选项

Question

我想知道nosql选项可能代替或者与典型MMORPG的rdbms结合使用会带来哪些好处。特别是，我很好奇如何在nosql下保留数据完整性。

我将举几个例子，我对服务器逻辑如何运作感到困惑：

场景1：让我们说玩家A和B同时攻击玩家C.对于任何玩家杀死玩家C，都会更新player_stats.kill_count。通常，可以通过以下方式处理此AttackPlayerRequest：

开始交易 {   attacker.health = newAttackerHealth

defender.health = newDefenderHealth

如果defender.Health == 0   {     attacker.stats.kills + = 1   } }

场景2：玩家A向NPC供应商出售物品，并迅速尝试将同一物品从其库存中丢弃到地面。 （即使你的UI不允许这样做，他们当然可以把事件放在线上）。

这个列表显然会继续影响每个玩家 - 玩家 - 玩家 - 世界互动。最后一条信息是服务器是线程化的，因为我们不希望任何特别冗长的请求阻止其他玩家在游戏中做简单的事情。

我想这里我的重要问题是，我是否误解了一些关于nosql的问题，其中这是一个微不足道的问题？如果没有，这是否超出了nosql选项要解决的范围？在典型的MMO下，可能会注入nosql选项以提高服务器性能吗？

Answer 1

这一切都取决于你的游戏如何运作。

<强>的NoSQL

Facebook上的Farmville使用NoSQL。 Farmville就像一个巨大的服务器，每个人都在。让我们说Farmville在其数据库集群中使用3台计算机。计算机1在圣地亚哥。计算机2在纽约。计算机3在莫斯科。我从圣地亚哥登录Facebook，所以我 在这里连接到数据库。我升级并退出。最终计算机1将告诉计算机2和3我是如何平衡的，但是在俄罗斯有人看到我的账户发生变化之前可能需要一个小时。

NoSQL扩展就像将另一台计算机添加到群集并告诉该区域中的网站使用该计算机一样简单。

<强> SQL

有几种方法可以使SQL工作，但我将解释一种使其类似于NoSQL的方法

每个数据中心将拥有10个游戏服务器，每个服务器都有自己的SQL数据库+ 1个子主数据库。 Sub Master数据库共享所有10个服务器之间的信息，因此如果您登录服务器1并创建角色John Doe，然后注销，如果您下次登录该服务器，Server 10将拥有您的角色。

Sub Master随后在总部与主服务器共享其信息。然后，主服务器将共享John Doe到所有其他数据中心的所有其他子主服务器，这些子主服务器将更新其游戏服务器。此配置允许您登录旧金山的服务器Weed，播放您的角色，退出，登录莫斯科的服务器伏特加，并仍然可以看到您的角色。

像“魔兽世界”这样的游戏使用SQL，但只共享数据库的某些部分。这样可以减少每台计算机上的数据库大小，同时降低硬件要求。

在现实生活中，每个Sub Master都有一个备用Sub Master，如果一台服务器出现故障，你的主服务器会有一些备份服务器，整个网络都不会锁定。

Answer 2

我认为MMO服务器会做很多你在内存中列出的东西。我不认为他们将所有这些都清理到数据库中。我认为更多难以置信的事件，比如接收新装备或改变你的装备布局都会得到保存。

这是很多数据，但并不像每一次战斗互动那么多。

Answer 3

担心延迟的MMORPG通常在单个服务器上运行，并将除了对象模型信息之外的所有内容存储在RAM中。任何有战斗环境的东西都会担心延迟。

任何使用HDD的东西，无论是RDBMS还是NoSQL，在战斗环境中都是个坏主意。通过任何使用HHD的机制，在单个服务器上的10,000个用户之间更新和共享对象自定义，位置，移动向量，数据，如果您担心延迟，那就太傻了。即使你有两个人在一个简单的舞台上战斗，延迟仍然是一个问题，你应该在一台服务器上运行，并将所有内容保存在内存中。所有渲染的内容都应该在您的PC上或PC的内存中。

不担心延迟的MMORPG可以运行在多个服务器和您希望的任何数据库上（NoSQL，MySQL等......）

如果您正在制作像farmville或neopets这样的游戏，那么是，NoSQL或MySQL成为有效选项。

Answer 4

据我了解，nosql技术是您在批处理作业上下文中使用的，而不是在实时上下文中。事实上，开源H-base实现位于hadoop分布式文件系统（hdfs）之上，主要用于只读情况。

这个想法是你通过迭代整个数据集来“寻找”一个记录，你保持“在磁盘上”（实际上在分布式文件系统上）。对于千万亿次级数据集，将内容保存在内存中是不可行的，因此您可以利用大量磁盘读取来“搜索”数据。分布式特性确保（或促进）及时发生。

原则是您将处理带到分布式数据，而不是从非常大的数据库中提取数据，通过网络发送数据，然后在本地节点上处理它。 Pig（http://pig.apache.org/）和Hive（http://hive.apache.org/）是hdfs之上的接口，它允许类似SQL的查询，但在后台，它们使用mapreduce工作。交互很慢，但这不是重点。关键是可以处理巨大的数据集。

对于游戏来说，这显然不是可行的方法。因此，您可能希望从分布式文件系统中获取数据，缓存在服务器上并在会话期间使用，当游戏结束时，所有数据都将提交回数据集。 （至少，这就是我想象的那样）。

Hdfs数据集主要在某个时间点处理，之后结果将在一个批次中发布。例如，在社交网站中，您将每天编译所有连接数据，搜索人与人之间的所有新连接，并且当数据集中的所有人的操作完成时，结果将以典型方式发布'X现在被传送到Y'消息。这不是实时发生的。