{"id":5432,"date":"2018-06-29T01:23:36","date_gmt":"2018-06-29T08:23:36","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=5432"},"modified":"2018-06-29T01:23:36","modified_gmt":"2018-06-29T08:23:36","slug":"inside-the-java-sdk-connection-management","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/inside-the-java-sdk-connection-management\/","title":{"rendered":"Por dentro do Java SDK: Gerenciamento de conex\u00f5es"},"content":{"rendered":"

Nesta segunda parte de \"Por dentro do Java SDK\", daremos uma olhada detalhada em como o SDK gerencia e agrupa soquetes para os v\u00e1rios n\u00f3s e servi\u00e7os. Embora n\u00e3o seja necess\u00e1rio seguir o exemplo, recomendo que voc\u00ea d\u00ea uma olhada na primeira postagem sobre bootstrapping\u00a0<\/a>tamb\u00e9m.<\/p>\n

Observe que esta postagem foi escrita tendo em mente as vers\u00f5es 2.5.9 \/ 2.6.0 do Java SDK. As coisas podem mudar com o tempo, mas a abordagem geral deve permanecer praticamente a mesma.<\/p>\n

No esp\u00edrito dos modelos OSI e TCP, proponho um modelo de tr\u00eas camadas que representa a pilha de conex\u00f5es dos SDKs:<\/p>\n

+-----------------+\r\n| Service Layer   |\r\n+-----------------+\r\n| Endpoint Layer  |\r\n+-----------------+\r\n| Channel Layer   |\r\n+-----------------+<\/pre>\n
Os n\u00edveis mais altos s\u00e3o constru\u00eddos sobre os n\u00edveis mais baixos, portanto, come\u00e7aremos com a camada Channel (Canal) e subiremos na pilha.<\/p>\n
A camada de canal<\/h2>\n
A camada de canal \u00e9 o n\u00edvel mais baixo em que o SDK lida com a rede e \u00e9 constru\u00edda sobre a excelente biblioteca de E\/S totalmente ass\u00edncrona chamada Netty<\/a>\u00a0Somos usu\u00e1rios extensivos do Netty h\u00e1 anos e tamb\u00e9m contribu\u00edmos com patches, bem como com o codec de memcache<\/a> de volta ao projeto.<\/p>\n
Cada Netty Canal<\/a> corresponde a um soquete e \u00e9 multiplexado em cima de loops de eventos. Abordaremos o modelo de threading em uma postagem posterior do blog, mas, por enquanto, \u00e9 importante saber que, em vez do modelo \"um thread por soquete\" da E\/S de bloqueio tradicional, o Netty pega todos os soquetes abertos e os distribui em um punhado de loops de eventos. Ele faz isso de forma muito eficiente, portanto, n\u00e3o \u00e9 de se admirar que o Netty seja usado em todo o setor<\/a>\u00a0para componentes de rede de alto desempenho e baixa lat\u00eancia.<\/p>\n
Como um canal se preocupa apenas com a entrada e sa\u00edda de bytes, precisamos de uma maneira de codificar e decodificar solicita\u00e7\u00f5es em n\u00edvel de aplicativo (como uma consulta N1QL ou uma solicita\u00e7\u00e3o de obten\u00e7\u00e3o de chave\/valor) em sua representa\u00e7\u00e3o bin\u00e1ria adequada. No Netty, isso \u00e9 feito adicionando manipuladores<\/a> para o canal de distribui\u00e7\u00e3o<\/a>. Todas as opera\u00e7\u00f5es de grava\u00e7\u00e3o na rede descem pelo pipeline e as respostas do servidor voltam pelo pipeline (tamb\u00e9m chamadas de entrada e sa\u00edda na terminologia Netty).<\/p>\n
Alguns manipuladores s\u00e3o adicionados independentemente do servi\u00e7o usado (como registro ou criptografia) e outros dependem do tipo de servi\u00e7o (por exemplo, para uma resposta N1QL, temos analisadores de fluxo JSON personalizados para a estrutura da resposta).<\/p>\n
Se voc\u00ea j\u00e1 se perguntou como obter uma sa\u00edda de registro em n\u00edvel de pacote durante o desenvolvimento ou a depura\u00e7\u00e3o (para produ\u00e7\u00e3o, use tcpdump, wireshark ou similar), tudo o que precisa fazer \u00e9 ativar o n\u00edvel de registro TRACE em sua biblioteca de registro favorita e ver\u00e1 uma sa\u00edda como esta:<\/p>\n
[cb-io-1-1] 2018-06-28 14:03:34 TRACE LoggingHandler:94 - [id: 0x41407638, L:\/127.0.0.1:60923 - R:localhost\/127.0.0.1:11210] WRITE: 243B\r\n+-------------------------------------------------+\r\n| 0 1 2 3 4 5 6 7 8 9 a b c d e f |\r\n+--------+-------------------------------------------------+----------------+\r\n|00000000| 80 1f 00 db 00 00 00 00 00 00 00 e5 00 00 00 00 |................|\r\n|00000010| 00 00 00 00 00 00 00 00 7b 22 61 22 3a 22 63 6f |........{\"a\":\"co|\r\n|00000020| 75 63 68 62 61 73 65 2d 6a 61 76 61 2d 63 6c 69 |uchbase-java-cli|\r\n|00000030| 65 6e 74 2f 32 2e 36 2e 30 2d 53 4e 41 50 53 48 |ent\/2.6.0-SNAPSH|\r\n|00000040| 4f 54 20 28 67 69 74 3a 20 32 2e 36 2e 30 2d 62 |OT (git: 2.6.0-b|\r\n|00000050| 65 74 61 2d 31 36 2d 67 35 63 65 30 38 62 30 2c |eta-16-g5ce08b0,|\r\n|00000060| 20 63 6f 72 65 3a 20 31 2e 36 2e 30 2d 62 65 74 | core: 1.6.0-bet|\r\n|00000070| 61 2d 33 33 2d 67 31 62 33 65 36 66 62 29 20 28 |a-33-g1b3e6fb) (|\r\n|00000080| 4d 61 63 20 4f 53 20 58 2f 31 30 2e 31 33 2e 34 |Mac OS X\/10.13.4|\r\n|00000090| 20 78 38 36 5f 36 34 3b 20 4a 61 76 61 20 48 6f | x86_64; Java Ho|\r\n|000000a0| 74 53 70 6f 74 28 54 4d 29 20 36 34 2d 42 69 74 |tSpot(TM) 64-Bit|\r\n|000000b0| 20 53 65 72 76 65 72 20 56 4d 20 31 2e 38 2e 30 | Server VM 1.8.0|\r\n|000000c0| 5f 31 30 31 2d 62 31 33 29 22 2c 22 69 22 3a 22 |_101-b13)\",\"i\":\"|\r\n|000000d0| 30 43 34 37 35 41 43 41 35 46 33 38 30 41 32 31 |0C475ACA5F380A21|\r\n|000000e0| 2f 30 30 30 30 30 30 30 30 34 31 34 30 37 36 33 |\/000000004140763|\r\n|000000f0| 38 22 7d |8\"} |\r\n+--------+-------------------------------------------------+----------------+<\/pre>\n
Observe o pequeno Gerenciador de registro<\/span>\u00a0 l\u00e1 em cima? Isso ocorre porque s\u00f3 adicionamos o manipulador de registro se o rastreamento estiver ativado no pipeline, para que voc\u00ea n\u00e3o pague a sobrecarga se n\u00e3o o estiver usando (o que ocorre na maioria das vezes):<\/p>\n
bootstrap = new BootstrapAdapter(new Bootstrap()\r\n  \/\/ *snip*\r\n  .option(ChannelOption.ALLOCATOR, allocator)\r\n  .option(ChannelOption.TCP_NODELAY, tcpNodelay)\r\n  .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, env.socketConnectTimeout())\r\n  .handler(new ChannelInitializer<Channel>() {\r\n    @Override\r\n    protected void initChannel(Channel channel) throws Exception {\r\n      ChannelPipeline pipeline = channel.pipeline();\r\n      if (env.sslEnabled()) {\r\n        pipeline.addLast(new SslHandler(sslEngineFactory.get()));\r\n      }\r\n      if (LOGGER.isTraceEnabled()) {\r\n        pipeline.addLast(LOGGING_HANDLER_INSTANCE);\r\n      }\r\n    customEndpointHandlers(pipeline);\r\n  }\r\n}));<\/pre>\n
Voc\u00ea tamb\u00e9m pode ver que, dependendo da configura\u00e7\u00e3o do ambiente, fazemos outros ajustes, como adicionar um manipulador de SSL\/TLS ao pipeline ou configurar o nodelay do TCP e os tempos limite do soquete.<\/p>\n
O customEndpointHandlers<\/span>\u00a0 \u00e9 substitu\u00eddo para cada servi\u00e7o, aqui est\u00e1 o pipeline para a camada KV (ligeiramente simplificado):<\/p>\n
if (environment().keepAliveInterval() > 0) {\r\n    pipeline.addLast(new IdleStateHandler(environment().keepAliveInterval(), 0, 0, TimeUnit.MILLISECONDS));\r\n}\r\n\r\npipeline\r\n    .addLast(new BinaryMemcacheClientCodec())\r\n    .addLast(new BinaryMemcacheObjectAggregator(Integer.MAX_VALUE));\r\n\r\npipeline\r\n    .addLast(new KeyValueFeatureHandler(context()))\r\n    .addLast(new KeyValueErrorMapHandler());\r\n\r\nif (!environment().certAuthEnabled()) {\r\n    pipeline.addLast(new KeyValueAuthHandler(username(), password(), environment().forceSaslPlain()));\r\n}\r\n\r\npipeline\r\n    .addLast(new KeyValueSelectBucketHandler(bucket()))\r\n    .addLast(new KeyValueHandler(this, responseBuffer(), false, true));<\/pre>\n
H\u00e1 muita coisa acontecendo aqui! Vamos analisar um por um:<\/p>\n