Spring Cloud (17): Design de alta simultaneidade

• espinho

  • Análise preliminar do negócio seckill
  • O desafio do sistema seckill
  • Projeto do sistema de pico
  • Arquitetura geral de segurança
    • acesso à página
    • Arquitetura de sistema de segurança comum
    • O projeto e implementação do sistema seckill no shopping
    • Isolamento de pico
    • isolamento empresarial
    • isolamento do sistema
    • isolamento de dados

• implantação real

  • OpenRestyName
  • Aquisição de produtos
  • Aquisição de Inventário
    • Lua acessa a biblioteca de escravos do Redis — IPC de comunicação entre processos do Linux (pipeline, canal anônimo, memória compartilhada, semáforo, fila de mensagens, soquete compartilhado do UNIX)
  • Controle de fluxo
    • Controle de tráfego na fase inicial de seckill
      • Projeto do sistema de agendamento
      • Otimização do sistema de reservas
        • Estratégia principal da plataforma de e-commerce
    • Controle de tráfego em caso de seckill
  • Recorte
  • limitando
    • Limitação de corrente do Nginx
    • Limitação de corrente da camada de aplicativo/serviço
    • Controle de fluxo do gateway
    • negação de serviço
  • Inventário e downgrade de compras limitadas e vendas instantâneas, pontos de acesso
    • limite de compra
    • dedução de estoque
      • Esquema de banco de dados ---- baixo desempenho
      • Esquema de bloqueio distribuído
    • Dedução de alta simultaneidade - downgrade
      • Gravar downgrade do serviço----Problema de inconsistência de dados----Deduzir inventário no Redis
      • ler rebaixamento do serviço
      • Simplifique a funcionalidade do sistema
    • dados quentes
      • ler pontos de acesso
      • escreva quente
    • Prevenção de escovas, controle de riscos e recuperação de desastres
      • anti escova
      • controle do vento
      • recuperação de desastres

• Práticas de leitura e escrita altamente concorrentes para grandes sites

  • Cenários de leitura e gravação simultâneos altos
    • Concentre-se no sistema de "alta leitura simultânea"
    • Concentre-se no sistema de "alta escrita simultânea"
    • Um sistema com "alta leitura simultânea" e "alta escrita simultânea" ao mesmo tempo
  • Estratégia de leitura e gravação de alta simultaneidade
    • Alta leitura simultânea
      • adicionar cache/cópia de leitura
      • leitura simultânea
      • reescrever leitura leve
      • Separação de leitura e gravação (arquitetura CQRS)
    • Alta gravação simultânea
      • fragmentação de dados
      • assíncrono
      • gravação em lote
  • Explicação detalhada do RockDB
    • RocksDB VS Redis
    • Como o LSM-Tree equilibra o desempenho de leitura e gravação

• Pergunta 1: Por que você precisa matar o sistema? promoção, chupa

• Pergunta 2: Qual é o status das principais plataformas de comércio eletrônico, como JD.com e Alibaba, na construção do sistema seckill? Explosivos, mercadorias em geral

• Pergunta 3: O que o sistema seckill significa para nós? Por que aprender o sistema seckill? Alta disponibilidade, alto desempenho, alta simultaneidade

espinho

Análise preliminar do negócio seckill

O desafio do sistema seckill

• enorme tráfego instantâneo
• problema de dados quentes
• Tráfego de pincel (ferramenta de captura de pacotes)

Projeto do sistema de pico

O caminho do link percorrido pela solicitação HTTP

O que fazer toda vez que o usuário interagir com o sistema durante um processo de compra de pânico

1. Dados da atividade Seckill: informações do produto que participaram da atividade Seckill, usadas principalmente para exibição de página da contagem regressiva, início e fim do evento e verificação de entrada instantânea na página de detalhes da empresa
2. Fornecer página de checkout: pode ser incorporado em várias plataformas (Android, PC, iOS), por isso é necessário fornecer um conjunto completo de serviços, incluindo páginas H5, que são usadas principalmente para exibir as informações de compra urgente de commodities, incluindo nomes de commodities , preços, quantidades de compras urgentes, endereços e formas de pagamento, ativos virtuais, etc.
3. Forneça os dados necessários para a renderização da página de liquidação: dados como endereços e ativos virtuais na dimensão do usuário, dados como nomes e preços na dimensão da atividade
4. Forneça a colocação do pedido: o usuário coloca um pedido na página de liquidação, fornece geração de pedidos ou transmite de forma transparente os dados do pedido para o downstream

Camada DNS: sites grandes tomarão algumas medidas anti-ataque relacionadas à rede, e o departamento de segurança de rede tem algumas medidas de configuração unificadas

Camada Nginx: proxy reverso e balanceador de carga, servidor web de alto tráfego, servidor de recursos estáticos, se a verificação de negócios também for colocada aqui, a pré-verificação pode ser realizada

Web Services: Agregação de Negócios

Serviço RPC: serviço básico

Spike arquitetura geral

acesso à página

