Laravel 事件动态频道名称

Question

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

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

如果用户A发布新内容，我们可以触发一个事件，向他的所有粉丝广播一条通知，告诉他们他刚刚发布了一些东西。问题是，我们应该在"user.A"上广播这个频道吗？这意味着每个关注用户A的其他用户都必须始终订阅该频道以及他们关注的每个其他用户的频道。

那么，什么更有效率，动态地跨可能数百个不同的频道进行广播（每个频道代表用户A的一个粉丝），还是每个用户自动监听可能数百个不同用户的频道？

不确定哪种方式更有效率。谢谢！

- Matt Pierce

Answer 1

我知道这是旧的，但仍有一些问题需要回答。首先，简单性和潜在的“如何”。在例子中，OP通常给出的是一个“唯一事件订阅”而不是一个频道用于多个事件。这取决于使用情况和规模问题。我认为，在典型的使用情况下，创建一个内部单一频道的事件监听方法是最好的选择。基本上，传递的消息是事件类型，数据存储在事件模型中（不是laravel的，而是专有的）。这样做的主要优势是可以利用枚举、灵活性等等，同时保持简单性。然而，第二个考虑因素是定价等等...

其实，自从这篇文章发布以来，Pusher对于由PersonA驱动的套接字并发和活跃监听的用户数量有了限制。我相信这个数字是100。虽然我的第一个观点可能维持了一个更简单的内部方法，但成本确实是一个因素。所以即使Pusher没有限制活跃并发用户的数量，生成和发送的事件数量也与活跃用户的数量相关。因此，如果一个用户不太受欢迎，只有3个关注者，但有10万人在该活跃套接字上更新这3个人，那么在计费方面就需要发送10万条消息。我将分享一张图片来证实这个想法...

最后一个问题，自从OP最初提出问题以来已经解决的是引入了presence channels。它们可以通过耳语等方式显示活动。它们更多地基于或针对订阅的“实体”数据信息进行共享，例如用户或企业等...与实时学习的数据处理消息/事件类型不同。 （我用奇怪的方式表达了最后一句话，以便记住如果数据可以在数据库或后端找到，那么减少了实时通知或广播事件的驱动和需求）。

其他广播的替代方案可能有不同的规则，如BeyondCode WebSocket Server（https://github.com/beyondcode/laravel-websockets），Ably（https://ably.com/）和Soketi（https://docs.soketi.app/）。还可以在https://laravel.com/docs/10.x/broadcasting#open-source-alternatives找到其他替代方案。

- amac