我禁不住觉得您正在使应该简单解决的问题变得过于复杂.
商业和成功的MMO通常采用这样的方法:
Every few minutes or after a significant action:
copy the player data
pass the player data to a background thread
In the background thread:
write each piece of player data to the database
没有“高度并发”的数据更改,因为每个玩家都将自己的数据保存到数据库的不同行中. (在某些情况下,这实际上是一行,一些商业游戏只是将玩家数据作为Blob存储在用户ID上.)有时数据有些陈旧,但这并不重要.如果服务器崩溃,这只会是一个问题,因为否则,您最终会将当前状态存储到数据库中.这不是我们正在谈论的银行间信贷转移.
至于MUD和BBS游戏,它们的算法将更加简单:
Every few minutes or after a significant action:
For each property in the player object:
write a property to the player's file
同样,这里没有争用,因为每个播放器都有自己的文件.
坚持使用每个用户命令确实是过高的,除非您的游戏货币化程度很高,并且由于服务器崩溃而使人们失去了3 Axe Awesome,否则有人会起诉您.
而除了玩家之外,您还需要坚持什么呢?持久保留其他所有内容通常会对游戏产生负面影响,因此通常您不希望这样做.
按照您的示例,对于“并发”访问同一怪物,这没有关系.如果只有一个进程,则怪物应该在RAM中.您的单个过程可以仲裁谁击中怪物以及以什么顺序击中怪物.这不是您的持久层的工作.处理游戏中的游戏逻辑并保持结果.