{"id":73949,"date":"2020-03-13T02:42:07","date_gmt":"2020-03-12T23:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1"},"modified":"2020-03-13T02:42:07","modified_gmt":"2020-03-12T23:42:07","slug":"kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"Como escolhemos um sistema de cache na Sportmaster. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1! Meu nome \u00e9 Alexey Pyankov, sou desenvolvedor na empresa Sportmaster. Neste post<\/a><\/noindex> falei sobre como come\u00e7ou o trabalho no site da Sportmaster em 2012, quais iniciativas conseguimos \"impulsionar\" e, ao contr\u00e1rio, quais dificuldades encontramos.<\/p>\n

Hoje eu quero compartilhar reflex\u00f5es que acompanham uma outra hist\u00f3ria \u2013 a escolha do sistema de cache para o backend Java na administra\u00e7\u00e3o do site. Essa hist\u00f3ria tem um significado especial para mim \u2013 embora tenha se desenrolado em apenas 2 meses, nesses 60 dias trabalhamos de 12 a 16 horas por dia, sem um \u00fanico dia de folga. Nunca havia pensado ou imaginado que seria poss\u00edvel trabalhar tanto.<\/p>\n

Por isso, dividi o texto em 2 partes, para n\u00e3o sobrecarregar demais. Ao contr\u00e1rio, a primeira parte ser\u00e1 muito leve \u2014 uma prepara\u00e7\u00e3o, uma introdu\u00e7\u00e3o, algumas considera\u00e7\u00f5es sobre o que \u00e9 caching. Se voc\u00ea j\u00e1 \u00e9 um desenvolvedor experiente ou trabalhou com caches \u2014 do lado t\u00e9cnico, provavelmente n\u00e3o haver\u00e1 nada de novo neste artigo. Mas para um j\u00fanior, uma pequena vis\u00e3o geral pode indicar a dire\u00e7\u00e3o certa a seguir, se ele se encontrar em uma encruzilhada dessas.<\/p>\n

\"Como<\/a><\/noindex>
\n<\/a><\/noindex>
\nQuando a nova vers\u00e3o do site da Sportmaster foi lan\u00e7ada em produ\u00e7\u00e3o, os dados chegavam de uma maneira, digamos, n\u00e3o muito conveniente. A base era composta por tabelas preparadas para a vers\u00e3o anterior do site (Bitrix), que precisavam ser carregadas no ETL, convertidas para um novo formato e enriquecidas com v\u00e1rias adi\u00e7\u00f5es de mais de uma dezena de sistemas. Para que uma nova imagem ou descri\u00e7\u00e3o do produto aparecesse no site, era necess\u00e1rio aguardar at\u00e9 o dia seguinte \u2014 a atualiza\u00e7\u00e3o ocorria apenas \u00e0 noite, uma vez por dia.<\/p>\n

No in\u00edcio, havia tantas preocupa\u00e7\u00f5es nas primeiras semanas ap\u00f3s o lan\u00e7amento em produ\u00e7\u00e3o que esses inconvenientes para os gerentes de conte\u00fado eram detalhes. Mas, assim que tudo se estabilizou, o desenvolvimento do projeto continuou \u2014 alguns meses depois, no in\u00edcio de 2015, come\u00e7amos a desenvolver ativamente a administra\u00e7\u00e3o. Em 2015 e 2016 tudo ia bem, fizemos lan\u00e7amentos regularmente, a administra\u00e7\u00e3o cobria uma parte cada vez maior da prepara\u00e7\u00e3o dos dados e nos prepar\u00e1vamos para o que em breve nossa equipe receberia a tarefa mais importante e desafiadora \u2013 o fluxo de produtos (prepara\u00e7\u00e3o completa e gest\u00e3o de dados para todos os produtos). Mas no ver\u00e3o de 2017, logo antes do lan\u00e7amento do fluxo de produtos, o projeto se encontrou em uma situa\u00e7\u00e3o muito complicada \u2013 precisamente devido a problemas com o caching. Sobre esse epis\u00f3dio, quero falar na segunda parte desta publica\u00e7\u00e3o em duas partes.<\/p>\n

Mas neste post, irei come\u00e7ar de longe, reunindo algumas ideias sobre caching, que discutir antes de um grande projeto seria uma boa abordagem.<\/p>\n

Quando surge a necessidade de caching<\/h2>\n

\nA necessidade de caching n\u00e3o surge por acaso. N\u00f3s, desenvolvedores, criamos produtos de software e queremos que eles sejam procurados. Se o produto \u00e9 desejado e bem-sucedido, os usu\u00e1rios come\u00e7am a chegar. E eles continuam a chegar, e chegar, e ent\u00e3o h\u00e1 muitos usu\u00e1rios, e o produto se torna de alta carga.<\/p>\n

