15

我正在进入一个现有的(游戏)项目,其服务器组件完全用 erlang 编写。有时,从拥有该系统的进程中获取一条数据(我对播放器 56 有多少小部件感兴趣)可能会非常痛苦。假设我可以找到拥有数据的进程,我可以将消息传递给该进程并等待它传回消息,但这不能很好地扩展到多台机器并且它会缩短响应时间。

我一直在考虑用一个系统替换该游戏中存在的许多任务,在该系统中,多个进程经常访问的信息将存储在受保护的 ets 表中。表的所​​有者只会接收更新消息(玩家刚刚花费了五个小部件)并相应地更新表。它将捕获所有异常并简单地继续下一个更新消息。任何想知道玩家是否有足够的小部件来购买傻瓜的过程只需要偷看桌子。(是的,我知道缓冲区中可能有一条消息会减少小部件的数量,但我已经控制了这个问题。)

恐怕我的问题与其说是问题,不如说是征求意见。我会赞成任何既有帮助又有充分解释或参考的内容。

这种实现的可能缺点是什么?我对锁争用的细节很感兴趣,我可能会在拥有一个写者多个读者的情况下看到,在多台机器上分发它会遇到什么样的问题,尤其是:来自做过的人的输入这之前。

4

3 回答 3

8

首先,默认的 ETS 行为是一致的,正如您在文档中看到的那样:Erlang ETS。它提供原子性和隔离性,如果在同一个函数中完成,还提供多次更新/读取(请记住,在 Erlang 中,函数调用大致相当于缩减,Erlang 调度程序用于在进程之间共享时间的度量单位,因此多函数 ETS操作可能会分成更多部分,从而产生可能的竞争条件)。

如果您对多节点 ETS 架构感兴趣,如果您想要与 ETS 的 OOTB 多节点并发,也许您应该看看 mnesia:Mnesia。(提示:我说的是 ram_copies 表、add_table_copy 和 change_config 方法)。

话虽如此,我不明白进程的问题(可能由未命名的 ets 表支持)。我解释得更好:您项目的主要问题是第一个基本假设。很简单:你没有一个单一的写作过程!

每次玩家拿到一个物体,击中一个玩家等等,它都会调用一个无副作用的函数来更新游戏状态,所以即使你有一个管理游戏状态的进程,他也必须告诉其他玩家客户端'嘿,你还记得那里的那个物体吗?把它忘了吧!'; 这就是为什么许多多人游戏的主要问题是延迟:延迟,当网络不是主要问题时,很多时候是由于阻塞发送/接收例程。

从这个角度来看,直接使用 ETS 表、使用持久表、进程字典(BAD !!!)等是一回事,因为您必须考虑同步问题,例如在面向对象的编程语言中使用共享内存(Java,每个人?)。

最后,您应该只考虑开发应用程序的一个主要问题:一致性。在开发出一致的应用程序之后,您才应该关注性能调整。

希望能帮助到你!

注意:我谈到了类似 MMORPG 服务器之类的东西,因为我以为你在谈论类似的东西。

于 2011-08-02T22:11:27.867 回答
7

ETS 表不会解决您在这方面的问题。您的代码(想要获取或设置播放器小部件计数)将始终在进程中运行,并且必须将数据复制到那里。

无论是来自进程堆还是 ETS 表都没有什么区别(也就是说,从 ETS 读取通常更快,因为它经过了很好的优化并且除了获取和设置数据之外不执行任何其他工作)。尤其是从远程节点获取数据时。对于多个阅读器,ETS 很可能更快,因为一个进程会按顺序处理请求。

然而,不同之处在于数据是否缓存在本地节点上。这就是 Mnesia、Riak 或 CouchDB 等自我复制数据库系统的用武之地。Mnesia 实际上是使用 ETS 表实现的。

至于锁定,最新版本的 Erlang 对 ETS 进行了增强,它允许多个读取器同时从一个表中读取以及一个写入器。唯一锁定的元素是正在写入的行(因此,如果您希望一个数据点同时进行多次读取,则并发性能比正常进程要好)。

但是请注意,与 ETS 表的所有交互都是非事务性的!这意味着您不能依赖于基于先前读取来写入值,因为该值可能在此期间发生了变化。Mnesia 使用事务处理。如果您知道自己在做什么,您仍然可以使用dirty_*Mneisa 中的功能从大多数操作中挤出接近 ETS 的性能。

于 2011-08-03T09:23:11.717 回答
4

听起来你有一堆随时可能发生的事情,你需要以一种安全、统一的方式聚合数据。查看通用事件行为。我建议使用它来创建事件服务器,并让所有这些进程通过事件将这些信息共享到您的服务器,此时您可以选择将其记录或存储在某处(如 ETS 表)。顺便说一句,ETS 表不适用于持久数据,例如玩家拥有多少“小部件” - 考虑Mnesia或像CouchDB这样的出色的仅崩溃数据库。这两种方法都可以很好地跨机器复制。


你提出了锁争用——你不应该有任何锁。消息在被每个进程接收时以同步顺序进行处理。事实上,语言中内置的消息传递语义的全部意义在于避免共享状态并发。
总而言之,通常您与消息进行通信,从一个进程到另一个进程。这对您来说很麻烦,因为您需要来自分散在各处的流程的信息,因此我对您的建议是基于将原始流程之外的所有“有趣”信息集中到单个实时源中的想法.

于 2011-08-02T22:02:28.457 回答