Erlang ETS 表与消息传递：优化问题？答案

【问题标题】：Erlang ETS tables versus message passing: Optimization concerns?Erlang ETS 表与消息传递：优化问题？
【发布时间】：2011-10-18 14:57:19
【问题描述】：

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

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

恐怕我的问题与其说是问题，不如说是对 cmets 的请求。我会赞成任何既有帮助又有充分解释或参考的东西。

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

【问题讨论】：

标签： process erlang ets

【解决方案1】：

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

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

【讨论】：

锁争用问题是关于 erlang 的 ets 表的实现。如果我有 2500 个可能读取表的进程和一个可以写入表的进程，那么最终会有一个时刻，读取器和写入器试图引用相同的数据，而 ets 必须解决该问题。我当然永远不会开始在 erlang 中手动锁定和解锁数据。鉴于数据的不变性，我什至不确定这是否可能。

【解决方案2】：

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

如果您对多节点 ETS 架构感兴趣，如果您想要使用 ETS 实现 OOTB 多节点并发，也许您应该看看 mnesia：Mnesia。（提示：我说的是 ram_copies 表、add_table_copy 和 change_config 方法）。

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

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

从这个角度来看，直接使用ETS表，使用持久化表，进程字典（BAD!!!）等等都是一回事，因为你必须考虑同步问题，就像在面向对象编程中一样使用共享内存的语言（Java，每个人？）。

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

希望对你有帮助！

注意：我说的是 MMORPG 服务器之类的东西，因为我以为你说的是类似的东西。

【讨论】：

【解决方案3】：

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

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

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

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

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

【讨论】：