Quando o projeto foi introduzido Redis não distribuídos cache, ele irá enfrentar este problema:
- Que dados devem ser colocados em cache? Em que base?
- dados em cache é atualizado com ativo ou expirado automaticamente expirar?
- Se expirado expira automaticamente, então o tempo de expiração como desenvolver?
Apenas duas semanas fazemos um projecto relacionado com a avaliação, o registro de processos e participação social; de usado curso no processo de um monte de "estranho" se você tem uma maneira melhor, espero ação.
01
projeto de fundo
Nosso projeto é uma plataforma de serviços pura, que é o único serviço que fornece uma interface, e nenhuma página de funcionamento, a interface chama quantidade diária do projeto é de cerca de 200 milhões de vezes, o pico de 10 milhões terá sucesso, porque a maior parte da interface é para sistema interno , de modo mais solicitados concentrada no 9:00-21:00 nos dias de semana, QPS quando o sistema de pico entre 300-400.
Porque nós armazenar dados do projeto usando MongoDB, em teoria, o apoio QPS dessa magnitude deve ser mais do que suficiente, mas eu tenho algumas observações e considerar assim:
Embora a integração do MongoDB é bons dados, mas muitas cenas não são única consulta, exagerada quando uma interface pode retornar centenas de pedaços de dados, pacotes de referência para trás têm mais de vinte mil linhas (não me pergunte não pode ser paginada para retorno .. .... claramente diga que não);
- Embora a integração do MongoDB é bons dados, mas muitas cenas não são única consulta, exagerada quando uma interface pode retornar centenas de pedaços de dados, pacotes de referência para trás têm mais de vinte mil linhas (não me pergunte não pode ser paginada para retorno .. .... claramente diga que não);
- 99,95% do projeto atual o tempo de resposta da interface de dezenas a centenas de milissegundos, para satisfazer as necessidades básicas do negócio, mas ainda 0,05% estão em resposta a pedidos de mais de 1s, ocasionalmente, até mesmo chegar a 5s, 10s;
- Olhando para estes longo tempo de resposta do pedido, a maior parte do tempo consumido pela consulta MongoDB, mas quando gostaria de solicitar mensagem manualmente quando a interface chamada novamente, ainda retorno milissegundo; configuração MongoDB em geral, sempre atualizados dados, e eu tenho observado, tempo de resposta longo dessas interfaces, solicitando que ponto no tempo particularmente grande quantidade;
- A razão ocasionalmente MongoDB consulta lenta Confirmo que foi a razão que eu posso pensar, tais como: um grande número de operações de escrita afeta operação de leitura, a tabela de bloqueio, o índice é menor que o tamanho da memória, etc., sendo que é o momento em que a pressão MongoDB; I observado, estas interfaces de tempo de resposta é muito tempo, o ponto de tempo que uma particularmente grande volume de pedidos, que é não especificamente aqui analisada.
Embora o pedido apenas dez mil vezes quatro ou cinco vezes o tempo de resposta de uma exceção, mas como mais acesso mais e para o item solicitado, mudança qualitativa quantitativa após Paul faltando, ainda tentam crise estrangulado no berço, de forma tão decisiva na distribuição de Redis fazer caching.
02
pentear Interface
O próximo passo é produzir estatísticas ambientais e resolver as interfaces para determinar quais interfaces pode ser colocado no cache, então é preciso primeiro ter uma estatística em bruto para cada interface para o volume de chamadas, porque não há nenhuma plataforma de log de acesso existente, então eu usei a maneira estúpida mais, uma série de coisa de uma interface.
- Um dia, o log dia de trabalho puxado para baixo, os nossos servidores quatro aplicações, registro diário sobre um G, ok ok;
- [Encontrar no Files] EditPlus através desta função ferramenta para encontrar o volume de chamadas no dia de cada interface, a interface tem sido na linha 30, descobriu alguns minutos, porque é um trabalho de uma só vez, simplesmente contadas manualmente;
- Várias vezes por dia não pode interface de sintonizar diretamente ignorada, eu basicamente só colocar milhões para as interfaces diárias volume de chamadas para estadia, o próximo passo da análise.
03
Dados tabela de dicionário, a configuração da classe
Este tipo de dados é o mais apto no cache, porque depois a frequência de atualização é particularmente baixa, e às vezes até mesmo inserir a'll haver atualização, se tais dados é maior do que a chamada que é certo para colocar em Redis de;
Quanto à estratégia de cache, você pode dobrar o tempo para escrever e atualizar o banco de dados Redis, modo de falha automática também pode ser usado, é claro, o tempo de expiração pode ser mais longo do que colocar um número, para o nosso projeto, eu usei o meio da estratégia unificada noite 0:00 falhou, os primeiros esses dados porque o nosso sistema é extrair durante a noite por ETL, sincronização uma vez por dia, e a segunda é que não temos medo de cache de avalanche, não tanto o tráfego à noite, mas não há acesso à quantidade.
04
dados Hotspot são os dados de forma clara
Há uma classe de dados, é claro que os dados quentes;
Temos uma interface, embora os dados de negócios, a quantidade de dados, mas apenas alguns milhares, mas chamadas por dia cerca de 400.000, e a freqüência de atualização não é muito alta, tais dados Redis colocar nele, mas logo em seguida, ; quanto ao que política de cache, mas também de outros sistemas porque a sincronização de dados mais, de acordo com a sincronização de dados do tempo, que finalmente aprovou um tempo de expiração de uma hora.
05
Avaliação dos dados restantes
Na verdade, os dois primeiros dados pode facilmente avaliá-lo, é a chave para avaliar esses dados:
- Temos um volume de chamadas diárias interface 200.000 para 300.000, não a quantidade, mas consultas mais complexas e lógica de processamento;
- A base da quantidade de dados é muito grande para colocar todos os dados em um Redis em;
- Não directamente os dados subjacentes no Redis porque existem múltiplas dimensões da consulta (condição);
- Não foi possível determinar a freqüência de cada chamada de dados é como a maioria resultado pessimista, cada dado chamar apenas uma vez naquele dia, por isso não há necessidade do cache.
Mas não podemos dizer uma trasfega nossos cérebros: "o volume de chamadas ficando maior, diretamente no Redis nele", ou "má avaliação, esquecê-lo, não colocar o cache", e tomar uma decisão ainda precisa de ter qualquer base , então eu fazer isso:
Passo 1.
Todas as interfaces para registrar todo o dia para descobrir
Dezenas certamente não um arquivo de log uma vez, ou para escrever seus próprios programas para escolher os dados necessários, mas considerando este trabalho só pode ser feito uma vez, eu ainda tentar salvar algum tempo.
EditPlus ainda usar essa ferramenta [Find in Files] função na consulta resultados caixa [] copiar todo o conteúdo, que levou dois minutos para colocar 240 000 log para descobrir.
o A interface de dados de consulta 240 000
Passo 2.
Para importar dados para um banco de dados para análise posterior
Cada log algo como isto:
XXXX.log"(64190,95):2020-3-17 16:44:10.092 http-nio-8080-exec-5 INFO 包名.类名 : 请求参数:args1={"字段1":"XXX","字段2":"YYY"}
Log que eu só precisa de três elementos: solicitar pacotes de Campo 1 e Campo 2, e tempo de chamada; como escolher para fora? Escreva um programa? Claro, não há problema, mas eu sou preguiçoso assim, alguns minutos podem fazer coisas Porque dezenas gastos de minutos, então? E este é um trabalho de uma só vez, então:
- Alternativamente elementos: [2020/03/17] substituir [/ t2020-3-17], isto é, para adicionar um selo de tempo na frente da aba;
- Alternativamente elementos: [{ "Campo 1": "] substituir [/ t];
- Alternativamente elementos: [ "" Campo 2 ":"] substituir [/ t];
- Alternativamente elementos: [ "}] Alternativamente para [], é substituído com um nulo;
- Selecione copiar, colar para excel em, excel na aba automaticamente coluna de troca;
- Excluir colunas desnecessárias, deixando apenas o conteúdo do campo campos 1 e 2, e um carimbo de tempo;
Não é preciso alguns passos de um minuto.
o dividir em cada três campos do log
Etapa 3.
análise de frequência de chamadas
Ao inserir dados em um banco de dados para análise, de acordo com nossas necessidades, nós principalmente querem saber que os participantes não vai repetir a mesma chamada? Cada intervalo de tempo de chamada? A SQL get:
select 字段1 , 字段2, count(1) 调用次数, (MIDNIGHT_SECONDS(max(UPDATETIME)) - MIDNIGHT_SECONDS(min(UPDATETIME)))/60 调用间隔时间，处理成了分钟from TABLEgroup by 字段1 , 字段2having count(1) > 2with ur ;
Claro, estatísticas de chamadas de intervalo, onde imprecisões estatísticas, especificamente eu não explicar, você química fina ...
Nele suma, o montante de 240.000 chamadas por dia, dos quais 100 000 chamadas uma vez, 140.000 dados serão chamados repetidamente em um curto espaço de tempo, há ainda alguns dados será repetido dezenas de vezes na consulta dentro de alguns minutos, então esta interface Redis é mais adequado para colocar em.
Passo 4.
Como os dados são armazenados?
Deixe-me dizer que nós salvar o formato de dados para os Redis, uma imagem vale mais que mil palavras:
o salvar o resultado de processamento para os Redis
Como para a atualização de cache política Bem, nós ainda usamos para definir o tempo de expiração, de acordo com as estatísticas em tempo sincronização de dados e de chamadas, este conjunto de tempo de 15 minutos mais apropriadas.
Pode ser visto neste processo de avaliação, todas as minhas operações têm mantido uma "lata preguiçoso preguiçoso" os hábitos bons e manter-se produtivo, fazer bom uso de ferramentas, economizando tempo desnecessário, todo o processo levou duas horas, a maior parte do tempo na importação de dados, com quase meia hora, mas, felizmente, neste processo, eu posso fazer outro trabalho.
Fonte: Webmaster Notícias