• No caso de alta simultaneidade de seckill, a página de detalhes de negócios implementada dessa maneira colocará muita pressão de acesso nos serviços de back-end, especialmente serviços de produtos e bancos de dados, mesmo que todas as informações do produto sejam armazenadas em cache, ainda consumirá muito de recursos. Recursos de back-end e largura de banda
• db não tem cache, db é pediátrico
• A simultaneidade oficial de máquina única do redis é 10+ e a produção é basicamente de 70.000 a 80.000 simultaneidade após a dedução do tamanho (também é difícil lidar com tráfego grande instantâneo)
• O desempenho do contêiner Tomcat Java Web também não é bom. Uma solicitação por thread e uma memória 4G provavelmente pode iniciar solicitações (4.000-5.000)

Arquitetura de sistema de segurança comum

• CDN assume recursos estáticos fornecidos por serviços web ou serviços Nginx
  • O CDN é um servidor disponível em todo o país. Os clientes podem obter recursos estáticos automaticamente do CDN mais próximo de acordo com sua localização, o que é mais rápido
• As responsabilidades do Nginx são ampliadas. Ele é usado como um gateway web na frente, responsável por parte da verificação da lógica de negócios, podendo adicionar listas brancas e negras, limitação de corrente e funções de controle de fluxo. Escrever negócios no Nginx:
  • JD.com é um portal de negócios para detalhes de negócios e vendas instantâneas
  • Meituan é usado como camada de acesso de balanceamento de carga
  • 12306 é usado para consulta de tickets
• Faça pleno uso dos recursos de alta simultaneidade e alta taxa de transferência do Nginx
• A característica do negócio seckill é que o tráfego de entrada é grande. No entanto, a composição do tráfego é muito heterogênea. Entre essas solicitações
  • pedido de pincel
  • Solicitação inválida (passagem de parâmetro e outras exceções)
  • Solicitação normal, em circunstâncias normais, essa proporção pode ser de 6:1:3

Distribua 30% das solicitações realmente efetivas para o downstream e intercepte os 70% restantes na camada de gateway. Caso contrário, todo o tráfego será enviado para a camada de serviço da web e o serviço da web iniciará um novo encadeamento para processar pincéis e solicitações inválidas, o que é um desperdício de recursos

O projeto e implementação do sistema seckill no shopping

1. Criar um evento: O operador cria um evento no plano de fundo da operação do sistema seckill de acordo com o produto especificado e especifica a hora de início, hora de término, inventário de eventos, etc. do evento.
2. Iniciar o evento: antes do início do evento, o plano de fundo da operação do sistema seckill iniciará o seckill e gravará simultaneamente as informações da atividade seckill da página inicial no cluster Redis Cluster do sistema de shopping e gravará informações como inventário do produto seckill no mestre Redis. cluster escravo do sistema seckill.
3. Iniciar encaixe: o usuário entra na página de detalhes da venda em flash para se preparar para a venda em flash.
4. Elegibilidade do filtro: você pode ver o botão para comprar imediatamente na página de detalhes da empresa. Aqui podemos limitar se o botão pode ser clicado adicionando alguns julgamentos lógicos, como se o limite de nível de usuário para compra está definido, se ainda está ativo inventário, se um compromisso está marcado, etc. Se não houver restrições, o usuário pode clicar no botão de compra instantânea para entrar na página de liquidação secundária.
5. Página de confirmação do pedido: Na página de liquidação, os usuários podem alterar a quantidade de compra, mudar de endereço, métodos de pagamento, etc. Os elementos de liquidação aqui também precisam ser determinados de acordo com o negócio real. Cenários mais complexos também podem suportar pontos, cupons, vermelho envelopes, prazo de entrega, etc., e estes afetarão o cálculo do preço final.
6. Página de pagamento: Após a confirmação correta, o usuário envia o pedido. Aqui, o serviço de back-end pode chamar interfaces como controle de risco e limite de compra para melhorar a verificação. Depois de tudo aprovado, a dedução do estoque e a geração do pedido são concluídas.
7. Página de retorno de pagamento: Após a conclusão do pedido, pule para a página correspondente de acordo com o método de pagamento selecionado pelo usuário, por exemplo, pule para a caixa registradora para pagamento on-line ou pule para a página de solicitação de sucesso do pedido para pagamento na entrega.

Isolamento de pico

• Estratégia de isolamento Seckill: isolamento geral do sistema de commodities e commodities seckill
• Isolamento Seckill: isolamento de negócios, isolamento de sistema, isolamento de dados,

isolamento empresarial

• Relate o evento no sistema de relatórios, fornecendo informações básicas como número do produto participante do seckill, horário de início e término do evento, estoque, regras de restrição de compras, regras de controle de risco e distribuição geográfica dos grupos participantes, número estimado de pessoas, nível de filiação, etc.
• O departamento técnico pode estimar a vazão aproximada, número de concorrentes, etc., e combinar a capacidade atual suportada pelo sistema para avaliar se ele precisa ser expandido, se precisa ser rebaixado ou ajustar a estratégia de limitação atual, etc.

isolamento do sistema

