Spike business
No campo do e-commerce, existem cenários de negócios típicos de pico, então, o que é um cenário de pico? Simplificando, o número de compradores de um produto é muito maior do que o estoque do produto, e o produto será vendido em um curto período de tempo. Por exemplo, cenários de negócios como a promoção anual 618, Double 11 big e a promoção de novos produtos da Xiaomi são cenários típicos de negócios de pico.
A maior característica do negócio de pico é o alto tráfego simultâneo instantâneo. No sistema de e-commerce, a quantidade de estoque é frequentemente muito menor do que o tráfego simultâneo. Por exemplo: a atividade de pico de Tmall pode ter apenas algumas centenas ou milhares de itens em estoque e o influxo deles instantaneamente As compras simultâneas podem atingir dezenas a milhões de tráfego.
Portanto, podemos resumir as características de negócios do sistema de spikes da seguinte maneira.
Amigos que precisam de mais conhecimento de Java e perguntas para entrevistas podem clicar no link abaixo para obtê-lo gratuitamente
Link: 1103806531 Senha: CSDN
(1) Tempo limitado, quantidade limitada, limite de preço
No tempo especificado; a quantidade de produtos na atividade de pico é limitada; o preço dos produtos será muito menor do que o preço original, ou seja, na atividade de pico, os produtos serão vendidos a um preço muito inferior ao preço original.
Por exemplo, o horário da atividade de pico é limitado às 10h00 às 10h30 de um determinado dia, a quantidade de mercadorias é de apenas 100.000 peças e o preço das mercadorias é muito baixo, como: compra de 1 yuan e outros cenários de negócios.
Limite de tempo, limite e preço podem existir sozinhos ou em combinação.
(2) Atividades de pré-aquecimento
O evento deve ser configurado com antecedência; antes do início do evento, os usuários podem visualizar as informações relacionadas ao evento; antes do início do evento de pico, o evento será promovido vigorosamente.
(3) Curta duração
O número de pessoas comprando é enorme; os produtos se esgotarão rapidamente.
Na apresentação do tráfego do sistema, haverá um fenômeno de pico repentino. Neste momento, o número de visitas simultâneas é muito alto. Na maioria dos cenários de pico, as mercadorias se esgotarão em um período muito curto.
Três pontas
Normalmente, do início ao fim do pico, geralmente existem três estágios:
- Estágio de preparação: este estágio também é chamado de estágio de aquecimento do sistema. Nesse momento, os dados de negócios do sistema de pico serão aquecidos com antecedência. Nesse momento, os usuários atualizarão constantemente a página de pico para verificar se a atividade de pico foi iniciada. Até certo ponto, alguns dados podem ser armazenados no Redis para pré-aquecimento por meio da operação de atualização contínua da página do usuário.
- Fase de pico: Esta fase é principalmente o processo de atividade de pico, que irá gerar tráfego simultâneo alto instantâneo, o que terá um grande impacto nos recursos do sistema, portanto, a proteção do sistema deve ser feita na fase de pico.
- Estágio de liquidação: processamento de dados após a conclusão do pico, como processamento de problemas de consistência de dados, processamento de situação anormal e processamento de devolução de mercadoria.
Redis ajuda o sistema de spike
Podemos projetar uma estrutura de dados Hash no Redis para dar suporte à dedução do estoque de commodities, conforme mostrado abaixo.
seckill:goodsStock:${
goodsId}{
totalCount:200,
initStatus:0,
seckillCount:0
}
Na estrutura de dados Hash que projetamos, existem três atributos principais.
- totalCount: indica o número total de produtos que participam do pico. Antes do início da atividade de pico, precisamos carregar esse valor no cache do Redis com antecedência.
- initStatus: projetamos esse valor como um valor booleano. Antes de o pico começar, este valor é 0, o que significa que o pico não começou. Você pode modificar esse valor para 1 por meio de tarefas cronometradas ou operações em segundo plano para indicar que o pico começa.
- seckillCount: Indica a quantidade de produtos que são seckados.Durante o processo de seckill, o limite superior deste valor é totalCount. Quando este valor atinge totalCount, significa que o seckill do produto foi concluído.
Podemos usar o seguinte snippet de código para armazenar em cache o carregamento de dados do produto que participará do pico na fase de pré-aquecimento do pico.
/**
* @author binghe
* @description 秒杀前构建商品缓存代码示例
*/
public class SeckillCacheBuilder{
private static final String GOODS_CACHE = "seckill:goodsStock:";
private String getCacheKey(String id) {
return GOODS_CACHE.concat(id);
}
public void prepare(String id, int totalCount) {
String key = getCacheKey(id);
Map<String, Integer> goods = new HashMap<>();
goods.put("totalCount", totalCount);
goods.put("initStatus", 0);
goods.put("seckillCount", 0);
redisTemplate.opsForHash().putAll(key, goods);
}
}
Quando o pico começa, precisamos primeiro determinar no código se o valor seckillCount no cache é menor que o valor totalCount. Se o valor seckillCount for realmente menor que o valor totalCount, podemos bloquear o inventário. Em nosso programa, essas duas etapas não são realmente atômicas. Se, em um ambiente distribuído, utilizarmos várias máquinas para operar o cache do Redis ao mesmo tempo, ocorrerão problemas de sincronização, o que acarretará sérias consequências de "sobrevenda".
No campo do e-commerce, existe um termo profissional denominado "oversold". Como o nome indica: "Oversold" significa que o número de produtos vendidos é maior do que o número de produtos em estoque, o que é um problema muito sério no campo do comércio eletrônico. Então, como podemos resolver o problema do "excesso de vendas"?
O script Lua resolve perfeitamente o problema de sobrevenda
Como resolvemos o problema de sincronização de várias máquinas operando o Redis ao mesmo tempo? Uma solução melhor é usar scripts Lua. Podemos usar scripts Lua para encapsular a operação de dedução de estoque no Redis em uma operação atômica, de modo que a atomicidade da operação possa ser garantida, resolvendo assim o problema de sincronização em um ambiente de alta concorrência.
Por exemplo, podemos escrever o seguinte código de script Lua para realizar a operação de dedução de estoque no Redis.
local resultFlag = "0"
local n = tonumber(ARGV[1])
local key = KEYS[1]
local goodsInfo = redis.call("HMGET",key,"totalCount","seckillCount")
local total = tonumber(goodsInfo[1])
local alloc = tonumber(goodsInfo[2])
if not total then
return resultFlag
end
if total >= alloc + n then
local ret = redis.call("HINCRBY",key,"seckillCount",n)
return tostring(ret)
end
return resultFlag
Podemos usar o seguinte código Java para chamar o script Lua acima.
public int secKill(String id, int number) {
String key = getCacheKey(id);
Object seckillCount = redisTemplate.execute(script, Arrays.asList(key), String.valueOf(number));
return Integer.valueOf(seckillCount.toString());
}
Dessa forma, quando executamos a atividade de pico, podemos garantir a atomicidade da operação, evitando assim efetivamente problemas de sincronização de dados e resolvendo efetivamente o problema de "sobrevenda".
Resumindo
Compilei vários pontos de conhecimento, módulos, documentos e perguntas de entrevistas mais reais de grandes empresas. Amigos necessitados podem clicar no link abaixo para obtê-los gratuitamente
Link: 1103806531 Senha: CSDN
