话不多说，这就开始吧…

最近公司在做saas平台，其中涉及到重构一个无人机项目。无人机推流拉流用了腾讯云直播、点播功能。安卓端集成了大疆的sdk，需要在飞无人机的时候一直推送飞行信息(比如飞行高度，飞行路线、风向什么的)。
之前用的tomcat自带的websocket,spring-boot-starter-websocke集成，但是性能可能有点问题。这次重构，打算换成netty。因为是saas化服务，领导还要求可集群部署，这里提供一种解决方案----redis的pub、sub（当然大型项目最好还是zk）。

1. 跨服务之间案例采用redis的发布和订阅进行传递消息。多个实例监听同一个channel。客户端上线存入redis，下线清除redis。
2. 用户A在发送消息给用户B时候，需要传递B的channeId，以用于服务端进行查找channeId所属是否自己的服务内。
3. 若本次channel在A实例的本地缓存中能找到，说明属于自己服务，直接发送。若不在，则通过redis的pub到其他服务实例，其他实例监听到消息之后，判断这个channel是否在本地，在就发送。

当然，redis 的pub sub本身也是有缺陷的，比如： 数据可靠性无法保证、扩展性差、资源消耗高，如果是正式比较大型的可以换成zk，思路差不多。

 
 
 
 
 
# 用户管道信息；记录某个用户分配到某个服务端
 
 
 
 

WebSocketController.java 控制层，开启、关闭netty，查看服务端、用户管道列表(其实这里可以根据业务逻辑，项目启动时候就启动netty，也不一定非要调接口开启)

可以用index页面，也可以直接 在线测试

启动2个实例,，分别调用接口开启netty服务端，连接上线，触发上线事件，便会在redis和缓存中存入信息。然后在线测试

怕有心人，每天积累一点点，fighting！！！

当管理大系统时，的问题一直是一个热点话题。负载均衡的目的是最优化资源使用，最大化吞吐量，最小化响应时间，避免任何单一资源的过载，因而解决这个问题对性能表现是很关键的。在本文中我们将看一看针对这个问题的一些解决方法。

为了更好的理解WS负载均衡，让我们深入了解一下TCP套接字的背景知识。默认地，一个单独的服务器可以处理65536个套接字连接，因为65536是可用的最大的TCP端口数。因此，既然WS连接拥有TCP的特性，每个WS客户端占用一个端口，我们可以肯定地说WebSocket的连接数目也是有限的。

事实上，这只说对了一半。对每个单独的IP地址，服务器都可以处理65536个套接字。因而通过向服务器上添加额外的网络接口，就很容易扩展那个数量。与此同时，去追踪服务器上现有多少链接是极其重要的。一旦超出了限制范围，你会遇到很多关于TCP连接的问题（例如，此时不可能通过ssh去连接到一个服务器）。因而，在你的应用程序代码中限制每个节点的WS连接数是很好的主意。当我们处理WebSockets问题时也会在我们的apps中使用一样的思路。

一旦我们理解了主要的限制条件，以及解决方式之后，让我们开始考虑负载均衡。下面我将描述在我们自己的项目中试过的三种方式。请注意所有的系统部分都是部署在AWS上的，其中的一些技巧和提示只适用于Amazon配置。

实现负载均衡最简单的办法是直接使用AWS提供的方法。从ELB切换到TCP模式是很容易的，这就使得任何类型的TCP连接的负载均衡成为可能, 包括WebSockets。这个方法有如下特性：

• 负载均衡节点的自动伸缩；

基本上，对大多数情况而言它是一个很好的解决方案，在你遇到负载飞溅的增长情况之前。在这种情况下，ELB运行的很慢以至于无法建立新的连接。可以去联系Amazon，告诉他们去“预热（pre-warm）”ELB，但是它对我们不是一个好的选项，基于负载测试的目的，当我们需要快速建立成千上万的WS连接时；对客户也不是好选项，基于系统的可用性。

我们曾经试过使用HAProxy作为一个负载均衡器。但是为了使HAProxy正确工作我们需要考虑上文讨论的端口限制问题。为了使HAProxy能够处理超过65536个链接，我们需要执行下面步骤：