• O seckill do usuário deve primeiro entrar na página de detalhes do produto (muitos sistemas de seckill de comércio eletrônico também aguardarão uma contagem regressiva na página de detalhes do negócio e clicarão no botão seckill para ativar quando o tempo acabar). Portanto, o primeiro sistema que precisa de atenção é a página de detalhes do produto. Precisamos solicitar um nome de domínio de página de detalhes de segurança independente, um balanceador de carga Nginx independente e um serviço de back-end de página de detalhes independente.
• Para isolar o nome de domínio, você pode solicitar um nome de domínio independente, que é usado especialmente para realizar o pico de tráfego. Depois que o tráfego chega do nome de domínio dedicado, ele é distribuído para um balanceador de carga dedicado e, em seguida, roteado para um grupo de microsserviços dedicados. Isso atinge o isolamento do tráfego do aplicativo de entrada para microsserviços no nível de serviço
• O sistema principal com um impacto de tráfego relativamente grande no seckill é a página de detalhes do seckill, a página de liquidação do seckill e a dedução do estoque do pedido do seckill são os objetos aos quais precisamos prestar atenção. Comparado com alguns sistemas no final do link, após o corte de pico anterior, o tráfego é relativamente baixo.Controlável, como caixas registradoras, sistemas de pagamento, isolamento físico é de pouca importância, mas aumentará os custos.

isolamento de dados

• Para o cache Redis, um mestre e um escravo são suficientes em cenários gerais, mas no cenário de pico, um mestre e vários escravos são necessários para ler os dados quentes

implantação real

OpenRestyName

Uso detalhado: https://blog.csdn.net/menxu_work/article/details/128400402

Aquisição de produtos

OpenResty lua página estática

Aquisição de Inventário

OpenResty segundo Redis

chegar

Lua acessa a biblioteca de escravos do Redis — IPC de comunicação entre processos do Linux (pipeline, canal anônimo, memória compartilhada, semáforo, fila de mensagens, soquete compartilhado do UNIX)

O Nginx precisa acessar o Redis pela rede, esse acesso à rede pode ser evitado?

Como construiremos um cluster mestre-escravo Redis em seckill, deixe a biblioteca de escravos Redis e o Nginx serem implantados no mesmo servidor

Quando o Nginx acessa o Redis, no máximo a camada IP da pilha de protocolos de rede do sistema operacional pode completar o acesso aos dados, evitando a transmissão real de pacotes de dados na rede.

TCP/IP层次模型：物理层,链路层、网络层、传输层、应用层

Na verdade, o JD.com usou esse design internamente. Há uma introdução relacionada em "A tecnologia central da arquitetura de sites com centenas de milhões de fluxos por Zhang Kaitao", nas páginas 351 e 385

Controle de fluxo

Controle de tráfego na fase inicial de seckill

Projeto do sistema de agendamento

Papel

• Histórico de gerenciamento de compromissos, atividades de configuração e encerramento
• O sistema de reservas envia mensagens de texto ou lembretes de mensagens aos usuários que fizeram reservas
• Microsserviços centrais de reserva orientados para terminal, fornecendo aos usuários a capacidade de fazer reservas e cancelá-las;

base de dados

• Reserve um evento
• nomeação do usuário

Otimização do sistema de reservas

• dimensão do tempo
• Número de reservas

Sistema de nomeação - tem as características de um certo grau de sistema de pico, fusão instantânea para controlar o número de pessoas

Estratégia principal da plataforma de e-commerce

• Banco de dados sub-banco de dados e sub-tabela, principalmente tabela de relacionamento de reserva de usuário
• A reserva de dados históricos também requer uma tarefa agendada para transferência e arquivamento para reduzir a pressão no banco de dados

Formulário de informações do evento de reserva

• Ele é armazenado no cache Redis. Se o cache Redis não puder mantê-lo, você pode usar o Redis para carregá-lo de um mestre para vários escravos ou pode usar o cache local do serviço.

Tabela de relacionamento de reserva de usuário

• Siga o usuário, não há problema de leitura de pontos de acesso, desde que o usuário faça login ou carregue a relação de reserva do usuário no cache do Redis no momento apropriado, leia do Redis ao fazer uma reserva para exibição do produto e informe ao usuário se a reserva foi feita

O que acontece quando um usuário marca uma consulta?

• O middleware de mensagens é escrito de forma assíncrona para evitar mensagens pesadas e perdidas e, ao mesmo tempo, o front-end lembra aos usuários que "o compromisso está na fila"

A página de detalhes da loja exibe o número atual de reservas para os usuários criarem uma atmosfera de produtos quentes

• Naturalmente, pensei em registrar o número de reservas no Redis. Ao exibir o ambiente na página de detalhes da empresa, esse registro será obtido do Redis para solicitação e, quando o usuário clicar no botão "Reservar agora" para marcar uma consulta, essa chave será acumulada.

Geralmente, um único chip Redis pode transportar um OPS de 70.000 a 80.000. E quando o período de agendamento recebe centenas de milhares, ou mesmo centenas de milhares de agendamentos por segundo?

• Acumule no cache local e, em seguida, grave no Redis em lotes. Por exemplo, depois de acumular 1.000 pessoas, increva 1.000 no Redis de uma vez, o que reduz a pressão de gravação no Redis em 1.000 vezes

Controle de tráfego em caso de seckill

Recorte

1. corte de fluxo
2. Código de verificação e teste de demonstraçãoHappyCaptcha
3. Pedido de demonstração da fila de mensagens

limitando

1. Limitação de corrente Nginx

Módulo de limitação de corrente
- HttpLimitzone para limitar o número de conexões simultâneas de um cliente
- HttpLimitReqest algoritmo de balde com vazamento para limitar a frequência de conexão do usuário

http { 
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; 
    server {
        location /test-limit {
            default_type application/json;
            limit_req zone=one burst=2 nodelay;
            content_by_lua_block {
                ngx.say("Test limit")
            }
        }
    }
}

