Hazelcast 的性能是否足以满足实时游戏的需求？

Question

我有一个将游戏引擎重写为可扩展的微服务集合的概念。

它目前是一个概念证明，但主要原则在于每个玩家的会话/连接由单个容器保持和管理，因此容器将根据连接用户的数量进行扩展和缩减。

每个播放器容器将与多个其他微服务对话以收集数据并执行操作，这些服务将是 2 或 3 的静态副本。

我想到了一个微服务，我觉得它有点瓶颈，我目前正在寻找提高“可扩展性”和“健壮性”的方法。

这个有问题的微服务是 GameMap 服务。将有多个 GameMap 服务（每个唯一或实例化的游戏地图至少有一个服务）。每个地图将包含 N 个单元格，并且每个单元格可以包含例如具有不同类型/状态的对象（即其他玩家对象、项目对象）

我希望能够为每个 GameMap 拥有至少 2 个副本，以便在某个人因某种原因失败和关闭时立即翻转。对于用户而言，在失败和故障转移 GameMap 之间进行无缝转换非常重要。为了实现这一点，我需要在它们之间共享一致/最新的状态。

能够在两个副本之间对流量进行负载平衡的需求是很好的，但不是必需的。

到目前为止，我提出的一个潜在解决方案是榛子铸造。这将允许我将每个地图单元的状态保存在可扩展的内存数据网格中（同样是为了稳健性和可扩展性）。

我预计游戏地图中每秒可能会有多达 100 次的状态变化，我担心它可能太慢并导致用户之间的巨大延迟。

有没有人根据这两种情况或更重要的是这里的 hazelcast 用例得到任何提示、建议或反馈？

PS，如果有帮助或有人感兴趣，我可以在某个时候将我的游戏引擎的非常粗糙的连接/架构图上传为微服务。

Answer 1

这实际上取决于您的要求，环境等。

特别是如果你想成为 HA，你可能想复制到不同的可用区或潜在的不同区域，你将受到光速的约束（或者需要接受数据丢失的可能性）。换句话说；性能主要由基础设施决定。

但只是给你一些大概的数字；对于同一低延迟组中的机器之间的 EC 上的 c5.9xlarge 实例的简单读取，您正在查看 100/200 us。每个实例运行数十万次获取通常不是问题。

换句话说; 很难说这是否是正确的做法。根据您的情况以及这有多重要，我会取您整个系统的一个切片并进行一些基准测试，以了解它的性能和扩展性如何。

但是当我看到微服务与“实时”和“游戏引擎”的结合时，我的警钟就响了。