Nos primeiros est\u00e1gios, n\u00e3o pensamos em otimiza\u00e7\u00e3o e desempenho de c\u00f3digo. O que importa \u00e9 a funcionalidade, lan\u00e7ar rapidamente uma vers\u00e3o piloto e testar hip\u00f3teses. E se a carga aumenta, melhoramos o hardware. Aumentamos duas, tr\u00eas, cinco, ou at\u00e9 dez vezes. Em algum ponto, as finan\u00e7as n\u00e3o permitir\u00e3o mais. E em quanto tempo o n\u00famero de usu\u00e1rios crescer\u00e1? N\u00e3o ser\u00e1 apenas 2-5-10, mas no caso de sucesso, pode ser de 100 a 1000 e at\u00e9 100 mil vezes. Ou seja, mais cedo ou mais tarde, ser\u00e1 necess\u00e1rio lidar com a otimiza\u00e7\u00e3o.<\/p>\n

Suponha que uma parte do c\u00f3digo (vamos chamar essa parte de fun\u00e7\u00e3o) esteja levando um tempo inaceit\u00e1vel para ser executada, e queremos reduzir esse tempo. A fun\u00e7\u00e3o pode ser o acesso a um banco de dados, pode ser a execu\u00e7\u00e3o de uma l\u00f3gica complexa - o essencial \u00e9 que o tempo de execu\u00e7\u00e3o seja longo. At\u00e9 onde podemos reduzir o tempo de execu\u00e7\u00e3o? Em teoria, podemos reduzi-lo a zero, mas n\u00e3o al\u00e9m disso. E como podemos reduzir o tempo de execu\u00e7\u00e3o a zero? A resposta: excluindo completamente a execu\u00e7\u00e3o. Em vez disso, retornamos imediatamente o resultado. E como sabemos qual \u00e9 o resultado? A resposta: ou calculamos, ou olhamos em algum lugar. Calcular \u00e9 demorado. E olhar, por exemplo, \u00e9 memorizar o resultado que a fun\u00e7\u00e3o retornou da \u00faltima vez que foi chamada com os mesmos par\u00e2metros.<\/p>\n

Ou seja, a implementa\u00e7\u00e3o da fun\u00e7\u00e3o n\u00e3o \u00e9 importante para n\u00f3s. Basta saber de quais par\u00e2metros o resultado depende. Assim, se representarmos os valores dos par\u00e2metros na forma de um objeto que pode ser usado como chave em algum armazenamento \u2014 podemos salvar o resultado do c\u00e1lculo e na pr\u00f3xima vez que precisarmos, podemos recuper\u00e1-lo. Se essas opera\u00e7\u00f5es de grava\u00e7\u00e3o e leitura do resultado forem mais r\u00e1pidas do que a execu\u00e7\u00e3o da fun\u00e7\u00e3o \u2013 obtemos lucro em termos de velocidade. O valor do lucro pode atingir 100, 1000 ou at\u00e9 100 mil vezes (10^5 \u2013 isso \u00e9 mais uma exce\u00e7\u00e3o, mas em caso de um banco de dados que est\u00e1 realmente lento \u2013 \u00e9 bastante poss\u00edvel).<\/p>\n

Requisitos principais para um sistema de cache<\/h2>\n

\nA primeira exig\u00eancia que pode surgir para um sistema de cache \u00e9 a r\u00e1pida velocidade de leitura e, em menor medida, a velocidade de grava\u00e7\u00e3o. Isso \u00e9 verdade, mas apenas at\u00e9 o momento em que colocamos o sistema em produ\u00e7\u00e3o.<\/p>\n

Vamos considerar um caso.<\/p>\n

Suponha que j\u00e1 garantimos que o hardware suportaria a carga atual e agora estamos lentamente implementando o cache. O n\u00famero de usu\u00e1rios aumenta um pouco, a carga cresce \u2013 adicionamos um pouco de cache, ajustamos aqui e ali. Isso continua por um tempo, e ent\u00e3o fun\u00e7\u00f5es pesadas j\u00e1 quase n\u00e3o s\u00e3o chamadas \u2013 toda a carga principal recai sobre o cache. O n\u00famero de usu\u00e1rios aumentou N vezes nesse per\u00edodo.<\/p>\n

E se a reserva inicial de hardware poderia ser de 2 a 5 vezes, ent\u00e3o, com a ajuda do cache, poder\u00edamos aumentar o desempenho em at\u00e9 10 vezes ou, no melhor dos casos, at\u00e9 100, em alguns casos, talvez at\u00e9 1000. Ou seja, com o mesmo hardware \u2013 processamos 100 vezes mais requisi\u00e7\u00f5es. Maravilha, merecemos um doce!<\/p>\n

Mas agora, em um belo momento, acidentalmente, o sistema falhou e o cache colapsou. Nada de mais \u2013 afinal, escolhemos o cache com o requisito de \"alta velocidade de leitura e grava\u00e7\u00e3o, o restante n\u00e3o \u00e9 importante\".<\/p>\n

