websocket集群方案实战（非MQ）

本文websocket方案实现原理基于nginx代理，dubbo自定义负载均衡策略实现。

websocket

双向通信的特性，使得它常用来做及时通讯，聊天工具。

关于websocket的session

websocket的session比较特殊，可以认为是一个有状态的，当浏览器刷新，就会断掉，无法实现共享。相反httpsession基于cookie实现，只要cookie存在，httpsession就能实现共享。

集群方案

1、MQ广播形式:

因为websocket的session无法共享问题，使得集群方案有些特殊。大家最容易想到的是可以通过MQ 广播的形式，向集群每个节点发消息，然后每个节点判断是否有需要toUser，有的话就发送，没有的话就放弃消息。这种方式实现比较简单，但缺点也很明显：存在异步延迟。如果MQ消息积压的话就很坑，就算没积压，MQ本身也存在少许的延迟，另外每个节点拉取得消息种很多是无用的，比如2个人互相发websocket消息，两个人最多就连在2个不同的节点，如果用广播形式对每个节点发消息，无疑就是浪费资源（但其实也可以适当对消息分发加以设计）。

2、自定义负载均衡

集群节点互相调用时，常见的负载均衡 ：轮训、随机、hash等。无非是从节点中选择一个去调用。
对于websocket集群节点通信也可以这样实现。

本文讲述第二种实现方式

登录时用户所在的服务器写入redis，略。

自定义dubb负载均衡：

public class ChatLoadBalance extends RandomLoadBalance {
    @Override
    protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        Object to_user_server_ip = RpcContext.getContext().get("to_user_server_ip");
        if (to_user_server_ip == null) {
            return super.doSelect(invokers, url, invocation);
        }
        String toServerPort =to_user_server_ip.toString();
        for (Invoker<T> invoker : invokers) {
            String identifyString = invoker.getUrl().toIdentityString();