limit_req_zone é o nome do comando, que é uma palavra-chave e só pode ser usado no bloco http

• $binary_remote_addr É a variável de ligação interna do Nginx, como $remote_porto número da porta do cliente
• zone=one:10m zone é uma palavra-chave, um é um nome de regra personalizada, cuja regra pode ser especificada no código subseqüente; 10m refere-se à função de declarar quanta memória para suportar o limite atual, teoricamente falando, uma área de 1 MB pode contém cerca de 16.000 estados de sessão
• rate=1r/s rate é uma palavra-chave, que pode especificar o limite do limite atual. r/s significa o número de solicitações permitidas por segundo. Aqui, limitamos 1 solicitação por segundo.
• limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s; #同一ip不同请求地址，进入名为one的zone，限制速率为5请求/秒
• limit_req_zone $binary_remote_addr $uri zone=two:10m rate=1r/s; #同一ip同一请求地址，进入名为two的zone，限制速率为1请求/秒
• limit_req é o nome da instrução, que pode ser usada em http, servidor e blocos de localização. Esta instrução é usada principalmente para definir a zona de memória compartilhada e o tamanho máximo da solicitação de rajada
• zone=one Use a zona chamada one, que foi declarada anteriormente com limit_req_zone
• burst=2 burst é usado para especificar o número máximo de solicitações de burst, as solicitações que excederem esse número serão atrasadas
• nodelay set nodelay, quando o número de solicitações de rajada for maior que a rajada, essa parte da solicitação será descartada imediatamente e o cliente retornará um status 503 em circunstâncias normais
  

No cenário de seckill, a taxa e o burst geralmente são definidos como muito baixos e ambos podem ser definidos como 1, o que significa que um IP só pode ser acessado uma vez em 1 segundo.

Os usuários da empresa, ao participarem da atividade seckill do e-commerce top, o melhor é mudar para sua própria rede de telefonia móvel para evitar ser "morto por engano".

2. Limitação de corrente da camada de aplicativo/serviço

• limite do pool de threads
• Limite atual da API
  • O pacote de código aberto RateLimiter fornecido pelo Google grava uma anotação e implementação de limitação de corrente baseada em token bucket por conta própria e a usa no código da API de negócios.
  • Governança de tráfego sentinela, de várias dimensões, como roteamento de tráfego, controle de tráfego, modelagem de tráfego, degradação de fusíveis, proteção de sobrecarga adaptativa do sistema, proteção de tráfego de ponto de acesso, etc.
• Limite atual personalizado
  • O thread-safe ConcurrentLinkedQueue pré-armazena um lote de IDs de pedidos
  • Atualização cronometrada da tarefa ( int getCount = ORDER_COUNT_LIMIT_SECOND / (1000 / FETCH_PERIOD);2.000 pedidos por segundo, atualização de 100 milissegundos para obter 2.000/1.000/100 = 200 uma vez por vez)
  • A obtenção de um ID exclusivo atua como um limitador de corrente String orderIdStr = orderIdList.poll();e 2.000 pedidos são distribuídos uniformemente em 1 minuto
• Filtragem hierárquica
  • O Nginx encerra o Nginx antecipadamente, habilita lua_shared_dict stock_cache 1m; # 共享字典，也就是本地缓存，名称叫做：stock_cache，大小1mo usongx.shared.stock_cache get/set
  • front-end:秒杀商品已无库存，秒杀结束
  • Camada de serviço:商品已经售罄,请购买其它商品!

3. Controle de fluxo do gateway

• Solução 1: Com base no script redis+lua,
  o gateway de limitação de corrente fornece oficialmente uma fábrica de filtro RequestRateLimiter, com base no método de script redis+lua usando o algoritmo de token bucket para atingir a limitação de corrente
  

• Solução 2: Integrar a limitação de fluxo do Sentinel
  Use o recurso de controle de fluxo do gateway do Sentinel para implementar a proteção de tráfego na entrada do gateway ou limitar a frequência das chamadas de API.
  O princípio do Spring Cloud Gateway acessando o Sentinel para atingir a limitação atual:
  

  • dimensão da rota: a entrada de roteamento configurada no arquivo de configuração do Spring, o nome do recurso é o routeId correspondente
  • Gateway 自定义 API 维度：用户可以利用 Sentinel 提供的 API 来自定义一些 API 分组
    

• Cenário: Execute o controle de fluxo na interface de ordem seckill 注意：匀速排队模式暂时不支持 QPS > 1000 的场景
• Cenário: limitação atual dos parâmetros do ponto de acesso na interface de detalhes do produto热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。注意：热点规则需要使用@SentinelResource("resourceName")注解，否则不生效; 参数必须是7种基本数据类型才会生效
  
• Tecla de atalho de detecção de ponto de acesso

4. Negação de serviço

Limite atual da regra do sistema sentinela

