上万socket的连接用的方案和技术？netty？分布式？越详细越好。

Netty提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。 也就是说，Netty 是一个基于NIO的客户，服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。

Netty是一个基于NIO的服务器端（简化TCP/UDP的socket开发）。

java 写道Web Services是由企业发布的完成其特定商务需求的在线应用服务,其他公司或应用软件能够通过Internet来访问并使用这项在线服务。实际上，WebService的主要目标是跨平台的可互操作性。为了达到这一目标，WebService完全基于XML（可扩展标记语言）、XSD（XMLSchema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。由此可以看出，在以下三种情况下，使用WebService会带来极大的好处。

即提供第三方可使用服务（可以基于http/tcp等）。

servlet：是服务器端执行的小应用程序，是一个服务器组件，比如HttpServlet 用于实现对Http请求的处理，接受请求 处理、动态产生响应。

三者关注点不同：

netty 提供一套基于NIO的服务器的框架（简化TCP/UDP的socket开发），类似的还有mina。 比如实现一个web服务器。

web service 重点是web服务，建立一套规则，使得跨平台/跨应用可可访问。比如天气预报接口、google Map接口等。

关于IO会涉及到阻塞、非阻塞、多路复用、同步、异步、BIO、NIO、AIO等几个知识点。知识点虽然不难但平常经常容易搞混，特此Mark下，与君共勉。

阻塞IO情况下，当用户调用 read 后，用户线程会被阻塞，等内核数据准备好并且数据从内核缓冲区拷贝到用户态缓存区后 read 才会返回。可以看到是阻塞的两个部分。

非阻塞IO发出read请求后发现数据没准备好，会继续往下执行，此时应用程序会不断轮询polling内核询问数据是否准备好，当数据没有准备好时，内核立即返回EWOULDBLOCK错误。直到数据被拷贝到应用程序缓冲区，read请求才获取到结果。并且你要注意！这里最后一次 read 调用获取数据的过程，是一个同步的过程，是需要等待的过程。这里的同步指的是 内核态的数据拷贝到用户程序的缓存区这个过程 。

非阻塞情况下无可用数据时，应用程序每次轮询内核看数据是否准备好了也耗费CPU，能否不让它轮询，当内核缓冲区数据准备好了，以事件通知当机制告知应用进程数据准备好了呢？应用进程在没有收到数据准备好的事件通知信号时可以忙写其他的工作。此时 IO多路复用 就派上用场了。

IO多路复用中文比较让人头大，IO多路复用的原文叫 I/O multiplexing，这里的 multiplexing 指的其实是在单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流 发明它的目的是尽量多的提高服务器的吞吐能力。实现一个线程监控多个IO请求，哪个IO有请求就把数据从内核拷贝到进程缓冲区，拷贝期间是阻塞的！现在已经可以通过采用mmap地址映射的方法，达到内存共享效果，避免真复制，提高效率。

像 select、poll、epoll 都是I/O多路复用的具体的实现。

select是第一版IO复用，提出后暴漏了很多问题。

poll 修复了 select 的很多问题。

但是poll仍然不是线程安全的， 这就意味着不管服务器有多强悍，你也只能在一个线程里面处理一组 I/O 流。你当然可以拿多进程来配合了，不过然后你就有了多进程的各种问题。

epoll 可以说是 I/O 多路复用最新的一个实现，epoll 修复了poll 和select绝大部分问题， 比如：

横轴 Dead connections 是链接数的意思，叫这个名字只是它的测试工具叫deadcon。纵轴是每秒处理请求的数量，可看到epoll每秒处理请求的数量基本不会随着链接变多而下降的。poll 和/dev/poll 就很惨了。但 epoll 有个致命的缺点是只有 linux 支持。

比如平常Nginx为何可以支持4W的QPS是因为它会使用目标平台上面最高效的I/O多路复用模型。

然后你会发现上面的提到过的操作都不是真正的异步，因为两个阶段总要等待会儿！而真正的异步 I/O 是内核数据准备好和数据从内核态拷贝到用户态这两个过程都不用等待。

很庆幸，Linux给我们准备了 aio_read 跟 aio_write 函数实现真实的异步，当用户发起aio_read请求后就会自动返回。内核会自动将数据从内核缓冲区拷贝到用户进程空间，应用进程啥都不用管。

我强力推荐C++后端开发免费学习地址：C/C++Linux服务器开发/后台架构师零声教育-学习视频教程-腾讯课堂

同步跟异步的区别在于 数据从内核空间拷贝到用户空间是否由用户线程完成 ，这里又分为同步阻塞跟同步非阻塞两种。

