MMORPG 的 NoSql 选项
我想知道对于典型的 MMORPG，nosql 选项可以代替 RDBMS 或与 RDBMS 结合使用，有什么好处。我特别好奇 nosql 下如何保持数据完整性。
我将举几个我对服务器逻辑如何运行感到困惑的例子：
场景 1：假设玩家 A 和 B 同时攻击玩家 C。玩家杀死玩家 C 后，player_stats.kill_count 就会更新。通常，可以通过以下方式处理此 AttackPlayerRequest：
开始事务 { Attacker.health = newAttackerHealth
Defender.health = newDefenderHealth
如果 Defender.Health == 0 { 攻击者.stats.kills += 1 } }
场景 2：玩家 A 将物品出售给 NPC 供应商，并快速尝试将同一物品从库存中扔到地上。 （即使你的用户界面不允许这样做，他们当然也可以将事件放在线上）。
这个列表显然还在继续，并且影响着几乎每一个玩家-玩家-玩家-世界的互动。最后一条信息是服务器是线程化的，因为我们不希望任何特别冗长的请求阻止其他玩家在游戏中执行简单的操作。
我想我的大问题是，我是否误解了 nosql 的某些内容，其中这是一个微不足道的问题？如果不是，这是否超出了 nosql 选项要解决的范围？在典型的 MMO 中，可以在哪里注入 nosql 选项来提高服务器性能？
I was wondering what sort of benefits a nosql option might have either in lieu of, or in conjunction with a rdbms for a typical MMORPG. In particular, I'm curious as to how data integrity is preserved under nosql.
I'll give a few examples where I'm kind of confused as to how server logic would operate:
Scenario 1: Let's say player A and B attack player C at the same time. A player_stats.kill_count is updated for whichever player kills player C. Normally, one might handle this AttackPlayerRequest in the following way:
Begin Transaction
{
attacker.health = newAttackerHealth
defender.health = newDefenderHealth
if defender.Health == 0
{
attacker.stats.kills += 1
}
}
Scenario 2: Player A sells an item to an NPC vendor, and quickly attempts to drop the same item from their inventory to the ground. (Even if you're UI disallows this, they can certainly just put the events on the wire).
This list obviously goes on and effects just about every player-player player-world interaction. One last piece of information is that the server is threaded as we don't want any particularly lengthy request to block other players from being able to do simple things in the game.
I guess my big question here is, am I misunderstanding something about nosql wherein this a trivial problem? If not, is this beyond the domain of what nosql options are meant to solve? Under a typical MMO, where might one inject nosql options to increase server performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这一切都取决于您的游戏如何运作。
NoSQL
Facebook 上的 Farmville 使用 NoSQL。 《Farmville》就像一台每个人都在使用的巨大服务器。假设 Farmville 在其数据库集群中使用 3 台计算机。圣地亚哥的 1 号计算机。纽约的 2 号计算机。莫斯科的 3 号计算机。我从圣地亚哥登录 Facebook，所以我
在这里连接到数据库。我升级并退出。最终计算机 1 会告诉计算机 2 和 3 我是如何升级的，但俄罗斯的某人可能需要一个小时才能看到我帐户的这些更改。
NoSQL 扩展非常简单，只需将另一台计算机添加到集群并告诉该区域的网站使用该计算机即可。
SQL
有几种使 SQL 工作的方法，但我将解释一种使其类似于 NoSQL 的方法。
每个数据中心将有 10 个游戏服务器，每个服务器都有自己的 SQL 数据库 + 1 个子主数据库。子主数据库在所有 10 个服务器之间共享信息，因此如果您登录服务器 1 并创建角色 John Doe，然后注销，那么如果您下次登录该服务器，服务器 10 将拥有您的角色。
然后，子主服务器与总部的主服务器共享其信息。然后，主服务器会将 John Doe 共享给所有其他数据中心的所有其他子主服务器，并且这些子主服务器将更新其游戏服务器。此配置将允许您登录旧金山的服务器 Weed，玩您的角色，注销，登录莫斯科的服务器 Vodka，但仍然可以看到您的角色。
像《魔兽世界》这样的游戏使用 SQL，但只有数据库的某些部分是共享的。这可以减少每台计算机上的数据库大小，并减少硬件要求。
在现实生活中，每个子主服务器都会有一个备份子主服务器，并且您的主服务器将有一些备份服务器，即使一台服务器出现故障，您的整个网络也不会锁定。
This all depends on how your game operates.
NoSQL
Farmville on facebook uses NoSQL. Farmville acts like 1 enormous server that everyone is on. Let's say Farmville uses 3 computers in its database cluster. Computer 1 in San Diego. Computer 2 in New York. Computer 3 in Moscow. I login to Facebook from San Diego so I
connect to the database here. I level up and log out. Eventually Computer 1 Will tell computer 2 and 3 about how I leveled but it could be up to an hour before someone in Russia would see those changes to my account.
NoSQL scaling is as simple as adding another computer to the cluster and telling the website in that region to use that computer.
SQL
There are several methods of making SQL Work but I will explain a way to make it similar to NoSQL
Each Data-center will have 10 game servers, each with its own SQL Database + 1 Sub Master Database. The Sub Master Database shared the information between all 10 servers so if you login to server 1 and make character John Doe, then logout, Server 10 will have your character if you login to that server next.
Sub Master then shares its information with the Master Server at your HQ. The Master Server will then share John Doe to every other sub master at all the other data-centers, and those sub masters will update their game servers. This configuration would allow for you to login to server Weed in San Francisco, play your character, logout, login on server Vodka in Moscow, and still see your character.
Games like World of Warcraft use SQL but only certain parts of the database are shared. This allows for reduced Database size on each computer and also reducing hardware requirements.
In a real life situation each Sub Master would have a backup Sub Master, and your Master server would have a few backup servers in the event that one server goes down your entire network would not lock up.
我认为 MMO 服务器可以做很多你在内存中列出的事情。我认为他们不会将所有这些内容都刷新到数据库中。我认为更多困难的事件，例如接收新装备或更改装备布局将被保存。
这是大量数据，但还没有每一次战斗交互那么多。
I think MMO servers would do a lot of the stuff you've listed in memory. I don't think they flush all of those out into the database. I think more hard-set events like receiving new gear or changing your gear layout would be saved.
It's a lot of data, but not nearly as much as every single combat interaction.
担心延迟的 MMORPG 通常在单个服务器上运行，并将除对象模型信息之外的所有内容存储在 RAM 中。任何有战斗环境的东西都会担心延迟。
任何使用 HDD 的东西，无论是 RDBMS 还是 NoSQL，在战斗环境中都是一个坏主意。如果您担心延迟，那么通过任何使用 HHD 的机制在单个服务器上的 10,000 个用户之间更新和共享对象定制、位置、运动矢量、方向矢量、健康状况、功率等数据都是愚蠢的。即使您有 2 个人在一个简单的竞技场中战斗，延迟仍然是一个问题，您应该在单个服务器上运行并将所有内容保留在内存中。将渲染的所有内容都应该位于您的电脑上或电脑的内存中。
不担心延迟的 MMORPG 可以在多个服务器和您希望的任何数据库（NoSQL、MySQL 等）上运行。
如果您正在制作 Farmville 或 Neopets 等游戏，那么 NoSQL 或 MySQL 会成为有效的选择。
MMORPGs that are worried about latency typically run on a single server, and store everything except object model information in RAM. Anything with battle environments are worried about latency.
Anything that uses HDD, be it an RDBMS or NoSQL, is a bad idea in battle environments. Updating and sharing object customization, position, movement vector, orientation vector, health, power, etc... data between 10,000 users on a single server via any mechanism that uses HHD is just silly if you are worried about latency. Even if you have 2 people fighting in a simple arena, latency is still an issue and you should run on a single server and keep everything in memory. Everything that will be rendered should be on your PC or in the memory of your PC as well.
MMORPGs that are not worried about latency can run on multiple servers and any database you wish (NoSQL, MySQL, etc...)
If you're making a game like farmville or neopets, then yes, NoSQL or MySQL become valid options.
据我了解，nosql 技术是在批处理作业上下文中使用的技术，而不是在实时上下文中使用的技术。事实上，开源的 H-base 实现位于 hadoop 分布式文件系统 (hdfs) 之上，该系统主要用于只读情况。
这个想法是，您通过迭代您保存在“磁盘”上（实际上是在分布式文件系统上）的整个数据集来“寻找”记录。对于千万级数据集，将数据保存在内存中是不可行的，因此您需要利用大量磁盘读取来“寻找”数据。分布式特性确保（或促进）这一切及时发生。
原则是，将处理带到分布式数据中，而不是从非常大的数据库中提取数据，通过网络发送，然后在本地节点上处理。 Pig（http://pig.apache.org/）和Hive（http://hive.apache.org/）是hdfs之上的接口，允许类似SQL的查询，但在后台，它们使用mapreduce工作机会。交互很慢，但这不是重点。关键是海量的数据集是可以处理的。
对于游戏来说，这显然不是一条出路。因此，您可能希望从分布式文件系统中获取数据，缓存在服务器上，并在会话期间使用。当游戏结束时，所有数据都将提交回数据集。 （至少，我想象的是这样的）。
Hdfs数据集大多在某个时间点进行处理，之后将结果批量发布。例如，在社交网站中，您将每天编译所有连接数据，搜索人与人之间的所有新连接，当对数据集中的所有人完成操作时，结果将发布在典型的“X 现在已连接到 Y”消息。这不是实时发生的。
To my understanding, nosql technology is something you would use in a batch job context, and not in a real-time context. As a matter of fact, the open source H-base implementation sits on top of the hadoop distributed file system (hdfs), which is primarily used for read-only situations.
The idea is that you 'seek' a record by iterating over the whole data set you are keeping 'on disk' (on a distributed file system actually). For petascale datasets it is infeasible to keep things in memory, so you utilize massive amounts of disk reads to be able to 'seek' the data at all. The distributed nature makes sure (or facilitates) that this occurs in a timely fashion.
The principle is that you bring the processing to the distributed data, instead of pulling data from a very large database, sending it over the network and then process it on a local node. Pig (http://pig.apache.org/) and Hive (http://hive.apache.org/) are interfaces on top of hdfs, which allow for SQL-like queries, but in the background, they use mapreduce jobs. Interaction is slow, but this is not the point. The point is that the immense data set can be processed at all.
For gaming, this is obviously not the way to go. So you would expect that data to be fetched from the distributed file system, cached on a server, and used during a session, When the game has finished, all data would be committed back to the data set. (At least, that's how I imagine it would go).
Hdfs data sets are mostly processed at a certain point in time, after which the results are being published in one batch. For example, in a social network site, you would compile all connection data on a daily basis, search for all new connections between people, and when the operation has finished for all people in the data set, the results would be published in the typical 'X is now conected to Y' messages. This does not happen in real-time.