• Auto-adaptação de carga (válido apenas para máquinas do tipo Linux/Unix): o load1 do sistema é usado como um indicador heurístico para proteção auto-adaptativa do sistema. Quando o load1 do sistema exceder o valor heurístico definido e o número atual de threads simultâneos do sistema exceder a capacidade estimada do sistema, a proteção do sistema (fase BBR) será acionada. A capacidade do sistema é estimada por maxQps * minRt do sistema. O valor de referência de configuração é geralmente núcleos de CPU * 2,5.
• Uso da CPU (versão 1.5.0+): Quando o uso da CPU do sistema exceder o limite, a proteção do sistema será acionada (intervalo de valores 0,0-1,0), que é mais sensível.
• RT médio: quando o RT médio de todo o tráfego de entrada em uma única máquina atinge o limite, a proteção do sistema é acionada e a unidade é milissegundos.
• Número de threads simultâneos: quando o número de threads simultâneos de todo o tráfego de entrada em uma única máquina atinge o limite, a proteção do sistema é acionada.
• QPS de entrada: quando o QPS de todo o tráfego de entrada em uma única máquina atinge o limite, a proteção do sistema é acionada.
  

Inventário e downgrade de compras limitadas e vendas instantâneas, pontos de acesso

limite de compra

• Restrições de dimensão de commodities: diferentes regiões
• Restrição de dimensão pessoal: não se refere apenas ao mesmo ID de usuário, mas também restringe do mesmo número de celular, o mesmo endereço de entrega, o mesmo IP do dispositivo e outras dimensões. Por exemplo, o mesmo número de celular pode fazer apenas 1 pedido por dia, cada pedido pode comprar apenas 1 item e apenas 2 itens podem ser comprados em um mês, etc.

dedução de estoque

Obtenha a atomicidade e a ordem da dedução de estoque. Como alcançá-lo?

1. Solução de banco de dados - baixo desempenho

• mecanismo de bloqueio de linha
  • Bloqueio pessimista: a consulta e o desconto são colocados em uma transação, use para atualização ao consultar o estoque e o bloqueio de linha é liberado no final da transação
  • Por meio de instruções SQL: como as condições da instrução where, para garantir que o estoque não seja reduzido abaixo de 0
• bloqueio otimista
  • número da versão da versãoupdate set stock = stock - ? ,version = version +1 where id = ? and version = ?
• recursos do banco de dados
  • Defina diretamente os dados do campo do banco de dados como um inteiro sem sinal, de modo que, quando o valor do campo de inventário após a subtração for menor que zero, a instrução SQL seja executada diretamente para relatar um erro.

2. Esquema de bloqueio distribuído

• Redis
• Funcionário do zoológico

Desvantagens:

• Problemas de validade
• atraso de rede de bloqueio vermelho NPC, pausa, ponteiro das horas

高并发的扣减----降级

O downgrade é geralmente com perdas, então sacrifícios devem ser feitos. Vários downgrades comuns:

• Degradação do serviço de gravação: sacrifique a consistência dos dados para obter maior desempenho;
• Degradação do serviço de leitura: downgrade de emergência e perda de parada rápida em cenários de falha

1. Grave o downgrade do serviço ---- problema de inconsistência de dados ---- deduza o inventário no Redis

• No cenário de várias fontes de dados (MySQL e Redis), problemas de consistência de dados: a menos que sejam introduzidas transações distribuídas
• Aqueles com baixo tráfego primeiro caem no banco de dados MySQL e, em seguida, atualizam os dados no cache Redis monitorando as alterações do Binlog do banco de dados. Por meio do armazenamento em cache, podemos realizar operações de leitura de tráfego mais alto, mas as operações de gravação ainda estão sujeitas ao IOPS de disco do banco de dados. Geralmente, um banco de dados pode suportar operações de gravação de 3.000 a 5.000 TPS
• O aumento no tráfego requer o downgrade dos caminhos de gravação acima, de gravação síncrona no banco de dados para gravação síncrona no cache Redis e gravação assíncrona MQ no banco de dados, usando o poderoso OPS do Redis para transportar o tráfego. Geralmente, um único fragmento Redis pode atingir 80.000 para 100.000 OPS , o OPS do cluster Redis é maior

O uso do próprio Redis é de thread único, para resolver sobrevenda, consultas e deduções precisam ser operações atômicas

PO: A referência do script Lua é a seguinte, apresentada na forma de uma linha de comentário e uma linha de código:

 -- -------------------Lua脚本代码开始***************************
 -- 调用Redis的get指令，查询活动库存，其中KEYS[1]为传入的参数1，即库存key
 local c_s = redis.call('get', KEYS[1])
 -- 判断活动库存是否充足，其中KEYS[2]为传入的参数2，即当前抢购数量
 if not c_s or tonumber(c_s) < tonumber(KEYS[2]) then
    return 0
 end
 -- 如果活动库存充足，则进行扣减操作。其中KEYS[2]为传入的参数2，即当前抢购数量
 redis.call('decrby',KEYS[1], KEYS[2])
 -- -------------------Lua脚本代码结束***********************

Redis 也挂了怎么处理

 * 秒杀订单下单，采用Redis缓存中直接扣减库存，
 * MQ异步保存到DB下单模式，应对高并发进行削峰，
 * 如果发送消息到MQ也成为性能瓶颈，可以引入线程池，将消息改为异步发送
 * 但存在着Redis宕机和本服务同时宕机的可能，会造成数据的丢失，
 * 需要快速持久化扣减记录，采用WAL机制实现，保存到本地RockDB数据库

2. Leia o downgrade do serviço

Ao projetar um sistema de alta disponibilidade, lembre-se de que os serviços externos de middleware ou outros serviços RPC dos quais o próprio microsserviço depende podem falhar a qualquer momento, portanto, precisamos criar um cache multinível para que ele possa ser rebaixado e interrompido no momento em que ocorre uma falha

