Uma solução complexa para os problemas simples dos serviços HighLoad WEB

Uma tarefa importante de sistemas WEB altamente carregados é a capacidade de processar um grande número de solicitações. Este problema pode ser resolvido de diferentes maneiras. Neste artigo, proponho considerar um método incomum para otimizar solicitações de back-end por meio da tecnologia de faixa de conteúdo (faixa). Ou seja, reduzir seu número sem perder a qualidade do sistema por meio de cache eficiente.

Para começar, proponho estudar um artigo em que o preâmbulo da tecnologia com um exemplo para o S2S é apresentado de forma concisa e inteligível. Além disso, é aconselhável conhecer meu primeiro artigo sobre o uso dessa tecnologia para otimizar o trabalho com dados de mercado em um projeto de troca de criptomoedas.

Neste artigo, quero mostrar que essa tecnologia pode ser usada mais amplamente do que o primeiro artigo demonstrado. Deixe-me lembrá-lo de que as informações comerciais ( velas ) são obtidas por solicitações de intervalo para arquivos estáticos, que são previamente preparados por um serviço especial. Agora, quero considerar as solicitações de um back-end completo usando os mesmos dados de mercado como exemplo e pelas mesmas velas, sem perder os principais lucros.

Então, o que está planejado para alcançar:

1. Otimize solicitações de back-end (reduza seu número);
2. Aumente a velocidade de entrega de conteúdo ao usuário final;
3. Otimize o tráfego.

Mais uma vez, enfatizo que a tecnologia de alcance é um padrão ( RFC 2616 ). É suportado nativamente pelos navegadores e eles podem armazenar em cache partes dos dados recebidas. Portanto, a próxima solicitação do navegador, se houver um cache real da parte solicitada, é implementada no cliente sem atrapalhar seus servidores.

Se você adicionar CDN entre o cliente e os servidores, poderá obter outra camada poderosa de armazenamento em cache. E se, no primeiro caso, o cache ocorrerá para um cliente final específico e, em seguida, emparelhado com uma CDN, você terá a oportunidade de armazenar em cache os dados já de um grupo de clientes finais.

Portanto, para fazer uma solicitação real ao servidor, a solicitação precisa superar dois níveis de cache, cada um dos quais reduz o volume de solicitações ao servidor de destino. Obviamente, o "reduto" final, no caminho da solicitação, pode ser seu servidor com seu cache.

Dos recursos do uso da tecnologia de alcance, é necessário considerar que ele funciona com partes de bytes. I.e. com dados binários. E podemos solicitar exatamente intervalos de bytes. Eles devem responder, respectivamente - com um bloco binário.

Eu acho bastante introdutório. Vamos para um caso especial e, a título de exemplo, descobriremos como podemos usar toda essa "felicidade" em um problema específico - solicitar velas por um determinado intervalo com uma determinada exposição.

Para iniciantes, como precisamos trabalhar com estruturas binárias, vamos codificar nossa vela. Para isso, tomamos, por exemplo, a seguinte estrutura:

moment: int32 //   min: float64 //   max: float64 //   open: float64 //   close: float64 //   volume: float64 //  average: float64 //   

Assim, nossa estrutura ocupará 52 bytes. Tomamos isso como um quantum - o bloco binário mínimo.

Em seguida, implementamos um controlador que aceita solicitações GET e analisa o cabeçalho do intervalo. Nesse caso, traduziremos o intervalo solicitado em quanta por divisão simples sem restante, ou seja, por exemplo, uma solicitação de intervalo:

Range: 5200-52000

Devemos interpretar na dimensão do nosso quantum como:

Range: 100-1000

Em essência, esse será o deslocamento e o limite da nossa consulta ao banco de dados.

Com a definição de exposição é muito simples, podemos colocá-lo no URL. Por exemplo:

/api/v1/candles/7m

I.e. solicitaremos velas com uma exposição de 7 minutos. Naturalmente, assumimos que esse parâmetro pode ser alterado a pedido do frontend.

Agora, sabendo a exposição necessária, o número da primeira vela e o número da última vela solicitada pelo frontend, podemos executar a consulta correspondente ao banco de dados.

Geralmente, lembra muito o problema clássico de paginação.

Restam pequenas coisas. Cada linha do resultado da consulta é convertida em uma estrutura binária (o mesmo quantum) e a matriz binária resultante é exibida como resultado da consulta, e o intervalo de conteúdo é retornado ao cabeçalho da resposta:

Content-Range: [ ] / [[ ] * [ ]]

Parar Mas como o front-end pode solicitar o intervalo de tempo desejado, e mesmo no intervalo de bytes? Como ele conhece algum número de vela lá? Aqui também tudo foi inventado. A faixa suporta deslocamento relativo, p.

Range: -52

Solicite 52 bytes do final. I.e. a última vela. Agora, sabendo o último momento da última vela, sabendo, pela resposta, o tamanho total do "arquivo", você pode calcular o número total de velas e, a partir daqui, determinar o intervalo de bytes para solicitar a exposição de tempo desejada.

Se você de repente quis fazer uma pergunta - por que essas dificuldades? Por favor, retorne aos seus objetivos. Essa tecnologia "mascarou" as consultas analíticas ao banco de dados em arquivos binários para a CDN e o navegador. Isso permite transferir a maioria das solicitações repetidas para a CDN e o cliente final.

Talvez outra questão surja - por que não usar o cache simples de solicitações GET? Bom Vamos acertar. Se executarmos essa solicitação no REST clássico:

GET /api/v1/candles/7m?from=01-03-2018&to=31-03-2018

Obteremos um cache exclusivo para esta solicitação. Executando a seguinte consulta:

GET /api/v1/candles/7m?from=15-03-2018&to=20-03-2018

Obteremos outro cache exclusivo .... embora, observe que o segundo pedido solicite os dados incluídos na resposta do primeiro.

Portanto, no caso da implementação proposta acima (intervalo), a segunda solicitação não formará um cache separado, mas usará os dados já recebidos da primeira solicitação. E não vai entrar no servidor. E isso, salvando o tamanho dos caches e reduzindo o número de chamadas para o servidor.

Há alguma desvantagem nessa tecnologia? Sim Eles são óbvios:

1. Esta tecnologia não é adequada para alteração de dados ao longo do tempo, pois com base no cache total.
2. O CDN CloudFlare apenas armazena em cache os arquivos completamente. Isso significa que, se o cliente final solicitar um intervalo de, digamos, 1 a 100 bytes, o CloudFlare realmente solicitará o arquivo inteiro do servidor. I.e. no nosso caso, ele carregará todas as velas com uma certa exposição. Ele o colocará por conta própria e já o distribuirá. Isso pode até ser considerado uma vantagem, se não for pelas restrições no local. E se você pode formar respostas "pesadas" e muitos parâmetros, então ... Em geral, é claro que o local terminará. Talvez não tenhamos conseguido configurá-lo corretamente. Mas até agora o resultado é o seguinte.
3. É necessário gerenciar caches com sabedoria. Existem mecanismos suficientes para isso, mas eles exigem ajuste.
4. O frontend deve ser capaz de analisar dados binários e ter um conjunto de dados ala incorporado para trabalhar com solicitações de intervalo.

Eu formularia a viabilidade de implementar essa estratégia da seguinte maneira - quando você precisar, você entenderá. Se agora houver dúvidas, é útil saber sobre ela, mas não se incomode.