What are the strategies for Pusher channel structures in social status update applications?

问题

When building a social application it's common to follow other users or topics as an indication of interest in updates by the user or topic. For example, following other users on Twitter, Friending other people on Facebook or liking a product or brand on Facebook.

Pusher has the concept of channels that you subscribe to. Channels are a human readable string that provide a logical identifier to information (e.g. "some-channel-name") and therefore seems to naturally suggest that in a social application any updates on a user or topic should be sent on a channel specific to that item (e.g. "userX-status-updates" or "myBrand-status-updates").

However, this raises concerns about how efficient it is to subscribe to multiple channels if a user is following a high number of other users or topic.

Therefore, what are the appropriate strategies for structuring channels in an social status update style application that uses Pusher?

回答1:

The first thing to clarify is that you need a mapping of who you are following so for the purposes of this answer I'm going to assume that it's stored in a DB on the server. It also assumed that status updates are triggered as follows:

1. Client (userX posts status update) -> Your Server (sanitize & validate)
2. Your Server -> Pusher
3. Pusher -> Clients (users interested in updates from UserX)

There are two possible solutions to the channel information architecture problem:

1. Channel Per User Status: A user subscribes to a userX-status-updates channel for all the users that they follow and users trigger update events on their own status update channel.
2. Users I'm Following Channel: When a user posts a status update you look up who is following that user and publish the update on a users-you-follow-updates channel.

Strategy 1. is the most optimal solution as it keeps interactions with your own infrastructure an Pusher to a minimum.

Here's the detail on these two strategies:

1. Channel Per User Status

The assumption here is that subscribing to channels is costly but that not entirely correct. Channels are simply a way of routing events. However, if you are using authenticated channels (private & presence) you need to authenticate the subscription via your own server. If you use the Pusher WebSocket libraries "out of the box" each subscription will result in a request to your server. So, a user is following 1,000 users that's 1,000 requests to your server.

But, for the pusher-js library there is a multi-auth plugin that can batch the authentication requests into a single call.

There is also a BatchAuthorizer for the Pusher WebSocket Java library, but it's only a sample solution to this scenario.

2. Users I'm Following Channel

Note: although this is an option it's probably only appropriate for smaller numbers of users

In this scenario a user sends their status update to the server, the server performs a lookup of which users are interested in the update and triggers and update even on a channel for each interested user.

For example, give users UserA, UserB and UserC each of those users will subscribe to their own update channel; UserA-followers-updates, UserB-followers-updates, and UserC-followers-updates respectively. If each of these users follows UserZ then when UserZ makes as status update that update is published on each of those channels.

This may also sound inefficient, however it is possible to trigger the same event on 10 channels at a time. So in the above example it would only require one call to the Pusher HTTP API to send the status update to all interested users. More information on multi-channel event publishing here.

来源：https://stackoverflow.com/questions/30353113/what-are-the-strategies-for-pusher-channel-structures-in-social-status-update-ap