我需要一个正确方向的指针。我一直在环顾四周,似乎找不到任何可以指向正确方向的设计模式(GoF)。
我正在开发一个小型数字标牌应用原型,其中有一个简单的服务器和连接到该服务器的大量播放器应用程序(显示图像/视频)。我的要求是能够将100个播放器连接到单个服务器,并为每个服务器分配50Mb数据。
我计划在服务器和收集播放器的玩家(每个大约25个?)之间建立小型集线器(软件集线器),并让集线器获取并分发50Mb数据(分而治之,对吧?) 。 50Mb只适用于原型,我认为在现实生活中,每个显示视频的播放量大约为300Mb。这些集线器的原因是我可以避免让100个玩家同时请求50Mb,而只有4个(每个玩家25个玩家)集线器会请求并重新分配。
使用集线器时,我需要能够在集线器之间移动播放器,即从一个集线器中移除播放器并将其连接到另一个集线器。 (我的一个想法是连接到同一个集线器的所有播放器必须共享内容,因此集线器将避免下载25个不同的电影)
拜托,有谁知道这在现实生活中是如何完成的?你能否评论一下我的概念和/或指出我正确的方向,以帮助我解决这个问题。
答案 0 :(得分:8)
在设计之前,请不要“选择”设计模式。 先设计,然后与模式进行比较。
您的设计无需始终遵循模式。 但是,请确保您的设计不符合反模式。
答案 1 :(得分:5)
你需要退后一步。在那一刻,你正在努力专注于软件架构的细节,而没有考虑(或至少提到)一些重要的要求。
看起来你真的只是试图流式传输视频。所以:
如果不是:
广播模型是否适合您,或者是否需要按需播放?也就是说,假设客户端1请求视频A.如果,几分钟后,客户端2也想要视频A,如果客户端2成为客户端1正在接收的同一流的另一个查看者,是否可以?
这是通过互联网或您可以控制的专用网络传送的吗?
如果您使用专用网络并且广播模型可以使用,您可以使用UDP多播,与纯粹的按需解决方案相比,可以显着降低带宽。
因此,在开始决定软件架构之前,您需要考虑硬件限制以及它们对您可用选择的影响。
回到您提出的解决方案,我认为它不会非常可靠地扩展。如果某个特定内容非常受欢迎,那么您的某个集线器将会严重超载,而其他集线器则处于空闲状态。您可能希望研究一种更传统的负载平衡技术,它允许您通过简单地添加更多服务器来扩展。