Supondo que quando o cache Redis de seckill falhar, podemos fazer downgrade rapidamente da solicitação de leitura para o cache Redis, MongoDB ou ES por meio da opção de downgrade. Ou quando o Redis e o cache de backup falham ao mesmo tempo (na realidade, raramente ocorrem falhas simultâneas), ainda podemos alternar o tráfego para o banco de dados por meio do switch de downgrade, para que o banco de dados fique temporariamente sob pressão para concluir o serviço de solicitação de leitura .

3. Simplifique as funções do sistema

Simplificar as funções do sistema significa eliminar processos desnecessários e abandonar funções não essenciais

O sistema seckill requer o mais simples possível, quanto menos interação, menores os dados, mais curto o link, mais próximo do usuário, mais rápida a resposta, então funções não essenciais podem ser rebaixadas no cenário seckill

dados quentes

Dentro de uma unidade de tempo (1s), se um dado for acessado com muita frequência, ele pode ser chamado de dados quentes, caso contrário, pode ser classificado como dados gerais ou dados frios. Então, quão alta uma frequência por unidade de tempo pode ser chamada de dados quentes? Na verdade, não há uma definição clara e pode ser determinada de acordo com a taxa de transferência do seu próprio sistema.

Quando um produto popular está na venda flash, apenas esse SKU é o ponto de acesso, portanto, não importa como você divida o banco de dados e a tabela ou aumente o número de estilhaços no cluster Redis, a capacidade do estilhaço onde o SKU do produto quente cai não é realmente aprimorado e sempre tocará Quando o limite superior for atingido, o Redis será desligado, o que pode levar à quebra do cache e à avalanche do sistema. Então, como devemos resolver esse problema espinhoso?

ler pontos de acesso

1. Aumente o número de cópias de dados quentes; aumente o número de cópias de escravos Redis
2. Quanto mais próximos os dados do ponto de acesso estiverem do usuário, melhor, mova os dados do ponto de acesso para cima e faça um cache local dos dados do ponto de acesso dentro do serviço
3. Retorno direto de curto-circuito. Quando um produto é vendido em segundos, este SKU não suporta o uso de cupons. Então, quando o sistema de cupons está processando, ele pode retornar diretamente uma lista de cupons vazia de acordo com o código SKU do produto.

escreva quente

Execute uma operação acumulativa na tecla Redis de "número de reserva". Quando milhões de pessoas marcam uma consulta ao mesmo tempo, esta tecla é uma operação de gravação a quente

1. Acumule primeiro na memória da JVM, atrase o envio para o Redis, para que o OPS do Redis possa ser reduzido dezenas de vezes
2. Existe uma maneira de pensar sobre a dedução de estoque, que pode evitar problemas importantes ao desmontar uma tecla de atalho em várias chaves. Esse design é aplicável aos caches MySQL e Redis, mas envolve a subdivisão do inventário e a movimentação de subinventários, o que é muito complicado, e há muitos problemas de limite, que são propensos a problemas de inventário imprecisos, portanto, precisa ser usado com cuidado com este método
3. O inventário de um único SKU é deduzido diretamente no fragmento único do Redis. Na verdade, o inventário de dedução está no final do link seckill. Por meio de nossos métodos anteriores de redução de pico e limitação de fluxo, o fluxo real para o inventário é limitado O Monolithic Redis OPS pode pagar. Em seguida, podemos limitar individualmente a dedução de estoque de um único SKU para garantir a pressão de um único Redis em estoque. Com essa abordagem em duas frentes, a pressão de dedução do inventário Redis para um único SKU é controlável

Prevenção de escovas, controle de riscos e recuperação de desastres

anti escova

1. Com a ajuda de ferramentas físicas, como "dedos dourados" para ajudar a clicar no botão de encaixe do telefone
2. Use software de terceiros para ajudar a acionar o botão de encaixe no aplicativo a tempo
3. Pegando e analisando as interfaces relevantes de encaixe e, em seguida, simulando o processo de encaixe por conta própria por meio do programa

Funcionalidade rápida: Somente pela verificação multidimensional do controle de risco pode ser identificado, a menos que pule
etapas

• O Nginx tem um limite de corrente condicional, que é um método muito simples e direto. Esse método pode efetivamente resolver as solicitações de alta frequência do tráfego preto em uma única interface, mas para evitar que o pincel faça cobranças diretamente sem passar pelo pré-processo, é necessário introduzir um mecanismo de token para orquestração de processos
• Mecanismo de token: A geração e verificação de token são realizadas na camada Nginx, de modo que nenhuma invasão nos dados principais do processo de negócios possa ser alcançada.
  Por exemplo, o token de processo pode ser adicionado ao cabeçalho retornado por meio de header_filter_by_lua_block. O token pode fazer MD5, adicionar número de produto, hora de início do evento, chave de criptografia personalizada, etc.
• Mecanismo de lista negra: lista negra local e lista negra de cluster; existem duas fontes: uma é importada de fora, que pode ser controle de risco ou outros canais; e a outra é a autossuficiência, que é gerada e usada automaticamente.

controle do vento

O processo de melhorar continuamente os retratos do usuário e os retratos do usuário são a base para estabelecer o controle de risco

