多对多流共享状态的设计模式[关闭]答案

【问题标题】：Design patterns for shared state with many to many streaming [closed]多对多流共享状态的设计模式[关闭]
【发布时间】：2016-12-24 06:29:00
【问题描述】：

我正在编写一个有趣的在线白板应用程序，多个用户查看同一个白板并可以在上面绘图。我正在使用 websockets（前端的 vanilla JS，后端的 Scala），现在基本上只是将鼠标事件从一个用户广播到其他用户，并在客户端渲染图像。

但是，这会导致暂时的共享状态，而我希望用户能够随时跳上并查看保留的共享状态。我认为这可能需要在后端和前端共享渲染代码，以便客户端在流式传输时渲染事件，但服务器可以在客户端关联时发送原始图像数据。

所以我的问题是：对于此类项目，我应该注意哪些其他设计模式？这是一个娱乐/学习项目，所以这是一个开放式问题，但我会接受一个包含此类数据流的一些有用参考的答案。

【问题讨论】：

【解决方案1】：

所以我的问题是：我应该使用哪些其他设计模式对这类项目有注意吗？

您不必在服务器上拥有渲染代码。您可以保存所有导致当前白板的累积事件并将其发送给新客户端，让新客户端为自己呈现白板，就好像所有事件最初发生时它们正在监听一样。

如果这比实际数据多，那么您可以压缩原始事件。例如，一条直线或近乎直线的线段不需要所有中间的鼠标位置，它实际上只需要线段的第一个和最后一个位置。

【讨论】：

@Nathan - 这回答了你的问题吗？
这是一个很好的答案，虽然我已经考虑过了。我拥有的鼠标事件数量似乎很快就会变得非常昂贵，而且我不能在不损失太多分辨率的情况下过度压缩事件。我将推迟接受答案，因为我在这里寻找一些具有更多外部资源的东西进入一些广泛的模式，例如，很高兴看到一些关于一些大型多人游戏如何解决这个问题的文章种问题。不过还是谢谢你的回答！
@Nathan - 将直线段压缩到第一个和最后一个点使用更少的数据并且不会丢失分辨率，它与渲染图像一样准确，但更紧凑。因此，适当的压缩很有意义，没有缺点。渲染节省了每个中间点。这是矢量图形和位图图形之间的区别。谷歌从位图图形转向谷歌地图的矢量图形有一个重要原因。方式，方式更有效。