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