Netty 断线重连 保连机制

概要

  保连是Netty客户端必须实现的一个重要功能, Netty本身并没有提供直接的实现, 为此Nettyx提供了InboundAdvice, ActionChannelFutureListener来进行保连

我知道你很急,但是你先别急. 先导入依赖

请从maven中央仓获取{lastest.version},最新版本号
<dependency>
    <groupId>io.github.fbbzl</groupId>
    <artifactId>nettyx</artifactId>
    <version>{lastest.version}</version>
</dependency>

Nettyx客户端支持两种形式的保连, 第一种是基于[监听器ChannelFutureListener]的保连, 第二种是基于 [建言InboundAdvice]的保连

根据自己业务需求选择合适的使用即可, 大部分情况两个都需要使用到, 基于监听器的保连是在建立连接之前的保连, 而 而 而
基于建言的保连一般是在建立连接之后, 连接出现问题之后,比如server宕机之类的的保连

1. ActionChannelFutureListener

  Nettyx提供了ActionChannelFutureListener, 此类扩展了ChannelFutureListener, 加入了一些函数式字段.
从项目Api的设计角度上来讲, 个人建议单独抽象出一个connect(address)方法, 且此connect方法不建议加入太多的业务逻辑, 越纯粹越好, 以便于后期重连的时候进行调用,

这里简单展示一个main

    // 用于连接远程地址的方法
    public static void main(String[] args) {
      TestSingleTcp testClient = new TestSingleTcp(new InetSocketAddress(9888));
      ChannelFutureListener listener = new ActionChannelFutureListener()
                 // redo 为ActionChannelFutureListener内部静态方法,用于重试
                 .whenFailure(redo(testClient::connect, 2, TimeUnit.MILLISECONDS))
			
      testClient.connect().addListener(listener);
    }

2.InboundAdvice

  我们之前就已经介绍过InboundAdvice的建言功能, 见过了它强大的channel建言功能, 其实它还可以进行断线重连, 重点是使用whenChannelInactive.
此场景多半是出现在 之前已经建立通信, 但是突然服务器宕机, 这时客户端就必须不停尝试重连

  private ChannelInitializer<NioSocketChannel> channelInitializer(SocketAddress address) {
        return new ChannelInitializer<NioSocketChannel>() {
            @Override
            protected void initChannel(NioSocketChannel channel) {
   				     InboundAdvice inboundAdvice = new InboundAdvice(channel);
       				 // 这里当channel建言收到断开连接的事件, 则会调用connect进行重连
       				 inboundAdvice.whenChannelInactive(ctx -> connect(address));
       				 
					 channel.pipeline()
                        // in  out
                        // ▼   ▲  remove start and end flag
                        .addLast(new StartEndFlagFrameCodec(1024 * 1024, false, Unpooled.wrappedBuffer(new byte[]{(byte) 0x7e})))
                        .addLast(new EscapeCodec(EscapeMap.mapHex("7e", "7d5e")))
                        .addLast(new UserCodec())
                        // ▼   ▲  deal control character and recover application data
                        .addLast(new LoggerHandler.InboundLogger(log, LoggerHandler.Sl4jLevel.ERROR))
                        //放在末尾的inboundadvice
                        .addLast(inboundAdvice);
            }
        };
    }

==========================================================================
  至此我们完成了保连的功能, 以上两个方案只能保连, 说白了就是保证连接的物理可用性, 但是业务上的逻辑可用性是无法保证的, 我个人建议使用心跳来保证连接的逻辑可用性
这里的 物理可用性 和 逻辑可用性, 类似于物理删除, 逻辑删除, 我知道你懂的