Java Hazelcast的性能是否足以进行实时游戏？

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

目前这是一个概念验证，但主要原则在于每个玩家的会话/连接由单个容器持有和管理，因此容器将根据连接用户的数量进行放大和缩小

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

我心目中有一个微型服务，我觉得它有点瓶颈，我目前正在寻找使其更“可扩展”和“健壮”的方法

这个微服务就是GameMap服务。将有多个GameMap服务（每个uniqe或实例GameMap至少有一个服务）。每个贴图将包含N个单元格，每个单元格可以包含不同类型/状态的对象（例如，其他PlayerObject、ItemObjects）

我想能够有一个副本，至少2为每个游戏地图立即翻转，如果一个是由于某种原因失败和关机。。对于用户来说，在失败和故障转移游戏地图之间进行无缝过渡非常重要。为了实现这一点，我需要在他们之间共享一致/最新的状态

需要能够在两个复制副本之间实现负载平衡，这是一个很好的选择，但不是必需的

到目前为止，我提出的一个潜在解决方案是hazelcast。这将允许我在可伸缩内存数据网格中保持每个映射单元的状态（同样是为了健壮性和可伸缩性）

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

有没有人根据这两个场景或更重要的是hazelcast的用例得到任何提示、建议或反馈

---

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

这取决于您的需求、环境等

特别是如果您希望成为HA，您可能希望复制到不同的可用性区域或可能不同的区域，并且您将受到光速的限制（或者需要接受数据丢失的可能性）。换句话说就是这样；性能主要由基础结构决定

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

换言之；很难说这是不是正确的方法。根据您的情况以及这一点的重要性，我将从您的整个系统中选取一部分，并制定一些基准测试，以了解它的性能和扩展能力

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