我们以同步非阻塞为例，如下可看到，在将数据从内核拷贝到用户空间这一过程，是由用户线程阻塞完成的。

可发现，用户在调用之后会立即返回，由内核完成数据的拷贝工作，并通知用户线程，进行回调。

在Java中，我们使用socket进行网络通信，IO主要有三种模式，主要看 内核支持 哪些。

同步阻塞IO ，每个客户端的Socket连接请求，服务端都会对应有个处理线程与之对应，对于没有分配到处理线程的连接就会被阻塞或者拒绝。相当于是 一个连接一个线程 。

BIO特点 ：

常量：

主类：

服务端监听线程：

服务端处理线程：

客户端：

同步非阻塞IO之NIO ：服务器端保存一个Socket连接列表，然后对这个列表进行轮询，如果发现某个Socket端口上有数据可读时说明读就绪，则调用该socket连接的相应读操作。如果发现某个 Socket端口上有数据可写时说明写就绪，则调用该socket连接的相应写操作。如果某个端口的Socket连接已经中断，则调用相应的析构方法关闭该端口。这样能充分利用服务器资源，效率得到了很大提高，在进行IO操作请求时候再用个线程去处理，是 一个请求一个线程 。Java中使用Selector、Channel、Buffer来实现上述效果。

每个线程中包含一个 Selector 对象，它相当于一个通道管理器，可以实现在一个线程中处理多个通道的目的，减少线程的创建数量。远程连接对应一个channel，数据的读写通过buffer均在同一个 channel 中完成，并且数据的读写是非阻塞的。通道创建后需要注册在 selector 中，同时需要为该通道注册感兴趣事件（客户端连接服务端事件、服务端接收客户端连接事件、读事件、写事件）， selector 线程需要采用 轮训 的方式调用 selector 的 select 函数，直到所有注册通道中有兴趣的事件发生，则返回，否则一直阻塞。而后循环处理所有就绪的感兴趣事件。以上步骤解决BIO的两个瓶颈：

下面对以下三个概念做一个简单介绍，Java NIO由以下三个核心部分组成：

channel和buffer有好几种类型。下面是Java NIO中的一些主要channel的实现：

正如你所看到的，这些通道涵盖了UDP和TCP网络IO，以及文件IO。以下是Java NIO里关键的buffer实现：

在微服务阶段，一个请求可能涉及到多个不同服务之间的跨服务器调用，如果你想实现高性能的PRC框架来进行数据传输，那就可以基于Java NIO做个支持长连接、自定义协议、高并发的框架，比如Netty。Netty本身就是一个基于NIO的网络框架， 封装了Java NIO那些复杂的底层细节，给你提供简单好用的抽象概念来编程。比如Dubbo底层就是用的Netty。

AIO是异步非阻塞IO，相比NIO更进一步，进程读取数据时只负责发送跟接收指令，数据的准备工作完全由操作系统来处理。

推荐一个零声教育C/C++后台开发的免费公开课程，个人觉得老师讲得不错，分享给大家：C/C++后台开发高级架构师，内容包括Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等技术内容，C/C++Linux服务器开发/后台架构师零声教育-学习视频教程-腾讯课堂 立即学习

原文：阻塞、非阻塞、多路复用、同步、异步、BIO、NIO、AIO 一锅端

[解决办法]

如果要确定包是一致性的，就用MD5做数据校验。

public void operationComplete(ChannelFuture future) {

}

这个地方是表示数据已经发送完毕。可以记录一些其他事情，比如日志。

发送完毕后，有新数据响应仍然走 Handler原来的流程。在这里面应该无法读取到响应数据。

（如果服务器同时向多个客户端，连续发送多条指令，每个不同的指令返回的数据不同，那么怎么确定该包为某一指令发出得到的数据）

这个地方 如果是多个客户端，那么每个客户端的ID是唯一的，netty里面有唯一ID号标示请求的唯一性。

还有一种方法是 发送请求时带一个唯一ID号，响应数据时也是带一个唯一ID号，这个唯一ID号就能确保客户端与服务器端的包是否一致性问题。

[解决办法]

Netty用的是NIO，是异步的，即你发送消息给Server后就不用等了，一边玩会去（传统的Socket是一直阻塞在这里等Server消息来，消息不到就一直等）。

等会Server发消息过来后会通知你消息到了，然后你再处理消息。

HttpRequestHandler -- HTTP请求处理类

TextWebSocketFrameHandler -- 对应Text消息的处理类

WebSocketServer -- 系统主类

WebSocketServerInitializer -- 服务主程序的初始化类

WebSocketServer 类代码：

import ionettybootstrapServerBootstrap;

import ionettychannelChannelFuture;

import ionettychannelChannelOption;

import ionettychannelEventLoopGroup;

