- 一致性哈希算法实现（本文的要点）
- spring cloud Finchley.RELEASE 版本中ribbon未完善的地方
- 后记
一致性哈希算法实现（本文的要点）
这种方法是本人认为最优雅的实现方案，理解这种方案需要一定的时间，如果你耐心看下去，相信你一定会有所收获。再强调一次，不了解一致性哈希算法的同学请先看这里，现先假设哈希环是顺时针查找的。
首先，想要将一致性哈希算法的思想应用到我们的websocket集群，我们需要解决以下新问题：
- 集群节点DOWN，会影响到哈希环映射到状态是DOWN的节点。
- 集群节点UP，会影响到旧key映射不到对应的节点。
- 哈希环读写共享。
在集群中，总会出现服务UP/DOWN的问题。
针对节点DOWN的问题分析如下：
一个服务器DOWN的时候，其拥有的websocket session会自动关闭连接，并且前端会收到通知。此时会影响到哈希环的映射错误。我们只需要当监听到服务器DOWN的时候，删除哈希环上面对应的实际结点和虚结点，避免让网关转发到状态是DOWN的服务器上。
实现方法：在eureka治理中心监听集群服务DOWN事件，并及时更新哈希环。
针对节点UP的问题分析如下：
现假设集群中有服务 CacheB上线了，该服务器的ip地址刚好被映射到key1和 cacheA之间。那么key1对应的用户每次要发消息时都跑去 CacheB发送消息，结果明显是发送不了消息，因为 CacheB没有key1对应的session。
此时我们有两种解决方案。
方案A简单，动作大：
eureka监听到节点UP事件之后，根据现有集群信息，更新哈希环。并且断开所有session连接，让客户端重新连接，此时客户端会连接到更新后的哈希环节点，以此避免消息无法送达的情况。
方案B复杂，动作小：
我们先看看没有虚拟节点的情况，假设 CacheC和 CacheA之间上线了服务器 CacheB。所有映射在 CacheC到 CacheB的用户发消息时都会去 CacheB里面找session发消息。也就是说 CacheB一但上线，便会影响到 CacheC到 CacheB之间的用户发送消息。所以我们只需要将 CacheA断开 CacheC到 CacheB的用户所对应的session，让客户端重连。
接下来是有虚拟节点的情况，假设浅色的节点是虚拟节点。我们用长括号来代表某段区域映射的结果属于某个 Cache。首先是C节点未上线的情况。图大家应该都懂吧，所有B的虚拟节点都会指向真实的B节点，所以所有B节点逆时针那一部分都会映射到B（因为我们规定哈希环顺时针查找）。
接下来是C节点上线的情况，可以看到某些区域被C占领了。
由以上情况我们可以知道：节点上线，会有许多对应虚拟节点也同时上线，因此我们需要将多段范围key对应的session断开连接（上图红色的部分）。具体算法有点复杂，实现的方式因人而异，大家可以尝试一下自己实现算法。
哈希环应该放在哪里？
- gateway本地创建并维护哈希环。当ws请求进来的时候，本地获取哈希环并获取映射服务器信息，转发ws请求。这种方法看上去不错，但实际上是不太可取的，回想一下上面服务器DOWN的时候只能通过eureka监听，那么eureka监听到DOWN事件之后，需要通过io来通知gateway删除对应节点吗？显然太麻烦了，将eureka的职责分散到gateway，不建议这么做。
- eureka创建，并放到redis共享读写。这个方案可行，当eureka监听到服务DOWN的时候，修改哈希环并推送到redis上。为了请求响应时间尽量地短，我们不可以让gateway每次转发ws请求的时候都去redis取一次哈希环。哈希环修改的概率的确很低，gateway只需要应用redis的消息订阅模式，订阅哈希环修改事件便可以解决此问题。
至此我们的spring websocket集群已经搭建的差不多了，最重要的地方还是一致性哈希算法。现在有最后一个技术瓶颈，网关如何根据ws请求转发到指定的集群服务器上？
答案在负载均衡。spring cloud gateway或zuul都默认集成了ribbon作为负载均衡，我们只需要根据建立ws请求时客户端发来的user id，重写ribbon负载均衡算法，根据user id进行hash，并在哈希环上寻找ip，并将ws请求转发到该ip便完事了。流程如下图所示：
接下来用户沟通的时候，只需要根据id进行hash，在哈希环上获取对应ip，便可以知道与该用户建立ws连接时的session存在哪台服务器上了！
spring cloud Finchley.RELEASE 版本中ribbon未完善的地方
题主在实际操作的时候发现了ribbon两个不完善的地方......
- 根据网上找的方法，继承AbstractLoadBalancerRule重写负载均衡策略之后，多个不同应用的请求变得混乱。假如eureka上有两个service A和B，重写负载均衡策略之后，请求A或B的服务，最终只会映射到其中一个服务上。非常奇怪！可能spring cloud gateway官网需要给出一个正确的重写负载均衡策略的demo。
- 一致性哈希算法需要一个key，类似user id，根据key进行hash之后在哈希环上搜索并返回ip。但是ribbon没有完善choose函数的key参数，直接写死了default！
难道这样子我们就没有办法了吗？其实还有一个可行并且暂时可替代的办法！
如下图所示，客户端发送一个普通的http请求（包含id参数）给网关，网关根据id进行hash，在哈希环中寻找ip地址，将ip地址返回给客户端，客户端再根据该ip地址进行ws请求。
由于ribbon未完善key的处理，我们暂时无法在ribbon上实现一致性哈希算法。只能间接地通过客户端发起两次请求（一次http，一次ws）的方式来实现一致性哈希。希望不久之后ribbon能更新这个缺陷！让我们的websocket集群实现得更优雅一点。
后记
以上便是我这几天探索的结果。期间遇到了许多问题，并逐一解决难题，列出两个websocket集群解决方案。第一个是session广播，第二个是一致性哈希。
这两种方案针对不同场景各有优缺点，本文并未用到ActiveMQ，Karfa等消息队列实现消息推送，只是想通过自己的想法，不依靠消息队列来简单地实现多用户之间的长连接通讯。希望能为大家提供一条不同于寻常的思路。