Os elementos básicos de um perfil de usuário incluem número de celular, número do dispositivo, identidade, IP, endereço, etc. Algumas informações estendidas também incluem registros de crédito, registros de compras, registros de desempenho, informações de trabalho, informações de previdência social, etc. A coleta desses dados não pode ser realizada apenas contando com uma única plataforma, por isso o estabelecimento do controle de risco requer múltiplas plataformas, serviços abrangentes e cobertura profunda, pois só assim podemos obter o máximo de dados do usuário possível

O chamado controle de risco é, na verdade, direcionado a um determinado usuário, em diferentes cenários de negócios, para verificar se alguns dados do perfil do usuário tocaram a linha vermelha ou se determinados dados abrangentes tocaram a linha vermelha. E com um retrato completo do usuário, o julgamento no controle de risco de usuários ilegais será naturalmente mais preciso.

recuperação de desastres

• Morar duas vezes na mesma cidade
• Viva mais em lugares diferentes

Práticas de leitura e escrita altamente concorrentes para grandes sites

Cenários de leitura e gravação simultâneos altos

Concentre-se no sistema de "alta leitura simultânea"

• Magnitude
• Tempo de resposta
• frequência

Cenas:

1. mecanismo de busca
2. Pesquisa de produtos para e-commerce
3. Descrições, fotos e preços de produtos para sistemas de comércio eletrônico
   

Concentre-se no sistema de "alta escrita simultânea"

Os três modelos de monetização da Internet:

• jogo
• comércio eletrônico
• Publicidade (sistema de dedução de taxa de publicidade)

Os anúncios geralmente são pay-per-view ou pay-per-click (conhecidos na indústria como CPC ou CPM). Especificamente, os anunciantes abrem uma conta na plataforma de publicidade, cobram uma quantia em dinheiro e colocam seus próprios anúncios. Após os usuários C-end verem este anúncio, eles podem deduzir um yuan por clique (CPC); ou navegar neste anúncio e deduzir 10 yuans (CPM) por 1.000 visualizações. Aqui está apenas uma analogia, a operação real obviamente não é a esse preço.

Tal sistema de cobrança de publicidade (ou seja, sistema de dedução) é um sistema típico de "alta escrita simultânea"

1. Sempre que um usuário C-end navegar ou clicar, o saldo da conta do anunciante será deduzido uma vez.
2. Essa dedução deve ser o mais em tempo real possível. Se a dedução for lenta, não há dinheiro na conta do anunciante, mas o anúncio ainda é reproduzido online, o que causará a perda de tráfego da plataforma

Um sistema com "alta leitura simultânea" e "alta escrita simultânea" ao mesmo tempo

Cenas:

• Sistema de venda de bilhetes de trem do site 12306
• Sistema de inventário de comércio eletrônico e sistema seckill
• Sistema de pagamento e envelope vermelho WeChat
• IM, Weibo e Momentos

Estratégia de leitura e gravação de alta simultaneidade

Alta leitura simultânea

1. Adicionar cache/cópia de leitura

• Solução 1: Cache local ou cache centralizado
  Existem quatro padrões principais de design para atualizar o cache: Cache à parte, Ler, Gravar, Gravar atrás do cache:

  • Padrão Cache Aside: Atualize o banco de dados primeiro e, em seguida, exclua o cache, o back-end é um armazenamento único e o armazenamento mantém seu próprio Cache, Binlog
  • Read through: Quando o cache é invalidado (expirado ou LRU trocado)
  • Write Through: Ocorre ao atualizar os dados
  • Write Behind Caching: O Page Cache do sistema de arquivos Linux também é o mesmo algoritmo.

  Problema de cache: (Dachang é cache cheio)

  • Alta disponibilidade do cache: Se o cache estiver inativo, todas as solicitações serão gravadas e o banco de dados ficará sobrecarregado?
  • Penetração do cache: O cache não está inativo, mas há muitas consultas para determinadas chaves, e essas chaves não estão no cache, fazendo com que um grande número de solicitações sobrecarregue o banco de dados em um curto período de tempo.
  • Quebra de cache: Uma chave de ponto de acesso, que é acessada intensivamente por grande simultaneidade, quando a chave se torna inválida no momento, uma grande simultaneidade contínua romperá o cache e solicitará diretamente o banco de dados.
  • Um grande número de teclas de atalho expirou. Similar ao segundo problema, como algumas chaves são inválidas, um grande número de requisições são escritas em um curto período de tempo e sobrecarregam o banco de dados, ou seja, cache avalanche. Na verdade, o primeiro problema também pode ser considerado uma avalanche de cache.

• Solução 2: MySQL mestre/escravo

• Solução 3: CDN/aceleração de arquivo estático/separação dinâmica e estática

Nota: Embora o Slave e o CDN do Redis e do MySQL sejam completamente diferentes do ponto de vista técnico, todos eles estão na forma de "armazenar em cache/adicionar cópias" do ponto de vista estratégico. É tudo através da redundância de dados para alcançar o efeito de trocar espaço por tempo

2. Leitura simultânea

• Cenário 1: RPC assíncrono "T1, T2, T3"
• Cenário 2: Solicitação redundante "Solicitação de cobertura"

3. Reescrever leitura leve

• Solução 1: Realização da "combinação push-pull" do fluxo do Weibo Feeds
  