import ionettychannelnioNioEventLoopGroup;

import ionettychannelsocketnioNioServerSocketChannel;

public final class WebSocketServer {

private int port = 0;

public WebSocketServer(int port) {

thisport = port;

}

public void run() throws Exception {

EventLoopGroup bossGroup = new NioEventLoopGroup();

EventLoopGroup workerGroup = new NioEventLoopGroup();

try {

ServerBootstrap b = new ServerBootstrap();

bgroup(bossGroup, workerGroup)

channel(NioServerSocketChannelclass)

childHandler(new WebSocketServerInitializer())

option(ChannelOptionSO_BACKLOG, 128)

childOption(ChannelOptionSO_KEEPALIVE, true);

Systemoutprintln("WebsocketChatServer 启动了");

// 绑定端口，开始接收进来的连接

ChannelFuture f = bbind(port)sync();

// 等待服务器 socket 关闭 。在这个例子中，这不会发生，但你可以优雅地关闭你的服务器。

fchannel()closeFuture()sync();

} finally {

workerGroupshutdownGracefully();

bossGroupshutdownGracefully();

Systemoutprintln("WebsocketChatServer 关闭了");

}

}

引用来自“预兆师”的答案

引用来自“石头哥哥”的答案

嗯 channel实际就是一个客户端和server的一个抽象的管道 ，netty封装了网络的底层 所以 你不必太多去掀开一些它封装的东西来处理 对于还不熟悉的开发者来讲的 话；你可以这样处理 在连接上来的时候 你创建一个session会话来持有这个channel ，每一个session有一个ID ，那么 你在业务层就可以通过这个ID拿到session 从而将这个数据发送出去，你这里 其实在服务器端就是sessionA sessionB ,A,B两个客户端连接服务器了 ，那么 就创建sessionA sessionB ，并产生一个ID （ID 保持唯一就可以了），A向B发送，那么实际就是通过服务器来转发A的消息到B，那么你必然拿到B的ID，几在A的消息中发送B的ID，这样就可以拿到sessionB ，然后channelwrite(); 消息的转发 与消息的推送 关键就在与知道sessionID，顺利得到相应的session 这样就可以解决问题了；

创建session的位置在channelActive(ChannelHandlerContext ctx)；标记channel的方式很多 ，上面的和你描述的一样 只是 封装了一个session来持有channel罢了；

谢谢你的回复。

你的回复里面没有提到如何绑定用户和channel的对应关系。我对此的大致想法是这样的：客户端与服务端建立连接的时候，也就是在channelActive(ChannelHandlerContext ctx)，服务端用RSA算法生成一对公私钥，并把公钥返回给客户端；客户端使用公钥加密登录信息发送到服务器，服务器解密后，将用户信息与channel对应起来，记录在链表里面。然后当A发送信息给B的时候，服务器从链表里面找到B的信息，并通过B对应的channel传送信息给B。

不知我这样的连接流程有没有问题，请指教。

ID--session--channel 它们是一一对应的， map<ID,session>;

class session{

ID;//session持有ID

channel;//session持有channel

}

任何一个客户端链接上来，你就把服务器现在在线的ID同步给链接上来的客户端，这样就好像是qq，向谁发送？ 只需 ID（目标）+message； 额 你这个是可以的 变相的其实本质一样 ，ID 就是一个纽带；

出现await返回null的情况，可能有以下几种原因：

消息传输中断：客户端发送的请求没有到达服务端或服务端响应没有返回客户端，导致解码器无法接收到完整的消息数据。

解码器错误：解码器在处理消息时出现错误，导致解析消息数据失败，无法返回正确的数据结果。

消息丢失：消息在传输过程中被丢失或被篡改，导致解码器无法正确解析消息。

针对这些情况，您可以考虑以下解决方法：

检查消息传输：确认客户端和服务端之间的网络连接是否正常，是否有中断或延迟等问题。可以使用网络调试工具，如Wireshark等，来捕获和分析数据包，确定数据是否被正确传输。

检查解码器：检查解码器的实现是否正确，确认解码器是否能够正确处理消息数据。可以在解码器中添加日志输出，输出解析过程中的关键数据，帮助排查问题。

增加消息确认机制：可以在客户端和服务端之间增加消息确认机制，确认消息是否被正确接收。可以使用ACK机制、消息重传等方法，保证消息的可靠传输。

增加数据校验：可以在消息中增加数据校验码，确保消息的完整性和正确性。可以使用CRC校验、MD5等方法，防止消息被篡改。总之，要解决await返回null的问题，需要从消息传输、解码器、消息确认和数据校验等方面进行全面排查和分析，找到问题的根本原因，并采取相应的措施进行解决。

首先 创建一个 bean 然后用Spring 加载那个bean ，这个bean 的ini方法 就是初始化netty的内容什么解码什么的 自定义处理类什么的，然后启动TOMCAT的时候默认 去加载他。就完事咯。

WebSocket是一种规范，是Html5规范的一部分，websocket解决什么问题呢？解决http协议的一些不足。我们知道，http协议是一种无状态的，基于请求响应模式的协议。

网页聊天的程序（基于http协议的），浏览器客户端发送一个数据，服务器接收到这个浏览器数据之后，如何将数据推送给其他的浏览器客户端呢？

这就涉及到服务器的推技术。早年为了实现这种服务器也可以像浏览器客户端推送消息的长连接需求，有很多方案，比如说最常用的采用一种轮询技术，就是客户端每隔一段时间，比如说2s或者3s向服务器发送请求，去请求服务器端是否还有信息没有响应给客户端，有就响应给客户端，当然没有响应就只是一种无用的请求。

这种长轮询技术的缺点有：

1）响应数据不是实时的，在下一次轮询请求的时候才会得到这个响应信息，只能说是准实时，而不是严格意义的实时。

2）大多数轮询请求的空轮询，造成大量的资源带宽的浪费，每次http请求携带了大量无用的头信息，而服务器端其实大多数都不关注这些头信息，而实际大多数情况下这些头信息都远远大于body信息，造成了资源的消耗。

拓展

比较新的技术去做轮询的效果是Comet。这种技术虽然可以双向通信，但依然需要反复发出请求。而且在Comet中，普遍采用的长链接，也会消耗服务器资源。

WebSocket一种在单个 TCP 连接上进行 全双工通讯 的协议。WebSocket通信协议于2011年被IETF定为标准RFC 6455，并被RFC7936所补充规范。WebSocket API也被W3C定为标准。

WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许 服务端主动向客户端推送数据 。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

websocket的出现就是解决了客户端与服务端的这种长连接问题，这种长连接是真正意义上的长连接。客户端与服务器一旦连接建立双方就是对等的实体，不再区分严格意义的客户端和服务端。长连接只有在初次建立的时候，客户端才会向服务端发送一些请求，这些请求包括请求头和请求体，一旦建立好连接之后，客户端和服务器只会发送数据本身而不需要再去发送请求头信息，这样大量减少了

网络带宽。websocket协议本身是构建在http协议之上的升级协议，客户端首先向服务器端去建立连接，这个连接本身就是http协议只是在头信息中包含了一些websocket协议的相关信息，一旦http连接建立之后，服务器端读到这些websocket协议的相关信息就将此协议升级成websocket协议。websocket协议也可以应用在非浏览器应用，只需要引入相关的websocket库就可以了。

HTML5定义了WebSocket协议，能更好的节省服务器资源和带宽，并且能够更实时地进行通讯。Websocket使用ws或wss的统一资源标志符，类似于HTTPS，其中wss表示在TLS之上的Websocket。如：

优点

浏览器页面向服务器发送消息，服务器将当前消息发送时间反馈给浏览器页面。

服务器端

服务器端初始化连接

WebSocketServerProtocolHandler ：参数是访问路径，这边指定的是ws，服务客户端访问服务器的时候指定的url是： ws://localhost:8899/ws 。

它负责websocket握手以及处理控制框架（Close，Ping（心跳检检测request），Pong（心跳检测响应））。 文本和二进制数据帧被传递到管道中的下一个处理程序进行处理。

桢 ：

WebSocket规范中定义了6种类型的桢，netty为其提供了具体的对应的POJO实现。

WebSocketFrame：所有桢的父类，所谓桢就是WebSocket服务在建立的时候，在通道中处理的数据类型。本列子中客户端和服务器之间处理的是文本信息。所以范型参数是TextWebSocketFrame。

自定义Handler

页面 ：

启动服务器，然后运行客户端页面，当客户端和服务器端连接建立的时候，服务器端执行 handlerAdded 回调方法，客户端执行 onopen 回调方法

服务器端控制台：

页面：

客户端发送消息，服务器端进行响应，

服务端控制台打印：

客户端也收到服务器端的响应：

打开开发者工具 ：

在从标准的HTTP或者HTTPS协议切换到WebSocket时，将会使用一种升级握手的机制。因此，使用WebSocket的应用程序将始终以HTTP/S作为开始，然后再执行升级。这个升级动作发生的确定时刻特定与应用程序；它可能会发生在启动时候，也可能会发生在请求了某个特定的IURL之后。

参考技术

java web 服务器推送技术--comet4j

Comet：基于 HTTP 长连接的“服务器推”技术