其实Netty基于网络连接声明周期暴露了很多提供用户自实现的API，而本文将基于其中的一个拓展点实现连接可靠性，希望对你有帮助。
详解Netty客户端断线重连的设计和实现
Netty生命周期中的channelInactive方法
读过笔者往期文章的读者大体是都知道channelInactive这个回调方法，我们从其注释即可知晓：注册的ChannelHandlerContext 的 Channel现在已经是不活跃即已经不可用的连接，就会调用pipeline上所有的处理器执行其内部实现的channelInactive处理剩余业务：
/**
* The {@link Channel} of the {@link ChannelHandlerContext} was registered is now inactive and reached its
* end of lifetime.
*/
void channelInactive(ChannelHandlerContext ctx) throws Exception;实际上channelInactive的执行我们也可以通过源码的方式让读者了解，我们以客户端连接为例，一旦客户端断开连接，客户端的selector就会轮循到连接关闭事件，便会将对应客户端的channel取消并调用channelInactive方法：
从源码角度来NioEventLoop轮询到关闭事件后会直接执行该事件closeOnRead方法，其内部判断连接非open状态则会直接调用close进行连接关闭操作：
protected class NioByteUnsafe extends AbstractNioUnsafe {
private void closeOnRead(ChannelPipeline pipeline) {
if (isOpen()) {
//......
} else {
//调用close执行关闭连接
close(voidPromise());
}
}
}close逻辑内部最终会定位到客户端的socketchannel执行到AbstractChannel的close方法，其内部会向eventLoop注册一个doDeregister的事件，该事件会将客户端socket注册的读写事件取消，完成后就会调用fireChannelInactive走到channelInactive回调，通知当前客户端netty这个socket的远程连接不再活跃，已经断开了：
对此我们给出上图所示的源码片段，改代码位于AbstractChannel的close方法，其内部核心逻辑就是调用fireChannelInactiveAndDeregister移除客户端socket的读写事件并触发channelInactive的回调通知：
private void close(final ChannelPromise promise, final Throwable cause,
final ClosedChannelException closeCause, final boolean notify) {
//......
if (closeExecutor != null) {
//......
} else {
//......
} else {
//调用fireChannelInactiveAndDeregister移除断开连接的客户端socket并触发channelInactive回调
fireChannelInactiveAndDeregister(wasActive);
}
}
}fireChannelInactiveAndDeregister内部核心逻辑就是deregister方法，可以看到该方法核心逻辑就是提交给eventLoop一个异步任务，也就是我们上图所说的移除客户端读写事件的方法，方法名是doDeregister，完成该方法调用后就会调用fireChannelInactive方法，告知服务端这个客户端channel连接已断开：
private void deregister(final ChannelPromise promise, final boolean fireChannelInactive) {
//......
invokeLater(new Runnable() {
@Override
public void run() {
try {
//移除客户端读写事件
doDeregister();
} catch (Throwable t) {
logger.warn("Unexpected exception occurred while deregistering a channel.", t);
} finally {
//触发客户端channel的channelInactive回调
if (fireChannelInactive) {
pipeline.fireChannelInactive();
}
//......
}
}
});
}对此我们给出doDeregister的逻辑，可以看到其内部拿到eventLoop事件轮询器，通过调用cancel移除当前客户端socket读写事件：
@Override
protected void doDeregister() throws Exception {
//通过selectionKey获取断开连接的客户端读写事件的key，通过cancel移除这些事件
eventLoop().cancel(selectionKey());
}Netty断线重连思路与实现
由此我们知晓要想实现断线重连，客户端可以通过重写channelInactive方法，确保在感知到连接断开时再次提交一个连接的延迟事件，知道断线的连接再次恢复，由此保证客户端连接可靠性：
最终我们给出断线重连的ReconnectHandler，其内部逻辑很简单，延迟5秒后向eventLoop提交一个断线重连的异步连接任务直到成功，完成后我们将这个处理器添加到客户端的pipeline即可：
public class ReconnectHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelInactive(ChannelHandlerContext ctx) throws Exception {
//提交断线重连的延迟任务
scheduledDoReConnect(ctx);
ctx.fireChannelInactive();
}
private ScheduledFuture<?> scheduledDoReConnect(ChannelHandlerContext ctx) {
//拿到当前channel的eventLoop提交一个连接远程服务端的延迟任务
ScheduledFuture<?> scheduledFuture = ctx.channel().eventLoop().schedule(() -> {
ChannelFuture channelFuture = ctx.channel().connect(new InetSocketAddress("127.0.0.1", 8888));
channelFuture.addListener(f -> {
if (!f.isSuccess()) {
//如果失败则递归调用scheduledDoReConnect再次尝试
scheduledDoReConnect(ctx);
} else {
System.out.println("reconnect success.");
}
});
}, 5, TimeUnit.SECONDS);
return scheduledFuture;
}
}小结
自此我们基于Netty生命周期的源码剖析给出客户端断线重连的设计和落地思路，希望对你有帮助。
