我知道这是旧的，但仍然有几个问题要回答。首先，简单性和潜在的“如何”。在这个例子中，OP给出的通常不是我认为的“唯一事件订阅”，而是一个频道用于许多事件。这确实取决于用例和规模问题。我假设典型的用例是创建一个内部单通道事件侦听方法将是最好的。基本上，传递的消息是事件类型，数据存储在事件模型中（不是laravel的，而是专有的）。这样做的主要优点是，你可以利用枚举，灵活性等。同时保持简单性。然而，第二个想法是定价和这样的...
第二个想法是，即使在这个被发布的时候，在给定的例子中，pusher也对允许并发和主动监听由PersonA驱动的套接字的用户数量有一个上限。我认为这个数字是100。虽然我的第一点可能会保持一个简单的内部方法，成本确实发挥了作用。因此，即使pusher没有限制活跃的并发用户，生成和发送的事件数量也与活跃用户的数量相关联。因此，如果一个用户不是太受欢迎，只有3个追随者，但10万人在该活动套接字上更新3人的成本10万消息在计费方面。我将分享一个图像来证实这个想法...

最后一点，自从OP最初提出他们的问题以来已经解决的是引入存在渠道。给予通过耳语等来显示活动的能力。它们也更多地基于或面向共享订阅的“实体”数据信息，如用户或企业等。而不是为处理带有数据的消息/事件类型而构建，并使用实时学习的数据处理这些响应。（我说的最后一行奇怪的是，如果数据可以在DB或后端找到，它减少了驱动器和对实时通知或广播事件的需求。
其他可能具有不同规则的广播替代方案是BeyondCode WebSocket Server（https://github.com/beyondcode/laravel-websockets），Ably（https://ably.com/）和Soketi（https://docs.soketi.app/）。也可以在www.example.com上找到其他人https://laravel.com/docs/10.x/broadcasting#open-source-alternatives

实时可扩展功能实现

概述

在我们的应用程序中，我们正在使用Pusher实现实时通知功能。此功能旨在当用户收到由其关注的其他用户所采取的操作触发的通知时自动通知用户。

问题陈述

我们面临着如何处理通知的广播通道的挑战，特别是在用户关注其他用户的情况下。具体地，该场景涉及用户A具有许多关注者并且还关注许多其他用户。当用户A发布新内容时，需要向用户A的所有关注者广播通知。

考虑的方法

选项一：跨跟随者频道动态广播

优点：

• 每个用户只订阅他们特定的关注用户的频道。
• 广播是有针对性的，减少了不必要的流量。

缺点：

• 动态通道创建和管理可能很复杂。
• 对于有很多追随者的用户来说，大量的频道可能会导致可扩展性问题。

选项二：用户收听多个频道

优点：

• 用户订阅他们感兴趣的频道时，更方便的频道管理。
• 使用较少的通道可能更容易处理可伸缩性。

缺点：

• 增加了用户的流量，因为他们需要收听多个频道。
• 广播可能需要在客户端进行过滤，以确保用户只接收相关通知。

建议

*评估您的用例：

• 考虑每个用户的平均关注者数量和潜在的可扩展性挑战。
  *混合方法：
• 考虑一种混合方法，其中用户根据他们的兴趣收听有限数量的频道。
  *实现通道组：
• 将频道组织成逻辑组（例如，“followers.userA”）以简化管理。
  *优化客户端过滤：
• 实施高效的客户端过滤，确保用户只收到相关通知。
  *负载测试和监控：
• 执行负载测试，以确保系统可以处理预期的流量。
• 实施监控以跟踪性能并根据实际使用模式调整方法。

总结

最有效的方法取决于应用程序的特定要求和约束。在测试环境中对这两个选项进行试验，以评估它们的性能和用户体验。