Socket分片:基于Netty的Java实现

Socket分片:基于Netty的Java实现

最近Nginx发布了1.9.1版，其中一个新的特性就是支持socket的 SO_REUSEPORT 选项。这个socket的SO_REUSEPORT选项已经有许多现实世界的应用。对NGINX而言，它通过将连接均衡的分给多个进程以提升性能。SO_REUSEPORT已经在一些操作系统上实现了支持。这个选项允许多个socket监听同一个IP地址+端口。内核负载均衡这些进来的sockets连接，将这些socket有效的分片。

尽管Java很早就有一个特性请求： JDK-6432031 ，但是时至今日，Oracle JDK依然不支持这个选项，因此我们只能通过 hack 的方式在Java中使用此特性。

Google已经在内部服务器中开启了这个特性：

SO_REUSEPORT

Scaling Techniques for Servers with High Connection Rates

SO_REUSEPORT

就像聂永的博客中所说：

运行在Linux系统上网络应用程序，为了利用多核的优势，一般使用以下比较典型的多进程/多线程服务器模型：

• 单线程listen/accept，多个工作线程接收任务分发，虽CPU的工作负载不再是问题，但会存在：
  • 单线程listener，在处理高速率海量连接时，一样会成为瓶颈
  • CPU缓存行丢失套接字结构(socket structure)现象严重
• 所有工作线程都accept()在同一个服务器套接字上呢，一样存在问题：
  • 多线程访问server socket锁竞争严重
  • 高负载下，线程之间处理不均衡，有时高达3:1不均衡比例
  • 导致CPU缓存行跳跃(cache line bouncing)
  • 在繁忙CPU上存在较大延迟

上面模型虽然可以做到线程和CPU核绑定，但都会存在：

• 单一listener工作线程在高速的连接接入处理时会成为瓶颈
• 缓存行跳跃
• 很难做到CPU之间的负载均衡
• 随着核数的扩展，性能并没有随着提升

SO_REUSEPORT 在*BSD平台早已经实现，而Linux平台则由谷歌工程师实现并于2013年正式纳入Linux的trunk (kernel 3.9)。

当前的操作系统支持情况：

• Linux: 内核自3.9开始支持此特性。因此Redhat 7.0中支持。
• BSD: 支持 (FreeBSD, DragonFly BSD. OpenBSD， NetBSD等)
• Mac OS：支持
• Windows： windows上只有SO_REUSEADDR选项，没有SO_REUSEPORT。windows上设置了SO_REUSEADDR的socket其行为与BSD上设定了SO_REUSEPORT和SO_REUSEADDRd的行为大致一样。
• Solaris：Solaris 11中支持 (patch已打)

和SO_REUSEADDR的区别

SO_REUSEADDR提供如下四个功能 ：

1. SO_REUSEADDR允许启动一个监听服务器并捆绑一个端口，即使以前建立的将此端口用做他们的本地端口的连接仍存在(TIME_WAIT)。这通常是重启监听服务器时出现，若不设置此选项，则bind时将出错。
2. SO_REUSEADDR允许在同一端口上启动同一服务器的多个实例，只要每个实例捆绑一个不同的本地IP地址即可。
3. SO_REUSEADDR允许单个进程捆绑同一端口到多个套接口上，只要每个捆绑指定不同的本地IP地址即可。这一般不用于TCP服务器。
4. SO_REUSEADDR允许完全重复的捆绑：当一个IP地址和端口绑定到某个套接口上时，还允许此IP地址和端口捆绑到另一个套接口上。一般来说，这个特性仅在支持多播的系统上才有，而且只对UDP套接口而言（TCP不支持多播）。

当使用通配符的时候更为复杂，这里有一张表格列出了各种情况(服务器的IP地址是192.168.0.1)：

SO_REUSEADDRsocketA socketB Result
---------------------------------------------------------------------
 ON/OFF 192.168.0.1:21192.168.0.1:21Error (EADDRINUSE)
 ON/OFF 192.168.0.1:2110.0.0.1:21OK
 ON/OFF 10.0.0.1:21192.168.0.1:21OK
 OFF 0.0.0.0:21192.168.1.0:21Error (EADDRINUSE)
 OFF 192.168.1.0:210.0.0.0:21Error (EADDRINUSE)
 ON 0.0.0.0:21192.168.1.0:21OK
 ON 192.168.1.0:210.0.0.0:21OK
 ON/OFF 0.0.0.0:210.0.0.0:21Error (EADDRINUSE)

SO_REUSEPORT选项有如下语义 ：

1. 此选项允许完全重复捆绑，但仅在想捆绑相同IP地址和端口的套接口都指定了此套接口选项才行。
2. 如果被捆绑的IP地址是一个多播地址，则SO_REUSEADDR和SO_REUSEPORT等效。

Netty的实现

Netty不是唯一通过 hack 方式实现 SO_REUSEPORT 特性的Java网络框架。比如下面的方式，使用 sun.nio.ch.Net 进行设置：

importsun.nio.ch.Net;

 ......

publicvoidsetReusePort(ServerSocketChannel serverChannel) {
try{
 Field fieldFd = serverChannel.getClass().getDeclaredField("fd");
//NoSuchFieldException
 fieldFd.setAccessible(true);
 FileDescriptor fd = (FileDescriptor)fieldFd.get(serverChannel);
//IllegalAccessException

 Method methodSetIntOption0 =
 Net.class.getDeclaredMethod("setIntOption0", FileDescriptor.class,
 Boolean.TYPE, Integer.TYPE, Integer.TYPE, Integer.TYPE);
 methodSetIntOption0.setAccessible(true);
 methodSetIntOption0.invoke(null, fd,false,'\uffff',
 SO_REUSEPORT, 1);
 } catch(Exception e) {
 System.out.println(e.toString());
 }
}

但是本文将关注Netty,因为Netty提供了一个通过JNI封装的库，可以更方便的进行 SO_REUSEPORT 设置。

自4.0.16版本，Netty为Linux提供了 native socket transport,通过JNI的方式实现，它可以提供更高的性能和极少的垃圾回收。

它兼容NIO的方式，只需改成：

NioEventLoopGroup → EpollEventLoopGroup
NioEventLoop → EpollEventLoop
NioServerSocketChannel → EpollServerSocketChannel
NioSocketChannel → EpollSocketChannel

Maven pom.xml加入：

<build>
<extensions>
<extension>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>1.2.3.Final</version>
</extension>
</extensions>
 ...
</build>

<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-epoll</artifactId>
<version>${project.version}</version>
<classifier>${os.detected.classifier}</classifier>
</dependency>
 ...
</dependencies>

SBT配置文件的话则加入：

"io.netty"%"netty-transport-native-epoll"%"${project.version}"classifier"linux-x86_64"

代码中设置 SO_REUSEPORT :

bootstrap.option(EpollChannelOption.SO_REUSEPORT, true)

很简单，完整的代码可以参照: WebServer.scala