我有一个将游戏引擎重写为可扩展的微服务集合的概念。
它目前是一个概念证明，但主要原则在于每个玩家的会话/连接由单个容器保持和管理，因此容器将根据连接用户的数量进行扩展和缩减。
每个播放器容器将与多个其他微服务对话以收集数据并执行操作，这些服务将是 2 或 3 的静态副本。
我想到了一个微服务，我觉得它有点瓶颈，我目前正在寻找提高“可扩展性”和“健壮性”的方法。
这个有问题的微服务是 GameMap 服务。将有多个 GameMap 服务（每个唯一或实例化的游戏地图至少有一个服务）。每个地图将包含 N 个单元格，并且每个单元格可以包含例如具有不同类型/状态的对象（即其他玩家对象、项目对象）
我希望能够为每个 GameMap 拥有至少 2 个副本，以便在某个人因某种原因失败和关闭时立即翻转。对于用户而言，在失败和故障转移 GameMap 之间进行无缝转换非常重要。为了实现这一点，我需要在它们之间共享一致/最新的状态。
能够在两个副本之间对流量进行负载平衡的需求是很好的，但不是必需的。
到目前为止，我提出的一个潜在解决方案是榛子铸造。这将允许我将每个地图单元的状态保存在可扩展的内存数据网格中（同样是为了稳健性和可扩展性）。
我预计游戏地图中每秒可能会有多达 100 次的状态变化，我担心它可能太慢并导致用户之间的巨大延迟。
有没有人根据这两种情况或更重要的是这里的 hazelcast 用例得到任何提示、建议或反馈？
PS，如果有帮助或有人感兴趣，我可以在某个时候将我的游戏引擎的非常粗糙的连接/架构图上传为微服务。