Em rela\u00e7\u00e3o \u00e0 carga inicial, a reserva de hardware era de 2-5 vezes, enquanto a carga aumentou de 10 a 100 vezes. Com o cache, eliminamos as chamadas para fun\u00e7\u00f5es pesadas e, por isso, tudo funcionava perfeitamente. E agora, sem o cache \u2013 qu\u00e3o mais nossa sistema vai cair? O que acontecer\u00e1? O sistema vai travar.<\/p>\n

Mesmo que nosso cache n\u00e3o tenha colapsado, mas apenas limpado por um tempo, ele precisar\u00e1 ser reaquecido, e isso levar\u00e1 algum tempo. E durante esse tempo \u2013 a carga principal recair\u00e1 sobre a funcionalidade.<\/p>\n

Resultado: projetos de alta carga em produ\u00e7\u00e3o exigem um sistema de cache n\u00e3o apenas com alta velocidade de leitura e grava\u00e7\u00e3o, mas tamb\u00e9m com integridade de dados e resist\u00eancia a falhas.<\/p>\n

As dores da escolha<\/h2>\n

\nNo projeto com o painel administrativo, a escolha foi assim: inicialmente instalamos o Hazelcast, pois j\u00e1 est\u00e1vamos familiarizados com este produto pela experi\u00eancia do site principal. Mas, essa escolha se mostrou infeliz - sob o nosso perfil de carga, o Hazelcast n\u00e3o apenas funciona lentamente, mas horrivelmente devagar. E quanto aos prazos de entrega em produ\u00e7\u00e3o, j\u00e1 est\u00e1vamos comprometidos na \u00e9poca.<\/p>\n

Spoiler: como as circunst\u00e2ncias se desenrolaram, que nos fez passar por esse percal\u00e7o e chegar a uma situa\u00e7\u00e3o cr\u00edtica e tensa - conto na segunda parte - e como chegamos a isso, e como sa\u00edmos. Mas agora - posso apenas dizer que foi um estresse grande, e \"pensar - n\u00e3o se pensa, sacudimos a garrafa\". \"Sacudimos a garrafa\" - isso tamb\u00e9m \u00e9 um spoiler, sobre isso mais adiante.<\/p>\n

