转载

Golang实现的分布式WebSocket微服务

使用流程

用Websocket客户端连接本服务，服务端会返回客户端一个唯一的client id，通过这个client id可以知道是哪个连接，客户端拿到这个id之后上报到服务端，服务端根据业务需求可以给这个长连接发送指定信息，或者绑定到分组。

分布式方案

维持大量的长连接对单台服务器的压力也挺大的，这里也就要求该服务需要可以扩容，也就是分布式地扩展。分布式对于可存储的公共资源有一套完整的解决方案，但对于WebSocket来说，操作对象就是每一个连接，它是维持在每一个程序中的。每一个连接不能存储起来共享、不能在不同的程序之间共享。所以我能想到的方案是不同程序之间进行通讯。

那么，怎样知道某个连接在哪个应用呢？答案是通过client id去判断。那么通过client id又是如何知道的呢？有以下几种方案：

一致性hash算法

一致性hash算法是将整个哈希值空间组织成一个虚拟的圆环，在redis集群中哈希函数的值空间为0-2^32-1（32位无符号整型）。把服务器的IP或主机名作为关键字，通过哈希函数计算出相应的值，对应到这个虚拟的圆环空间。我们再通过哈希函数计算key的值，得到一个在圆环空间的位置，按顺时针方向找到的第一个节点就是存放该key数据的服务器节点。

在没有节点的增减的时候，可以满足我们的需求，但如果此时一个节点挂掉了或者新增一个机器怎么办？节点挂点之后，会在圆环上删除节点，增加节点则反之。这时候按顺时针方向找的数据就不准确，在某些业务上来说可以接受，但在WebSocket微服务上来说，影响范围内的连接会断掉，如果要求没那么高，客户端再进行重连也可以。
hash slot（哈希槽）

服务器的IP或者主机名作为key，对每个key进行计算CRC16值，然后对16384进行取模，得出一个对应key的hash slot。
```
HASH_SLOT = CRC16(key) mod 16384
```
我们根据节点的数量，给每个节点划分范围，这个范围是0-16384。hash slot的重点就在这个虚拟表，key对应的hash slot是永不变的，增减节点就是维护这张虚拟表。

以上两种方案都可以实现需求，但一致性hash算法的方案会使部分key找到的节点不准确；hash slot的方案需要维护一张虚拟表，在实现起来需要有一个功能去判断服务器是否挂了，然后修改这张虚拟表，新增节点也一样，在实现起来会遇到很多问题。

然后我采取的方案是，每个连接都保存在本应用，然后用redis的key value记录每个连接client id对应的服务器IP和端口。对指定client id进行操作时，去redis找出响应的ip和端口，判断是否为本机，不是本机的话进行RPC通讯告诉相应的程序。长连接的连接数据不可迁移，程序挂掉了相应的连接也就挂了，在该程序上的连接也就断开了，这时重连的话会找到另一个可用的程序。