Olá! Meu nome é Alexey Pyankov, sou desenvolvedor da empresa Sportmaster. Naquilo Contei como começou o trabalho no site Sportmaster em 2012, quais iniciativas conseguimos “impulsionar” e vice-versa, que rake arrecadamos.
Hoje quero compartilhar ideias que seguem outro tópico - escolha de um sistema de cache para o backend java no painel de administração do site. Esse enredo tem um significado especial para mim - embora a história tenha se desenrolado por apenas 2 meses, durante esses 60 dias trabalhamos de 12 a 16 horas e sem um único dia de folga. Nunca pensei ou imaginei que fosse possível trabalhar tanto.
Portanto, divido o texto em 2 partes para não carregá-lo completamente. Pelo contrário, a primeira parte será muito leve – preparação, introdução, algumas considerações sobre o que é cache. Se você já é um desenvolvedor experiente ou já trabalhou com caches, do lado técnico provavelmente não haverá nada de novo neste artigo. Mas para um júnior, uma revisão tão pequena pode lhe dizer em que direção olhar se ele se encontrar em tal encruzilhada.
Quando a nova versão do site Sportmaster foi colocada em produção, os dados foram recebidos de uma forma que, para dizer o mínimo, não foi muito conveniente. A base foram tabelas preparadas para a versão anterior do site (Bitrix), que tiveram que ser puxadas para ETL, trazidas para um novo formato e enriquecidas com várias coisinhas de mais uma dezena de sistemas. Para que uma nova foto ou descrição de produto aparecesse no site, era preciso esperar até o dia seguinte - atualizações apenas à noite, uma vez por dia.
No início, havia tantas preocupações desde as primeiras semanas de produção que tais inconvenientes para os gerenciadores de conteúdo eram insignificantes. Mas, assim que tudo se acalmou, o desenvolvimento do projeto continuou - alguns meses depois, no início de 2015, começamos a desenvolver ativamente o painel de administração. Em 2015 e 2016 está tudo indo bem, lançamos regularmente, o painel de administração cobre cada vez mais a preparação dos dados, e estamos nos preparando para o fato de que em breve nossa equipe será encarregada do mais importante e complexo - o produto circuito (preparação e manutenção completa dos dados de todos os produtos). Mas no verão de 2017, pouco antes do lançamento do circuito de commodities, o projeto se encontrará em uma situação muito difícil – justamente por causa de problemas de cache. Quero falar sobre esse episódio na segunda parte desta publicação em duas partes.
Mas neste post vou começar de longe, vou apresentar algumas reflexões - ideias sobre cache, o que seria um bom passo para percorrer antes de um grande projeto.
Quando ocorre uma tarefa de cache
A tarefa de cache não aparece apenas. Somos desenvolvedores, escrevemos um produto de software e queremos que ele tenha demanda. Se o produto for procurado e bem-sucedido, os usuários virão. E mais e mais vêm. E então há muitos usuários e o produto fica altamente carregado.
Nos primeiros estágios, não pensamos em otimização e desempenho do código. O principal é a funcionalidade, lançando rapidamente um piloto e testando hipóteses. E se a carga aumentar, bombeamos o ferro. Aumentamos duas ou três vezes, cinco vezes, talvez 10 vezes. Em algum lugar aqui – as finanças não permitem mais isso. Quantas vezes o número de usuários aumentará? Não será 2-5-10, mas se for bem-sucedido, será de 100-1000 a 100 mil vezes. Ou seja, mais cedo ou mais tarde você terá que fazer otimização.
Digamos que alguma parte do código (vamos chamar essa parte de função) leva um tempo indecentemente longo e queremos reduzir o tempo de execução. Uma função pode ser o acesso a um banco de dados, ou pode ser a execução de alguma lógica complexa - o principal é que demora muito para ser concluída. Quanto você pode reduzir o tempo de execução? No limite, você pode reduzi-lo a zero, nada mais. Como você pode reduzir o tempo de execução a zero? Resposta: elimine completamente a execução. Em vez disso, retorne o resultado imediatamente. Como você pode descobrir o resultado? Resposta: calcule ou procure em algum lugar. Demora muito para calcular. E espionar é, por exemplo, lembrar o resultado que a função produziu na última vez quando chamada com os mesmos parâmetros.
Ou seja, a implementação da função não é importante para nós. Basta saber de quais parâmetros depende o resultado. Então, se os valores dos parâmetros forem representados na forma de um objeto que pode ser usado como chave em algum armazenamento, o resultado do cálculo poderá ser salvo e lido na próxima vez que for acessado. Se essa escrita e leitura do resultado for mais rápida que a execução da função, temos lucro em termos de velocidade. O valor do lucro pode chegar a 100, 1000 e 100 mil vezes (10^5 é uma exceção, mas no caso de uma base bastante atrasada, é bem possível).
Requisitos básicos para um sistema de cache
A primeira coisa que pode se tornar um requisito para um sistema de cache é a velocidade de leitura rápida e, em menor grau, a velocidade de gravação. Isso é verdade, mas apenas até implementarmos o sistema em produção.
Vamos jogar este caso.
Digamos que fornecemos hardware à carga atual e agora estamos introduzindo gradualmente o cache. O número de usuários cresce um pouco, a carga aumenta - adicionamos alguns caches, aparafusamos aqui e ali. Isso continua por algum tempo, e agora funções pesadas praticamente não são mais chamadas - toda a carga principal recai sobre o cache. O número de usuários durante esse período aumentou N vezes.
E se o fornecimento inicial de hardware pudesse ser de 2 a 5 vezes, então com a ajuda do cache poderíamos melhorar o desempenho por um fator de 10 ou, em um bom caso, por um fator de 100, em alguns lugares talvez por um fator de 1000. Ou seja, no mesmo hardware – processamos 100 vezes mais solicitações. Ótimo, você merece o pão de gengibre!
Mas agora, num belo momento, por acaso, o sistema travou e o cache entrou em colapso. Nada de especial - afinal, o cache foi escolhido com base no requisito “alta velocidade de leitura e gravação, o resto não importa”.
Em relação à carga inicial, nossa reserva de ferro foi de 2 a 5 vezes, e a carga durante esse período aumentou de 10 a 100 vezes. Usando o cache, eliminamos chamadas para funções pesadas e com isso tudo funcionou. E agora, sem cache, quantas vezes nosso sistema ficará lento? o que vai acontecer conosco? O sistema cairá.
Mesmo que nosso cache não tenha travado, mas tenha sido limpo apenas por um tempo, ele precisará ser aquecido, e isso levará algum tempo. E durante esse período, o fardo principal recairá sobre a funcionalidade.
Conclusão: projetos de produção altamente carregados exigem um sistema de cache não apenas para ter altas velocidades de leitura e gravação, mas também para garantir a segurança dos dados e a resistência a falhas.
A agonia da escolha
Em um projeto com painel de administração, a escolha foi assim: primeiro instalamos o Hazelcast, porque Já estávamos familiarizados com este produto pela experiência do site principal. Mas aqui essa escolha não teve sucesso - sob nosso perfil de carga, o Hazelcast não é apenas lento, mas terrivelmente lento. E naquela época já tínhamos assinado a data de lançamento.
Spoiler: como exatamente se desenvolveram as circunstâncias para que perdemos um negócio tão importante e acabamos em uma situação aguda e tensa - contarei na segunda parte - e como terminamos e como saímos. Mas agora - direi apenas que foi muito estressante e "pensar - de alguma forma não consigo pensar, estamos sacudindo a garrafa". “Agitar a garrafa” também é um spoiler, falaremos mais sobre isso depois.
O que fizemos:
- Fazemos uma lista de todos os sistemas sugeridos pelo Google e StackOverflow. Um pouco mais de 30
- Escrevemos testes com carga típica de produção. Para isso, registramos os dados que passam pelo sistema em ambiente de produção – uma espécie de sniffer de dados não na rede, mas dentro do sistema. Exatamente esses dados foram usados nos testes.
- Com toda a equipe, todos selecionam o próximo sistema da lista, configuram-no e executam testes. Não passa no teste, não carrega a carga – jogamos fora e passamos para o próximo da fila.
- No 17º sistema ficou claro que tudo estava perdido. Pare de sacudir a garrafa, é hora de pensar seriamente.
Mas esta é uma opção quando você precisa escolher um sistema que vai “atravessar a velocidade” em testes pré-preparados. E se ainda não existirem esses testes e você quiser escolher rapidamente?
Vamos simular esta opção (é difícil imaginar que um desenvolvedor middle+ viva no vácuo, e no momento da seleção ainda não tenha formalizado sua preferência sobre qual produto experimentar primeiro - portanto, o raciocínio adicional é mais um teórico/filosofia/ sobre um júnior).
Tendo decidido os requisitos, começaremos a selecionar uma solução pronta para uso. Por que reinventar a roda: vamos usar um sistema de cache pronto.
Se você está apenas começando e pesquisa no Google, dê ou receba o pedido, mas em geral as orientações serão assim. Em primeiro lugar, você encontrará o Redis, ele é ouvido em todos os lugares. Então você descobrirá que o EhCache é o sistema mais antigo e comprovado. A seguir escreveremos sobre o Tarantool, um desenvolvimento nacional que possui um aspecto único de solução. E também o Ignite, porque sua popularidade está crescendo e conta com o apoio da SberTech. No final tem também o Hazelcast, porque no mundo empresarial ele aparece frequentemente entre as grandes empresas.
A lista não é exaustiva; existem dezenas de sistemas. E só vamos estragar uma coisa. Vamos pegar os 5 sistemas selecionados para o “concurso de beleza” e fazer uma seleção. Quem será o vencedor?
Redis
Lemos o que eles escrevem no site oficial.
- projeto de código aberto. Oferece armazenamento de dados na memória, capacidade de salvar em disco, particionamento automático, alta disponibilidade e recuperação de interrupções na rede.
Parece que está tudo bem, você pode pegar e parafusar - tudo que você precisa, ele faz. Mas, só por diversão, vamos dar uma olhada nos outros candidatos.
EhCache
- “o cache mais utilizado para Java” (tradução do slogan do site oficial). Também de código aberto. E então entendemos que o Redis não é para java, mas sim geral, e para interagir com ele é necessário um wrapper. E o EhCache será mais conveniente. O que mais o sistema promete? Confiabilidade, funcionalidade comprovada e completa. Bem, também é o mais comum. E armazena em cache terabytes de dados.
Redis foi esquecido, estou pronto para escolher o EhCache.
Mas um sentimento de patriotismo me leva a ver o que há de bom no Tarantool.
Tarantool
- atende à designação “Plataforma de integração de dados em tempo real”. Parece muito complicado, então lemos a página em detalhes e encontramos uma afirmação em voz alta: “Armazena 100% dos dados em cache na RAM”. Isso deve levantar questões - afinal, pode haver muito mais dados do que memória. A explicação é que isso significa que o Tarantool não executa serialização para gravar dados da memória no disco. Em vez disso, ele usa recursos de baixo nível do sistema, quando a memória é simplesmente mapeada para um sistema de arquivos com desempenho de E/S muito bom. Em geral, eles fizeram algo maravilhoso e legal.
Vejamos as implementações: rodovia corporativa Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Se ainda havia dúvidas sobre o Tarantool, então o caso de implementação na Mastercard acaba comigo. Eu pego Tarantool.
Mas mesmo assim…
Inflamar
... há mais algum , é anunciado como uma “plataforma de computação na memória... velocidades na memória em petabytes de dados”. Há também muitas vantagens aqui: cache distribuído na memória, armazenamento e cache de valor-chave mais rápidos, escalonamento horizontal, alta disponibilidade e integridade estrita. Em geral, verifica-se que o mais rápido é o Ignite.
Implementações: Sberbank, American Airlines, Yahoo! Japão. E então descubro que o Ignite não é implementado apenas no Sberbank, mas a equipe da SberTech envia seu pessoal para a própria equipe do Ignite para refinar o produto. Isso é completamente cativante e estou pronto para usar o Ignite.
Não está completamente claro por que, estou olhando para o quinto ponto.
Castanha de avelã
eu vou ao site , leitura. E acontece que a solução mais rápida para cache distribuído é o Hazelcast. É muito mais rápido do que todas as outras soluções e, em geral, é líder no campo de grade de dados na memória. Neste contexto, aceitar outra coisa é não respeitar a si mesmo. Ele também usa armazenamento de dados redundante para operação contínua do cluster sem perda de dados.
É isso, estou pronto para fazer o Hazelcast.
Comparação
Mas se você olhar, todos os cinco candidatos são descritos de tal forma que cada um deles é o melhor. Como escolher? Podemos ver qual é o mais popular, procurar comparações e a dor de cabeça vai passar.
Encontramos um assim , escolha nossos 5 sistemas.
Aqui estão eles classificados: Redis está no topo, Hazelcast está em segundo lugar, Tarantool e Ignite estão ganhando popularidade, EhCache foi e continua o mesmo.
Mas vamos dar uma olhada : links para sites, interesse geral no sistema, ofertas de emprego - ótimo! Ou seja, quando meu sistema falhar, direi: “Não, é confiável! Há muitas ofertas de emprego..." Uma comparação tão simples não servirá.
Todos esses sistemas não são apenas sistemas de cache. Eles também possuem muitas funcionalidades, inclusive quando os dados não são bombeados para o cliente para processamento, mas vice-versa: o código que precisa ser executado nos dados vai para o servidor, é executado lá e o resultado é retornado. E nem sempre são considerados um sistema separado de armazenamento em cache.
Ok, não vamos desistir, vamos encontrar uma comparação direta dos sistemas. Vejamos as duas opções principais – Redis e Hazelcast. Estamos interessados na velocidade e iremos compará-las com base neste parâmetro.
Hz x Redis
Nós encontramos isso :
Azul é Redis, vermelho é Hazelcast. O Hazelcast vence em todos os lugares, e há uma justificativa para isso: é multithread, altamente otimizado, cada thread funciona com sua própria partição, portanto não há bloqueios. E o Redis é de thread único; ele não se beneficia das modernas CPUs multi-core. Hazelcast possui E/S assíncrona, Redis-Jedis possui soquetes de bloqueio. Afinal, o Hazelcast usa um protocolo binário e o Redis é centrado em texto, o que significa que é ineficiente.
Por precaução, vamos recorrer a outra fonte de comparação. O que ele vai nos mostrar?
Redis x Hz
outro :
Aqui, ao contrário, o vermelho é Redis. Ou seja, o Redis supera o Hazelcast em termos de desempenho. Hazelcast venceu a primeira comparação, Redis venceu a segunda. explicou com muita precisão por que Hazelcast venceu a comparação anterior.
Acontece que o resultado do primeiro foi realmente fraudado: o Redis foi levado na caixa base e o Hazelcast foi adaptado para um caso de teste. Acontece que: em primeiro lugar, não podemos confiar em ninguém e, em segundo lugar, quando finalmente escolhemos um sistema, ainda precisamos configurá-lo corretamente. Essas configurações incluem dezenas, quase centenas de parâmetros.
Agitando a garrafa
E posso explicar todo o processo que fizemos agora com a seguinte metáfora: “Agitando a garrafa”. Ou seja, agora você não precisa programar, agora o principal é conseguir ler o stackoverflow. E tenho uma pessoa na minha equipe, um profissional, que trabalha exatamente assim nos momentos críticos.
O que ele está fazendo? Ele vê uma coisa quebrada, vê um stack trace, tira algumas palavras dela (quais são suas especialidades no programa), pesquisa no Google, encontra stackoverflow entre as respostas. Sem ler, sem pensar, entre as respostas à pergunta, ele escolhe algo mais parecido com a frase “faça isso e aquilo” (escolher tal resposta é seu talento, pois nem sempre é a resposta que recebe mais curtidas), aplica-se, parece: se algo mudou, ótimo. Se não mudou, reverta. E repita a pesquisa de verificação de lançamento. E dessa forma intuitiva ele garante que o código funcione depois de algum tempo. Ele não sabe por que, não sabe o que fez, não consegue explicar. Mas! Esta infecção funciona. E “o fogo está extinto”. Agora vamos descobrir o que fizemos. Quando o programa funciona, é muito mais fácil. E isso economiza muito tempo.
Este método é muito bem explicado com este exemplo.
Já foi muito popular montar um veleiro em uma garrafa. Ao mesmo tempo, o veleiro é grande e frágil, e o gargalo da garrafa é muito estreito, sendo impossível empurrá-la para dentro. Como montá-lo?
Existe um método assim, muito rápido e muito eficaz.
O navio consiste em um monte de coisinhas: paus, cordas, velas, cola. Colocamos tudo isso em uma garrafa.
Pegamos a garrafa com as duas mãos e começamos a tremer. Nós a sacudimos e sacudimos. E geralmente acaba sendo um lixo completo, é claro. Mas às vezes. Às vezes acaba sendo um navio! Mais precisamente, algo semelhante a um navio.
Mostramos isso para alguém: “Seryoga, você vê!?” E, de fato, de longe parece um navio. Mas não podemos permitir que isto continue.
Existe outra maneira. Eles são usados por caras mais avançados, como hackers.
Dei uma tarefa para esse cara, ele fez tudo e foi embora. E você olha - parece que está feito. E depois de um tempo, quando o código precisa ser finalizado, isso começa por causa dele... Ainda bem que ele já conseguiu fugir para longe. São esses caras que, usando o exemplo de uma garrafa, vão fazer isso: você vê, onde fica o fundo, o vidro entorta. E não está totalmente claro se é transparente ou não. Aí os “hackers” cortam esse fundo, colocam um navio ali, depois colam o fundo novamente, e é como se fosse assim que deveria ser.
Do ponto de vista da definição do problema, tudo parece correto. Mas usando os navios como exemplo: por que fazer este navio, afinal, quem precisa dele? Ele não fornece nenhuma funcionalidade. Geralmente esses navios são presentes para pessoas de alto escalão, que os colocam em uma prateleira acima deles, como uma espécie de símbolo, como um sinal. E se tal pessoa for o chefe de uma grande empresa ou um funcionário de alto escalão, como a bandeira representará tal hacker, cujo pescoço foi cortado? Seria melhor se ele nunca soubesse disso. Então, como eles acabam fazendo esses navios que podem ser doados a uma pessoa importante?
O único lugar-chave sobre o qual você realmente não pode fazer nada é o corpo. E o casco do navio cabe perfeitamente no pescoço. Já o navio é montado fora da garrafa. Mas não se trata apenas de montar um navio, é uma verdadeira joalheria. Alavancas especiais são adicionadas aos componentes, que permitem que eles sejam levantados. Por exemplo, as velas são dobradas, cuidadosamente trazidas para dentro e depois, com a ajuda de uma pinça, são puxadas e levantadas com muita precisão, com precisão. O resultado é uma obra de arte que pode ser dotada de consciência tranquila e orgulho.
E se quisermos que o projeto tenha sucesso, é preciso que haja pelo menos um joalheiro na equipe. Alguém que se preocupa com a qualidade do produto e leva em consideração todos os aspectos, sem sacrificar nada, mesmo em momentos de estresse, quando as circunstâncias exigem fazer o urgente em detrimento do importante. Todos os projetos bem-sucedidos, sustentáveis e que resistiram ao teste do tempo, baseiam-se neste princípio. Há algo muito preciso e único neles, algo que aproveita todas as possibilidades disponíveis. No exemplo do navio na garrafa, o fato de o casco do navio passar pelo gargalo se destaca.
Voltando à tarefa de escolher nosso servidor de cache, como esse método pode ser aplicado? Ofereço esta opção de escolher entre todos os sistemas que existem - não agite a garrafa, não escolha, mas veja o que eles têm em princípio, o que procurar na hora de escolher um sistema.
Onde procurar gargalo
Vamos tentar não sacudir a garrafa, não repassar tudo o que está lá um por um, mas vamos ver quais problemas surgirão se de repente, para nossa tarefa, projetarmos nós mesmos esse sistema. É claro que não montaremos a bicicleta, mas usaremos este diagrama para nos ajudar a descobrir quais pontos prestar atenção nas descrições dos produtos. Vamos esboçar esse diagrama.
Se o sistema for distribuído, teremos vários servidores (6). Digamos que sejam quatro (é conveniente colocá-los na imagem, mas, claro, pode haver quantos você quiser). Se os servidores estiverem em nós diferentes, significa que todos eles executam algum código que é responsável por garantir que esses nós formem um cluster e, em caso de quebra, se conectem e se reconheçam.
Também precisamos de lógica de código (2), que na verdade trata de armazenamento em cache. Os clientes interagem com este código por meio de alguma API. O código do cliente (1) pode estar na mesma JVM ou acessá-lo pela rede. A lógica implementada internamente é a decisão de quais objetos deixar no cache e quais descartar. Usamos memória (3) para armazenar o cache, mas se necessário, podemos salvar alguns dados no disco (4).
Vamos ver em quais partes ocorrerá a carga. Na verdade, cada seta e cada nó serão carregados. Em primeiro lugar, entre o código do cliente e a API, se for uma comunicação de rede, a subsidência pode ser bastante perceptível. Em segundo lugar, dentro da estrutura da própria API - se exagerarmos na lógica complexa, podemos ter problemas com a CPU. E seria bom se a lógica não perdesse tempo com memória. E a interação com o sistema de arquivos permanece - na versão normal isso é serializar/restaurar e gravar/ler.
A seguir vem a interação com o cluster. Muito provavelmente, estará no mesmo sistema, mas poderá estar separadamente. Aqui você também precisa levar em consideração a transferência de dados para ele, a velocidade de serialização dos dados e as interações entre o cluster.
Agora, por um lado, podemos imaginar “quais engrenagens irão girar” no sistema de cache ao processar solicitações do nosso código e, por outro lado, podemos estimar quais e quantas solicitações nosso código irá gerar para este sistema. Isso é suficiente para fazer uma escolha mais ou menos sóbria - escolher um sistema para o nosso caso de uso.
Castanha de avelã
Vamos ver como aplicar esta decomposição à nossa lista. Por exemplo, Hazelcast.
Para colocar/retirar dados do Hazelcast, o código do cliente acessa (1) a API. Hz permite rodar o servidor como embarcado e, neste caso, o acesso à API é uma chamada de método dentro da JVM, que pode ser considerada gratuita.
Para que a lógica em (2) funcione, Hz depende do hash da matriz de bytes da chave serializada - ou seja, a chave será serializada em qualquer caso. Esta é uma sobrecarga inevitável para Hz.
As estratégias de despejo são bem implementadas, mas para casos especiais você pode adicionar as suas próprias. Você não precisa se preocupar com esta parte.
O armazenamento (4) pode ser conectado. Ótimo. A interação (5) para embarcados pode ser considerada instantânea. Troca de dados entre nós do cluster (6) - sim, existe. Este é um investimento em tolerância a falhas em detrimento da velocidade. O recurso Hz Near-cache permite reduzir o preço - os dados recebidos de outros nós do cluster serão armazenados em cache.
O que pode ser feito nessas condições para aumentar a velocidade?
Por exemplo, para evitar a serialização da chave em (2) - anexe outro cache no topo do Hazelcast, para os dados mais recentes. A Sportmaster escolheu a cafeína para este propósito.
Para torção no nível (6), o Hz oferece dois tipos de armazenamento: IMap e ReplicatedMap.
Vale a pena mencionar como o Hazelcast entrou na pilha de tecnologia Sportmaster.
Em 2012, quando estávamos trabalhando no primeiro piloto do futuro site, foi o Hazelcast que acabou sendo o primeiro link que o mecanismo de busca retornou. O conhecimento começou “pela primeira vez” - ficamos cativados pelo fato de que apenas duas horas depois, quando inserimos o Hz no sistema, ele funcionou. E funcionou bem. No final do dia havíamos completado vários testes e estávamos felizes. E essa reserva de vigor foi suficiente para superar as surpresas que Hz trouxe ao longo do tempo. Agora a equipe Sportmaster não tem motivos para abandonar o Hazelcast.
Mas argumentos como “o primeiro link no motor de busca” e “HelloWorld foi rapidamente montado” são, claro, uma excepção e uma característica do momento em que a escolha ocorreu. Os verdadeiros testes do sistema escolhido começam com a entrada em produção, e é nesta fase que você deve prestar atenção na hora de escolher qualquer sistema, inclusive o cache. Na verdade, no nosso caso podemos dizer que escolhemos o Hazelcast por acidente, mas depois descobrimos que escolhemos corretamente.
Para produção, muito mais importante: monitoramento, tratamento de falhas em nós individuais, replicação de dados, custo de escalonamento. Ou seja, vale a pena ficar atento às tarefas que surgirão durante a manutenção do sistema - quando a carga for dezenas de vezes maior do que o planejado, quando acidentalmente carregamos algo no lugar errado, quando precisamos lançar uma nova versão do código, substitua os dados e faça isso despercebido pelos clientes.
Para todos esses requisitos, o Hazelcast certamente se enquadra no projeto.
Continua
Mas Hazelcast não é uma panacéia. Em 2017, escolhemos o Hazelcast para o cache de administração, simplesmente com base nas boas impressões de experiências anteriores. Isso desempenhou um papel fundamental em uma piada muito cruel, pela qual nos encontramos em uma situação difícil e “heroicamente” saímos dela por 60 dias. Mas mais sobre isso na próxima parte.
Enquanto isso... Feliz Novo Código!
Fonte: habr.com