• Solução 2: consulta associada a várias tabelas: tabela ampla e mecanismo de pesquisa

4. Resumo: separação leitura-gravação (arquitetura CQRS)

Modelo típico de arquitetura de separação de leitura e gravação

• Projete estruturas de dados separadas para leitura e gravação
• O lado da escrita, geralmente o banco de dados de negócios online, resiste à pressão da escrita por meio de subbancos de dados e subtabelas. Para resistir à alta pressão de simultaneidade, o final da leitura pode ser um cache <K, V> para cenários de negócios, ou uma tabela ampla que foi juntada com antecedência, ou um mecanismo de pesquisa ES
• Concatenação de leitura e gravação. Tarefas cronometradas convertem regularmente os dados no banco de dados de negócios em uma estrutura de dados adequada para leitura de alta simultaneidade; ou a extremidade de gravação envia alterações de dados para o middleware da mensagem e, em seguida, a extremidade de leitura consome mensagens; ou monitora diretamente o Binlog no banco de dados de negócios , Ouça as alterações no banco de dados para atualizar os dados no lado de leitura
• As leituras têm latência em comparação com as gravações. Como os dados gravados à esquerda estão mudando em tempo real, os dados lidos à direita certamente serão atrasados. A consistência final entre leitura e gravação não é uma consistência forte, mas isso não afeta a operação normal do negócio

Alta gravação simultânea

Estratégia 1: fragmentação de dados

Estratégia 2: Assíncrona

• Caso 1: registro ou login do código de verificação por SMS
• Caso 2: Sistema de pedidos de comércio eletrônico
• Caso 3: sistema de cobrança de publicidade
• Caso 4: Gravar memória + log Write-Ahead

Estratégia 3: Escreva em lotes

• Caso 1: Dedução combinada do sistema de cobrança de publicidade
• Caso 2: Mecanismo de mesclagem de pequenas transações do MySQL

RockDBGenericName

Em termos de mecanismo de implementação de transação, o MySQL usa o mecanismo WAL (Write-ahead logging, pre-write log) para implementar, todas as modificações são primeiro gravadas no log e depois aplicadas ao sistema, geralmente incluindo Refazer e desfazer duas partes de Informação. É o conhecido Redo log, o nome do arquivo é geralmente ib_logfile0, 1, 2..., MySQL usa um mecanismo muito complicado para implementar o WAL, um formato de log separado, uma grande variedade de tipos de log, escrita em grupo, etc.

O RocksDB é um mecanismo de armazenamento KV persistente e de alto desempenho, de código aberto do Facebook. Foi originalmente desenvolvido pela equipe de engenheiros de banco de dados do Facebook com base no Google LevelDB. De um modo geral, raramente vemos qualquer projeto que use RocksDB diretamente para armazenar dados e, mesmo no futuro, provavelmente não será usado diretamente por sistemas de negócios como o Redis.

https://www.influxdata.com/blog/benchmarking-leveldb-vs-rocksdb-vs-hyperleveldb-vs-lmdb-performance-for-influxdb/

Grave 50 milhões de dados em lotes, o RocksDB levou apenas 1m26,9s

RocksDB VS Redis

	Desempenho oficial de leitura e gravação	Desempenho real de leitura e gravação	Método de operação
Redis	500.000 vezes/s	10W/S	Memória
RocksDBName	200.000 vezes/s	4W/S	disco

Por que o RocksDB pode atingir um desempenho de gravação tão alto?
A maioria dos sistemas de armazenamento usa estruturas de armazenamento, como árvores ou tabelas de hash, para obter pesquisas rápidas. Os dados devem ser gravados em um local específico quando são gravados. Por exemplo, quando escrevemos um dado na árvore B+, devemos escrevê-lo em um nó fixo de acordo com o método de classificação da árvore B+. A tabela de hash é semelhante e deve ser gravada em um slot de hash específico.

Essa estrutura de dados fará com que, ao gravar dados, você tenha que gravar uma parte aqui no disco e depois escrever uma parte ali, para poder pular e escrever, que é o que chamamos de "escrita aleatória".

O MySQL se esforçou muito para reduzir leituras e gravações aleatórias. A estrutura de dados do RocksDB pode garantir que a maioria das operações gravadas no disco sejam顺序写入

O Kafka também usa leitura e gravação sequencial, portanto, o desempenho de leitura e gravação também é muito bom. Tudo tem vantagens e desvantagens, esse tipo de dado basicamente não pode ser consultado porque os dados não tem estrutura e só podem ser percorridos.

Como o RocksDB pode levar em conta um bom desempenho de consulta sob a premissa de garantir que os dados sejam escritos em ordem
?LSM-Tree

Como o LSM-Tree equilibra o desempenho de leitura e gravação

O nome completo da LSM-Tree é The Log-Structured Merge-Tree, que é uma estrutura de dados composta muito complexa.
contém

• WAL (Write Ahead Log) – Mysql
• SkipList — Lista de pulos do Redis
• Uma tabela ordenada hierárquica (Tabela de strings classificadas, SSTable)

A árvore LSM é especialmente projetada para o sistema de armazenamento de valor-chave para melhorar o desempenho de gravação em detrimento do desempenho de leitura parcial.通常适合于写多读少的场景

diagrama de arquitetura

https://www.processon.com/view/link/637f182e5653bb3a8420f9af