How should I implement a websocket pool using Go?

<p>I&#39;ve not done something like this outside of JS, where it&#39;s all about events, and I&#39;m a little unsure of what best practices would be. I&#39;d really appreciate any more experienced Go users who could offer some advice.</p> <p>I&#39;m writing an application where users can add friends, and then their activities are broadcast to their friends over a websocket connection. </p> <p>I want to account for the fact that a user might be logged in to multiple sessions at once. So my first thought was that I could store all the connections in a map where the keys are user IDs, and the values are arrays/slices of <code>websocket.Conn</code>s. When a user dispatches a message, the server would do something like</p> <pre><code>for _, userID := range user.Friends { for _, conn := range pool[userID] { // conn.WriteJSON etc } } </code></pre> <p>When a user logs in, the server would check if the pool already has a key with their user ID, and if so, it&#39;d <code>append(pool[userID], &amp;newConn)</code>, and if not, <code>pool[userID] = []*websocket.Conn{&amp;newConn}</code>.</p> <p>My first concern with that is that this would be a global variable potentially being modified by multiple threads/goroutines at once, and the regular map isn&#39;t safe for concurrent use. I looked into the new map structure in the sync package, but I&#39;m not sure whether to use it, because it warns that it&#39;s slower and not type safe relative to a normal map with a mutex. So should I just be using a mutex?</p> <p>My other area of uncertainty is in how to implement the websocket listeners themselves. Right now, I have a regular HTTP HandleFunc that upgrades the HTTP request to a websocket connection, then does an infinite <code>for</code> loop listening for messages coming through. This is a goroutine per session, right, HandleFuncs create a new goroutine? Is that a reasonable/smart way to handle this?</p> <hr/>**评论：**<br/><br/>wybiral: <pre><p>As far as the concurrent map situation goes I&#39;d use a mutex. It&#39;s also really common to see people using channels to coordinate stuff like this but imo that can quickly get messy. If you look at the Go standard library code this is the kind of thing where a mutex tends to be used because it&#39;s more concise and efficient.</p> <p>Using the sync.Map implementation seems messier to me because it loses the type safety by being defined as empty interfaces. Yuck.</p> <p>If, however, you find yourself adding more state changes like this it might make sense to have one goroutine process them all and then communicate with that goroutine using channels as a form of internal API to synchronize those changes. But given your current problem I&#39;d vote on using a mutex.</p> <p>For websocket connects I would suggest Gorilla Websockets: <a href="http://www.gorillatoolkit.org/pkg/websocket" rel="nofollow">http://www.gorillatoolkit.org/pkg/websocket</a></p></pre>ChurroLoco: <pre><p>I agree with the mutex approach above. It will be simple and efficient. You may also want to limit the number of connections the server holds so that the limit is more is more predictable. </p> <p>If you have to scale beyond one web server I suggest using something like Redis to keep track of which instance has a web socket connection to each user. </p></pre>Skylis: <pre><p>Benchmark your workload and see what&#39;s the best.</p> <p>There are multiple ways to do it, and it depends on what you&#39;re doing which way will perform optimally.</p></pre>