选择哪种设计模式

我需要一个正确方向的指针.我一直在环顾四周,似乎找不到任何能指向正确方向的设计模式(GoF).

我正在开发一个小型数字标牌应用原型,其中有一个简单的服务器和连接到该服务器的大量播放器应用程序(显示图像/视频).我的要求是能够将100个播放器连接到单个服务器,并为每个服务器分配50Mb数据.

我打算在服务器和收集播放器的玩家(每个大约25个？)之间建立小型集线器(软件集线器),并让集线器获取并分发50Mb数据(分而治之,对吧？).50Mb只适用于原型,我认为在现实生活中,每个显示视频的播放量大约为300Mb.这些集线器的原因是我会避免让100个玩家同时请求50Mb,而只有4个(每个玩家25个玩家)集线器将请求并重新分配.

使用集线器时,我需要能够在集线器之间移动播放器,即从一个集线器中移除播放器并将其连接到另一个集线器.(我的一个想法是连接到同一个集线器的所有播放器必须共享内容,因此集线器将避免必须下载25个不同的电影)

请问,有谁知道这在现实生活中是如何完成的？你能否评论我的概念和/或指出我正确的方向,以帮助我解决这个问题.

在设计之前不要" 选择 "设计模式.先设计,然后与模式进行比较.

您的设计无需始终遵循模式.但是,请确保您的设计不符合反模式.

你需要退一步.在那一刻,您正在尝试专注于软件架构的细节,而没有考虑(或至少提到)一些重要的要求.

看起来你真的只是想流式传输视频.所以:

您可以使用现成的视频流产品吗？这可能比建立自己的便宜.

如果不:

广播模型是否适合您,或者它是否必须按需提供？也就是说,假设客户端1请求视频A.如果,几分钟后,客户端2也想要视频A,如果客户端2成为客户端1正在接收的同一流的另一个查看者,是否可以？

这是通过互联网传送还是通过您可以控制的专用网络传送的？

如果您使用专用网络并且广播模型可以使用,您可以使用UDP多播,与纯粹的按需解决方案相比,它可以显着减少带宽.

因此,在开始决定软件架构之前,您需要考虑硬件限制以及它们对可用选择的影响.

回到你提出的解决方案,我认为它不会非常可靠地扩展.如果某个特定内容非常受欢迎,那么您的某个集线器将会严重超载,而其他集线器则处于空闲状态.您可能希望研究一种更传统的负载平衡技术,该技术允许您通过简单地添加更多服务器来扩展.