Laravel 事件动态频道名称

Question

我正在我的应用程序中创建一个实时通知功能，该功能将使用 Pusher 在用户收到通知时自动通知用户（通知是由他们关注的用户采取的某些操作创建的）。

我知道如何设置事件并广播它，但我对广播这些通知的频道感到困惑。情况是用户 A 关注了许多其他用户，但他自己也有很多关注者。

如果用户 A 发布了新内容，我们可以触发一个事件，向他的所有关注者广播他刚刚发布了内容的通知。这里的问题是，我们是否在“user.A”上广播这个频道？这意味着关注用户 A 的每个其他用户都必须始终订阅该频道以及他们关注的每个其他用户的频道。

那么，更有效的是，在可能数百个不同的频道（每个频道代表用户 A 的关注者之一）上动态广播，或者每个用户应该自动收听可能数百个不同用户的频道？

不确定哪个更有效率。谢谢！

Answer 1

我知道这已经很旧了，但是仍有一些问题需要回答。首先，简单性和潜在的“操作方法”。在这个例子中，OP通常给出的不是我所认为的“唯一事件订阅”与许多事件的一个通道之类的东西。这确实取决于用例和规模问题。我认为典型的用例是创建内部单通道事件监听方法是最好的。基本上传递的消息是事件类型，数据存储在事件模型中（不是 Laravel 的，而是专有的）。这样做的主要优点是您可以利用枚举、灵活性等，同时保持简单性。然而，第二个想法是定价等......

第二个想法是，即使从发布此消息的时间起，推送器也对允许在给定示例中的 PersonA 驱动的套接字上并发和主动侦听的用户数量设置了上限。我相信这个数字是 100。虽然我的第一点可能会保持更简单的内部方法，但成本确实是一个因素。因此，即使推送器没有限制活动并发用户数，生成和发送的事件数量也会与活动用户数量相关。因此，如果一个用户不太受欢迎并且只有 3 个关注者，但该活动套接字上有 10 万个人更新 3 个人，则在计费方面需要花费 10 万条消息。我将分享一张图片来证实这个想法......

最后一点，自OP最初提出问题以来已经解决，是引入存在通道。它们能够通过耳语等方式显示活动。它们也更基于或适合于共享订阅的“实体”数据信息，例如用户或业务等......而不是为使用数据和处理来处理消息/事件类型而构建这些响应是通过实时学习的数据进行的。 （我奇怪地指出最后一行要记住，如果可以在数据库或后端中找到数据，它会减少实时通知或广播事件的驱动和需求。

可能具有不同规则的其他广播替代方案包括 BeyondCode WebSocket Server (https://github.com/beyondcode/laravel-websockets)、Ably (https://abilly.com/) 和 Soketi () https://docs.soketi.app/）。还可以找到其他内容https://laravel.com/docs/10.x/broadcasting#open-source-alternatives