process - Erlang ETS 表与消息传递 : Optimization concerns?

Question

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

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

恐怕我的问题与其说是问题，不如说是征求意见。我会赞成任何有用且充分解释或引用的内容。

这种实现的可能缺点是什么？我对锁争用的细节很感兴趣，我可能会看到一个作者-多个读者，我将在多台机器上分发它会遇到什么样的问题，尤其是:来自已经完成的人的输入这之前。

Answer 1

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

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

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

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

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

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

希望能帮助到你!

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