O que fizemos:<\/p>\n

    \n
  1. Elaboramos uma lista de todos os sistemas sugeridos pelo google e StackOverflow. Um pouco mais de 30.<\/li>\n
  2. Escrevemos testes com uma carga caracter\u00edstica de produ\u00e7\u00e3o. Para isso, gravamos os dados que atravessam o sistema em um ambiente de produ\u00e7\u00e3o - uma esp\u00e9cie de sniffer de dados n\u00e3o na rede, mas dentro do sistema. Nos testes, usamos exatamente esses dados.<\/li>\n
  3. Toda a equipe, cada um escolhe o pr\u00f3ximo sistema da lista, configura, roda os testes. Se o teste n\u00e3o passar, n\u00e3o suportar a carga - descartamos, passamos para o pr\u00f3ximo da fila.<\/li>\n
  4. Na 17\u00aa sistema, ficou claro que tudo estava sem esperan\u00e7a. Chega de \"sacudir a garrafa\", \u00e9 hora de pensar s\u00e9rio.<\/li>\n<\/ol>\n

    \nMas essa \u00e9 uma op\u00e7\u00e3o quando \u00e9 preciso escolher um sistema que \"passe na velocidade\" nos testes previamente organizados. E se esses testes ainda n\u00e3o existem e queremos decidir mais rapidamente?<\/p>\n

    Modelaremos essa op\u00e7\u00e3o (\u00e9 dif\u00edcil imaginar que um desenvolvedor mid-level + viva em um v\u00e1cuo, e no momento da escolha ainda n\u00e3o tenha decidido qual produto experimentar primeiro - portanto, as considera\u00e7\u00f5es seguintes s\u00e3o mais uma teoria \/ filosofia \/ sobre um j\u00fanior).<\/p>\n

    Depois de definir os requisitos, come\u00e7aremos a escolher uma solu\u00e7\u00e3o pronta. Por que reinventar a roda: vamos pegar um sistema de cache pronto.<\/p>\n

    Se voc\u00ea est\u00e1 come\u00e7ando e vai pesquisar, a ordem pode ser mais ou menos essa, mas, em geral, as refer\u00eancias ser\u00e3o as seguintes. Primeiro, voc\u00ea encontrar\u00e1 o Redis, que est\u00e1 em toda parte. Depois, saber\u00e1 que existe o EhCache, como o sistema mais antigo e comprovado. Em seguida, ser\u00e1 mencionado o Tarantool \u2014 um desenvolvimento local, que tem um aspecto \u00fanico na solu\u00e7\u00e3o. E tamb\u00e9m o Ignite, pois atualmente est\u00e1 em ascens\u00e3o e recebe apoio do SberTech. Por fim, o Hazelcast, que aparece com frequ\u00eancia no mundo corporativo entre grandes empresas.<\/p>\n

    Essa lista n\u00e3o \u00e9 exaustiva, existem dezenas de sistemas. Mas n\u00f3s vamos nos concentrar apenas em um. Vamos pegar 5 sistemas selecionados para um 'concurso de beleza' e faremos uma sele\u00e7\u00e3o. Quem ser\u00e1 o vencedor?<\/p>\n

    Redis<\/h3>\n

    \nVamos ler o que est\u00e1 escrito no site oficial.
    \n    Redis<\/a><\/noindex> \u2014 projeto opensource. Oferece um armazenamento de dados em mem\u00f3ria, a possibilidade de salvar no disco, divis\u00e3o autom\u00e1tica em parti\u00e7\u00f5es, alta disponibilidade e recupera\u00e7\u00e3o ap\u00f3s quedas de rede.<\/p>\n

    Parece que est\u00e1 tudo \u00f3timo, pode-se pegar e integrar \u2014 tudo o que \u00e9 necess\u00e1rio, ele faz. Mas vamos olhar, apenas por curiosidade, para os outros candidatos.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 'o cache mais amplamente utilizado para Java' (tradu\u00e7\u00e3o do slogan do site oficial). Tamb\u00e9m opensource. E aqui entendemos que o Redis n\u00e3o \u00e9 espec\u00edfico para Java, mas \u00e9 geral, e para interagir com ele \u00e9 necess\u00e1rio um wrapper. O EhCache ser\u00e1 mais conveniente. O que mais o sistema promete? Confiabilidade, veracidade, funcionalidade completa. E tamb\u00e9m \u00e9 o mais comum. E ele cacheia terabytes de dados.<\/p>\n

    O Redis foi esquecido, estou pronto para escolher o EhCache.<\/p>\n

    Mas o sentimento de patriotismo me leva a olhar o que h\u00e1 de bom no Tarantool.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 se apresenta como 'Plataforma de Integra\u00e7\u00e3o de Dados em Tempo Real'. Soa muito complicado, ent\u00e3o vamos ler a p\u00e1gina detalhadamente e encontramos uma declara\u00e7\u00e3o impressionante: 'Cacheia 100% dos dados na mem\u00f3ria'. Isso deve levantar quest\u00f5es \u2014 pois os dados podem ser significativamente maiores do que a mem\u00f3ria. A explica\u00e7\u00e3o \u00e9 que, para gravar dados no disco a partir da mem\u00f3ria, o Tarantool n\u00e3o passa pela serializa\u00e7\u00e3o. Em vez disso, utiliza recursos de baixo n\u00edvel do sistema, onde a mem\u00f3ria \u00e9 simplesmente mapeada no sistema de arquivos com \u00edndices de I\/O muito bons. Em geral, foi feito de forma incr\u00edvel e excelente.<\/p>\n

    Vamos olhar as implementa\u00e7\u00f5es: Mail.ru, linha corporativa, Avito, Beeline, MegaFon, Alfa-Bank, Gazprom...<\/p>\n

    Se ainda havia alguma d\u00favida sobre o Tarantool, o caso de implementa\u00e7\u00e3o no Mastercard me convenceu. Vou optar pelo Tarantool.<\/p>\n

    Mas mesmo assim\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 ainda h\u00e1 Ignite<\/a><\/noindex>, anunciado como uma \u00abplataforma de computa\u00e7\u00e3o in-memory\u2026 com velocidades in-memory em petabytes de dados\u00bb. Aqui tamb\u00e9m h\u00e1 muitos benef\u00edcios: cache in-memory distribu\u00eddo, o reposit\u00f3rio de chave-valor e cache mais r\u00e1pido, escalabilidade horizontal, alta disponibilidade, rigorosa integridade. No geral, o mais r\u00e1pido \u00e9 o Ignite.<\/p>\n

    Implementa\u00e7\u00f5es: Sberbank, American Airlines, Yahoo! Japan. E depois descubro que o Ignite n\u00e3o est\u00e1 apenas implementado no Sberbank, mas a equipe do SberTech envia seus membros para a equipe do Ignite para aprimorar o produto. Isso realmente me convence e estou pronto para adotar o Ignite.<\/p>\n

    Totalmente incompreens\u00edvel por que, vejo o quinto ponto.<\/p>\n

    Hazelcast<\/h3>\n

    \nAcesso ao site Hazelcast<\/a><\/noindex>, leio. E parece que a solu\u00e7\u00e3o mais r\u00e1pida para cache distribu\u00eddo \u00e9 o Hazelcast. Ele \u00e9 v\u00e1rias vezes mais r\u00e1pido que todas as outras solu\u00e7\u00f5es e, de fato, \u00e9 o l\u00edder na \u00e1rea de grid de dados in-memory. Em compara\u00e7\u00e3o a isso, escolher outra coisa seria uma falta de respeito. Al\u00e9m disso, utiliza armazenamento redundante para opera\u00e7\u00e3o cont\u00ednua do cluster sem perda de dados.<\/p>\n

    Pronto, estou decidido a optar pelo Hazelcast.<\/p>\n

    Compara\u00e7\u00e3o<\/h2>\n

    \nMas ao observar, todos os cinco candidatos est\u00e3o t\u00e3o bem descritos que cada um deles \u00e9 o melhor. Como escolher? Podemos verificar qual deles \u00e9 o mais popular, procurar compara\u00e7\u00f5es e acabar com a dor de cabe\u00e7a.<\/p>\n

    Encontramos um an\u00e1lise<\/a><\/noindex>, escolhemos nossos 5 sistemas.<\/p>\n

    \"Como
    \n
    \nAqui eles est\u00e3o classificados: no topo est\u00e1 o Redis, em segundo lugar \u2014 Hazelcast, Tarantool e Ignite est\u00e3o ganhando popularidade, e o EhCache permanece como estava. <\/p>\n

    Mas vamos olhar para o m\u00e9todo de c\u00e1lculo<\/a><\/noindex>: links para websites, interesse geral no sistema, ofertas de emprego \u2014 \u00f3timo! Ou seja, quando meu sistema falhar, direi: \u00abN\u00e3o, ele \u00e9 confi\u00e1vel! Existem muitas ofertas de emprego\u2026\u00bb. Essa compara\u00e7\u00e3o simples n\u00e3o servir\u00e1.<\/p>\n

    Todos esses sistemas n\u00e3o s\u00e3o apenas sistemas de cache. Eles tamb\u00e9m possuem muitas funcionalidades, incluindo \u2013 quando n\u00e3o s\u00e3o os dados que s\u00e3o transferidos para o cliente para processamento, mas, ao contr\u00e1rio: o c\u00f3digo que precisa ser executado sobre os dados \u00e9 enviado ao servidor, \u00e9 executado l\u00e1, e o resultado \u00e9 retornado. Como sistemas separados de cache, n\u00e3o s\u00e3o frequentemente considerados.<\/p>\n

    Bem, n\u00e3o vamos desistir, vamos encontrar uma compara\u00e7\u00e3o direta dos sistemas. Vamos pegar as duas principais op\u00e7\u00f5es \u2014 Redis e Hazelcast. Estamos interessados na velocidade, e esse par\u00e2metro ser\u00e1 utilizado para a compara\u00e7\u00e3o.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nEncontramos um assim uma compara\u00e7\u00e3o<\/a><\/noindex>:
    \n\"Como
    \n
    \nAzul \u00e9 Redis, vermelho \u00e9 Hazelcast. Hazelcast vence em todos os aspectos, e isso tem uma justificativa: \u00e9 multithreaded, altamente otimizado, cada thread trabalha com sua parti\u00e7\u00e3o, portanto n\u00e3o h\u00e1 bloqueios. J\u00e1 Redis \u00e9 single-threaded, n\u00e3o consegue aproveitar os modernos CPUs multicore. Hazelcast utiliza I\/O ass\u00edncrono, enquanto Redis-Jedis usa sockets bloqueantes. No fim das contas, Hazelcast utiliza um protocolo bin\u00e1rio, enquanto Redis \u00e9 orientado a texto, ou seja, \u00e9 ineficiente.<\/p>\n

    Para garantir, vamos consultar mais uma fonte de compara\u00e7\u00e3o. O que ela nos mostrar\u00e1?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nMais um uma compara\u00e7\u00e3o<\/a><\/noindex>:
    \n\"Como
    \n
    \nAqui, ao contr\u00e1rio, vermelho \u00e9 Redis. Ou seja, Redis tem melhor desempenho que Hazelcast. No primeiro compara\u00e7\u00e3o, Hazelcast venceu, na segunda, Redis.     Aqui tamb\u00e9m<\/a><\/noindex> explicaram muito bem por que Hazelcast venceu na compara\u00e7\u00e3o anterior.<\/p>\n

    Aparentemente, o resultado do primeiro foi realmente manipulado: Redis foi utilizado na vers\u00e3o b\u00e1sica, enquanto Hazelcast foi otimizado para o caso de teste. Portanto, fica claro que: em primeiro lugar, n\u00e3o se pode confiar em ningu\u00e9m, e em segundo lugar, quando finalmente escolhermos um sistema, ainda precisamos configur\u00e1-lo corretamente. Essas configura\u00e7\u00f5es envolvem dezenas, quase centenas de par\u00e2metros.<\/p>\n

    Agitamos a garrafa<\/h2>\n

    \nE todo o processo que acabamos de realizar, posso explicar com a met\u00e1fora \"Agitamos a garrafa\". Ou seja, neste momento, n\u00e3o \u00e9 necess\u00e1rio programar, o principal \u00e9 saber ler stackoverflow. E eu tenho em minha equipe uma pessoa, um profissional, que trabalha exatamente assim em momentos cr\u00edticos.<\/p>\n

    O que ele faz? Ele v\u00ea algo que n\u00e3o est\u00e1 funcionando, percebe o stack trace, pega algumas palavras dele (quais, exatamente, isso \u00e9 seu conhecimento no programa), busca no Google, encontra stackoverflow entre as respostas. Sem ler, sem refletir, entre as respostas \u00e0 pergunta \u2014 ele escolhe algo que pare\u00e7a mais com a frase \"fazer isso e aquilo\" (escolher essa resposta \u00e9 seu talento, pois nem sempre \u00e9 a resposta com mais curtidas), aplica, e observa: se algo mudou, \u00f3timo. Se n\u00e3o mudou \u2014 retrocede. E repetimos a execu\u00e7\u00e3o-verifica\u00e7\u00e3o-busca. E, assim, de forma intuitiva, ele consegue que, ap\u00f3s algum tempo, o c\u00f3digo funcione. Ele n\u00e3o sabe por qu\u00ea, n\u00e3o sabe o que fez, n\u00e3o consegue explicar. Mas! Essa coisa funciona. E o \"inc\u00eandio foi apagado\". Agora vamos entender o que fizemos. Quando o programa funciona \u2014 \u00e9 muito mais f\u00e1cil. E economiza significativamente tempo.<\/p>\n

    Este m\u00e9todo \u00e9 bem explicado atrav\u00e9s deste exemplo.<\/p>\n

    H\u00e1 muito tempo, era muito popular montar um barco \u00e0 vela dentro de uma garrafa. O barco \u00e9 grande e fr\u00e1gil, e o pesco\u00e7o da garrafa \u00e9 muito estreito, n\u00e3o d\u00e1 para empurr\u00e1-lo para dentro. Como montar isso?<\/p>\n

    \"Como
    \n
    \nExiste um m\u00e9todo, muito r\u00e1pido e muito eficaz.<\/p>\n

    O barco consiste em v\u00e1rias pequenas partes: palitos, cordas, velas, cola. Colocamos tudo isso na garrafa.
    \nSeguramos a garrafa com as duas m\u00e3os e come\u00e7amos a chacoalhar. Agitamos, agitamos. E geralmente \u2013 acaba parecendo um desastre, claro. Mas \u00e0s vezes. \u00c0s vezes parece um barco! Mais exatamente, algo que se assemelha a um barco.<\/p>\n

    Mostramos essa coisa para algu\u00e9m: \"Olha, Serguei, voc\u00ea v\u00ea!?\". E de fato, \u00e0 dist\u00e2ncia \u2013 parece um barco. Mas n\u00e3o podemos deixar isso assim.<\/p>\n

    H\u00e1 outro m\u00e9todo. Os caras mais avan\u00e7ados, os hackers, usam isso.<\/p>\n

    Dei uma tarefa para um desses caras, ele fez tudo e saiu. E voc\u00ea olha \u2013 parece estar feito. Mas depois de um tempo, quando \u00e9 necess\u00e1rio aprimorar o c\u00f3digo \u2014 come\u00e7am a surgir problemas por causa dele... Felizmente, ele j\u00e1 tinha se afastado. Esse tipo de gente, que em exemplo da garrafa, faz assim: v\u00ea que onde fica o fundo \u2013 o vidro se curva. E n\u00e3o est\u00e1 t\u00e3o claro se \u00e9 transparente ou n\u00e3o. Ent\u00e3o, os \"hackers\" cortam esse fundo, colocam o barco dentro, colam o fundo de volta, e parece que assim estava certo.<\/p>\n

    Do ponto de vista da formula\u00e7\u00e3o do problema, parece que tudo est\u00e1 certo. Mas no exemplo dos barcos: para que fazer esse barco, quem realmente precisa dele? A funcionalidade que ele oferece \u00e9 nenhuma. Normalmente, esses barcos s\u00e3o presentes para pessoas de alto escal\u00e3o, que os colocam em uma prateleira, como um s\u00edmbolo, como um sinal. E se para uma dessas pessoas, um chefe de um grande neg\u00f3cio ou um funcion\u00e1rio de alta patente, estiver pendurado como bandeira uma coisa t\u00e3o mal feita, onde o pesco\u00e7o foi cortado? \u00c9 melhor que ele nunca descubra isso. Ent\u00e3o, como s\u00e3o feitos esses barcos que podem ser dados a uma pessoa importante?<\/p>\n

    O \u00fanico aspecto, crucial, sobre o qual realmente n\u00e3o se pode fazer nada, \u00e9 o casco. E o casco do navio passa exatamente pela boca da garrafa. Enquanto isso, o navio \u00e9 montado fora da garrafa. Mas n\u00e3o \u00e9 apenas montar o navio, \u00e9 um verdadeiro trabalho artesanal. S\u00e3o adicionados componentes especiais que permitem levant\u00e1-los depois. Por exemplo, as velas s\u00e3o dobradas, cuidadosamente colocadas dentro e, em seguida, com a ajuda de pin\u00e7as, s\u00e3o levantadas e ajustadas com precis\u00e3o. O resultado \u00e9 uma obra de arte que pode ser dada com a consci\u00eancia tranquila e orgulhosamente.<\/p>\n

    E se quisermos que o projeto seja bem-sucedido, deve haver pelo menos uma pessoa-joalheiro na equipe. Algu\u00e9m que se preocupa com a qualidade do produto e considera todos os aspectos, n\u00e3o sacrificando nada, mesmo em momentos de estresse, quando as circunst\u00e2ncias exigem que se fa\u00e7a algo urgente em detrimento do importante. Todos os projetos bem-sucedidos, que s\u00e3o sustent\u00e1veis e resistiram ao teste do tempo, foram constru\u00eddos com esse princ\u00edpio. H\u00e1 algo muito preciso e \u00fanico neles, algo que utiliza todas as possibilidades dispon\u00edveis. No exemplo do navio na garrafa, brinca-se com o fato de que o casco do navio passa pela boca da garrafa.<\/p>\n

    Voltando \u00e0 tarefa de escolher nosso servidor de cache, como esse m\u00e9todo poderia ser aplicado? Eu sugiro uma maneira de escolha entre todos os sistemas dispon\u00edveis \u2014 n\u00e3o balan\u00e7ar a garrafa, n\u00e3o escolher, mas observar o que, em princ\u00edpio, eles t\u00eam que deve ser considerado ao escolher um sistema.<\/p>\n

    Onde procurar o bottleneck<\/h2>\n

    \nVamos tentar n\u00e3o balan\u00e7ar a garrafa, n\u00e3o revisar tudo que temos um por um, mas observar quais problemas surgir\u00e3o se, de repente, para a nossa tarefa \u2014 projetarmos um sistema assim por conta pr\u00f3pria. N\u00e3o construiremos uma bicicleta, mas utilizaremos este esquema para nos orientar sobre quais pontos observar nas descri\u00e7\u00f5es dos produtos. Vamos esbo\u00e7ar esse esquema.<\/p>\n

    \"Como
    \n
    \nSe o sistema for distribu\u00eddo, ent\u00e3o teremos v\u00e1rios servidores (6). Suponhamos que quatro (\u00e9 conveniente represent\u00e1-los na imagem, mas, claro, pode haver quantos forem necess\u00e1rios). Se os servidores est\u00e3o em diferentes n\u00f3s, ent\u00e3o um certo c\u00f3digo est\u00e1 executado em todos eles, respons\u00e1vel por fazer esses n\u00f3s formarem um cluster e, em caso de falha, se reconectarem e se reconhecerem.<\/p>\n

    Ainda precisamos de uma l\u00f3gica de c\u00f3digo (2) que se concentre no cache. Com este c\u00f3digo, os clientes interagem atrav\u00e9s de uma determinada API. O c\u00f3digo do cliente (1) pode estar dentro da mesma JVM ou se conectar a ele pela rede. A l\u00f3gica implementada internamente decide quais objetos manter no cache e quais descartar. Para armazenar o cache, usamos a mem\u00f3ria (3), mas se necess\u00e1rio, algumas informa\u00e7\u00f5es tamb\u00e9m podem ser armazenadas em disco (4).<\/p>\n

    Vamos observar em quais partes a carga ser\u00e1 gerada. Na verdade, cada conex\u00e3o e cada n\u00f3 sofrer\u00e3o sobrecarga. Em primeiro lugar, entre o c\u00f3digo do cliente e a API, caso haja intera\u00e7\u00e3o pela rede, a lat\u00eancia pode ser bastante percept\u00edvel. Em segundo lugar, dentro da pr\u00f3pria API \u2013 se exagerarmos na l\u00f3gica complexa, podemos ter problemas de CPU. \u00c9 melhor que a l\u00f3gica n\u00e3o acesse a mem\u00f3ria desnecessariamente. E ainda temos a intera\u00e7\u00e3o com o sistema de arquivos \u2013 no caso normal, isso envolve serializar \/ restaurar e gravar \/ ler.<\/p>\n

    Em seguida, a intera\u00e7\u00e3o com o cluster. Muito provavelmente, ele estar\u00e1 no mesmo sistema, mas tamb\u00e9m pode estar separado. Aqui tamb\u00e9m \u00e9 necess\u00e1rio considerar a transfer\u00eancia de dados para ele, a velocidade de serializa\u00e7\u00e3o de dados e a intera\u00e7\u00e3o entre o cluster.<\/p>\n

    Agora, de um lado \u2013 podemos visualizar \u201cquais engrenagens estar\u00e3o girando\u201d no sistema de cache ao processar solicita\u00e7\u00f5es do nosso c\u00f3digo e, do outro lado \u2013 podemos estimar quantas e quais solicita\u00e7\u00f5es nosso c\u00f3digo gerar\u00e1 para esse sistema. Isso \u00e9 suficiente para fazer uma escolha mais ou menos racional \u2013 escolher um sistema que se adeque ao nosso caso de uso.<\/p>\n

    Hazelcast<\/b><\/p>\n

    Vamos ver como tal decomposi\u00e7\u00e3o pode ser aplicada \u00e0 nossa lista. Por exemplo, Hazelcast.<\/p>\n

    Para armazenar \/ buscar dados do Hazelcast, o c\u00f3digo do cliente se dirige (1) \u00e0 API. Hz permite iniciar o servidor como embutido, e nesse caso, a chamada \u00e0 API \u00e9 uma invoca\u00e7\u00e3o de m\u00e9todo dentro da JVM, podendo ser considerada gratuita.<\/p>\n

    Para que a l\u00f3gica em (2) funcione, Hz se baseia no hash do array de bytes da chave serializada \u2013 ou seja, a serializa\u00e7\u00e3o da chave ocorrer\u00e1 de qualquer forma. Este \u00e9 um overhead inevit\u00e1vel para Hz.
    \nAs estrat\u00e9gias de exclus\u00e3o est\u00e3o bem implementadas, mas para casos especiais \u2013 \u00e9 poss\u00edvel conectar as suas pr\u00f3prias. N\u00e3o \u00e9 necess\u00e1rio se preocupar com essa parte.<\/p>\n

    O armazenamento (4) pode ser conectado. Excelente. A intera\u00e7\u00e3o (5) para embarcados pode ser considerada instant\u00e2nea. A troca de dados entre os n\u00f3s no cluster (6) \u2013 sim, existe. Isso contribui para a resili\u00eancia em troca de velocidade. O recurso Hz Near-cache permite reduzir o custo \u2013 os dados obtidos de outros n\u00f3s do cluster ser\u00e3o armazenados em cache.<\/p>\n

    O que pode ser feito nessas condi\u00e7\u00f5es para aumentar a velocidade?<\/p>\n

    Por exemplo, para evitar a serializa\u00e7\u00e3o da chave em (2) \u2013 adicionar mais um cache sobre o Hazelcast, para os dados mais quentes. A Sportmaster escolheu o Caffeine para esse fim.<\/p>\n

    Para ajustes no n\u00edvel (6), o Hz oferece dois tipos de armazenamento: IMap e ReplicatedMap.
    \n\"Como
    \n
    \nVale a pena mencionar como o Hazelcast entrou na pilha de tecnologias da Sportmaster.<\/p>\n

    Em 2012, quando est\u00e1vamos trabalhando no primeiro piloto do futuro site, o Hazelcast foi exatamente o primeiro link que o buscador retornou. O encontro aconteceu 'de cara' \u2013 ficamos impressionados que, apenas duas horas ap\u00f3s integrar o Hz ao sistema, ele j\u00e1 estava funcionando. E funcionando bem. No final do dia, completamos alguns testes e ficamos satisfeitos. Essa energia foi suficiente para superar as surpresas que o Hz apresentou com o tempo. Atualmente, a equipe da Sportmaster n\u00e3o tem motivos para se afastar do Hazelcast.<\/p>\n

    Mas argumentos como 'primeiro link no buscador' e 'r\u00e1pido para montar um HelloWorld' s\u00e3o, claro, exce\u00e7\u00f5es e caracter\u00edsticas do momento em que a escolha foi feita. Os verdadeiros desafios para o sistema escolhido come\u00e7am ao entrar em produ\u00e7\u00e3o, e \u00e9 exatamente nessa fase que devemos prestar aten\u00e7\u00e3o ao escolher qualquer sistema, incluindo caches. Na verdade, podemos dizer que escolhemos o Hazelcast por acaso, mas depois percebemos que fizemos a escolha certa.<\/p>\n

    Para produ\u00e7\u00e3o, \u00e9 muito mais importante: monitoramento, tratamento de falhas em n\u00f3s individuais, replica\u00e7\u00e3o de dados, custo de escalonamento. Ou seja, devemos prestar aten\u00e7\u00e3o \u00e0s tarefas que surgir\u00e3 durante a manuten\u00e7\u00e3o do sistema \u2013 quando a carga exceder em dezenas de vezes o planejado, quando acidentalmente carregarmos algo errado e em um lugar errado, quando for necess\u00e1rio implementar uma nova vers\u00e3o do c\u00f3digo, substituir dados e fazer isso de forma transparente para os clientes.<\/p>\n

    Para todas essas exig\u00eancias, o Hazelcast \u00e9, sem d\u00favida, adequado.<\/p>\n

    Continua<\/h2>\n

    \nMas Hazelcast n\u00e3o \u00e9 uma panaceia. Em 2017, escolhemos o Hazelcast para o cache no painel administrativo, simplesmente baseando-nos na boa impress\u00e3o da experi\u00eancia anterior. Isso teve um papel crucial em uma situa\u00e7\u00e3o muito complicada, da qual conseguimos nos recuperar 'heroicamente' ap\u00f3s 60 dias. Mas sobre isso, na pr\u00f3xima parte.<\/p>\n

    E por enquanto\u2026 Feliz Novo C\u00f3digo!
    \n
    Fonte:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73950,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73949","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Como escolhemos o sistema de cache na Sportmaster. Parte 1 | ProHoster","description":"Ol\u00e1! Meu nome \u00e9 Alexey Pyankov, sou desenvolvedor na empresa Sportmaster.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u0432 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-12T23:42:07+00:00","article:modified_time":"2020-03-12T23:42:07+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73949","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:23:51","updated":"2022-09-28 05:05:57","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/73949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}