Resumo de transações distribuídas e bloqueios distribuídos

Transações distribuídas

O que é uma transação distribuída?

Introdução ao modelo de transação distribuída:

Transações distribuídas referem-se a operações de transação envolvendo vários participantes. Esses participantes podem estar localizados em diferentes nós físicos ou entre diferentes sistemas. É necessário garantir que as operações de todos os participantes sejam bem-sucedidas ou falhem para manter a consistência dos dados.

Participante da transação "Gerenciador de recursos (RM): sinônimo de participante da transação": por exemplo, cada banco de dados é um participante da transação.
Coordenador de Transações "Transaction Manager (TM): sinônimo de coordenador de transações": um programa de serviço que acessa múltiplas fontes de dados.
No modelo de transação distribuída, um TM gerencia vários RMs, ou seja, um programa de serviço acessa múltiplas fontes de dados; TM é um gerenciador de transações globais que coordena o progresso de transações locais multipartidárias para fazer eles se comprometem ou revertem juntos para finalmente alcançar uma característica ACID global.

Quais são os métodos de implementação de transações distribuídas?

Os métodos comuns de implementação de transações distribuídas incluem confirmação de duas fases (2PC), confirmação de três fases (3PC), modelo de transação TCC (Try-Confirm-Cancel), fila de mensagens, etc.

Qual é a diferença entre commit em duas fases e commit em três fases?

O envio em duas fases é um protocolo de bloqueio síncrono, que exige que os participantes operem sob a orientação do coordenador. Existem pontos únicos de falha e gargalos de desempenho; o envio em três fases é introduzido com base em duas fases submissão. O mecanismo de tempo limite reduz o tempo de bloqueio, mas ainda existem problemas de bloqueio e pontos únicos de falha.
Two-Phase Commit (2PC para abreviar) e Three-Phase Commit (3PC para abreviar) são usados em sistemas distribuídos para garantir dados entre vários participantes Protocolo consistente.

Submissão em duas etapas (2PC):

Fase de Preparação: O coordenador envia solicitações de preparação de transação a todos os participantes e aguarda as respostas dos participantes. Os participantes realizam operações de preparação de transações e enviam mensagens prontas ao coordenador.
Fase de commit: Se todos os participantes estiverem prontos, o coordenador envia uma solicitação de commit a todos os participantes, e os participantes realizam a operação de commit da transação e enviam uma mensagem de confirmação ao coordenador. Após receber todas as mensagens de confirmação, o coordenador decide se deseja confirmar a transação.

Submissão em três etapas (3PC):

Fase CanCommit (fase de preparação): O coordenador envia uma solicitação CanCommit a todos os participantes, e os participantes realizam operações preparatórias para transações locais e enviam mensagens prontas ao coordenador.
Fase PreCommit (fase pré-commit): o coordenador aguarda mensagens prontas de todos os participantes. Se todos os participantes estiverem prontos, o coordenador envia uma solicitação PreCommit a todos os participantes, e os participantes realizam a operação de pré-commit da transação e devolvem os resultados ao coordenador.
Fase DoCommit (fase de commit): Depois de receber feedback de todos os participantes, o coordenador decide se deseja confirmar a transação com base nos resultados do feedback. Se todos os participantes reportarem sucesso, o coordenador envia uma solicitação DoCommit e os participantes realizam a operação de commit da transação. Caso contrário, o coordenador envia uma solicitação DoAbort e o participante executa uma operação de rollback da transação.

O envio em três fases introduz uma fase de pré-comprometimento em comparação com o envio em duas fases, o que pode garantir melhor a consistência das transações no caso de anormalidades na rede ou falhas dos participantes. No entanto, o commit trifásico ainda sofre de problemas de bloqueio e não determinísticos em alguns casos especiais.
A escolha entre commit bifásico e trifásico depende das necessidades específicas e dos requisitos de desempenho do sistema. A confirmação em duas fases é simples e direta, mas pode fazer com que a transação não seja concluída sob certas condições de falha. A confirmação trifásica introduz fases adicionais, melhorando a tolerância a falhas, mas adicionando complexidade e latência. Faça concessões e escolhas com base nas circunstâncias reais.

2PC é um modelo simples para implementação de transações distribuídas. Os dois estágios são:

Fase de votação:
a. O coordenador (coordenador, ou seja, gerente de transações) iniciará uma solicitação CanCommit para executar a operação para o participante da transação (coorte, ou seja, gerente de recursos local), e aguarde a resposta do participante.
b. Após receber a solicitação, o participante realizará a operação de transação na solicitação, registrará as informações de log (incluindo a imagem antes da execução da transação) e bloqueará o registro atual. Se a execução for bem sucedida, o participante enviará uma mensagem “Sim” ao coordenador para indicar consentimento à operação; se não for bem sucedida, será enviada uma mensagem “Não” para indicar o encerramento da operação.
c. Quando todos os participantes retornam os resultados da operação (mensagens Sim ou Não), o sistema entra na fase de envio.
Fase de commit:
Se cada participante responder sim, o coordenador inicia uma operação de envio de transação para todos os participantes, e então todos os participantes executam transações locais após recebê-la. Envie a operação e envie um ACK para o coordenador; se algum participante responder não ou expirar, o coordenador inicia uma operação de reversão de transação para todos os participantes e, em seguida, todos os participantes realizam operações de reversão de transação local e reportam ao coordenador após receber Enviar ACK.
Desvantagens:
Ponto único de falha: se houver um problema com o coordenador, todo o processo de envio da segunda fase não funcionará. O que é mais sério é que o coordenador aparece em fase dois.Se houver um problema, outros participantes ficarão em um estado de bloqueio de recursos de transação e não poderão continuar a concluir a operação de transação.
Inconsistência de dados: Na segunda fase do envio em duas fases, ou seja, quando a transação é submetida, após o coordenador enviar uma solicitação de commit aos participantes, ocorre uma exceção na rede local ou durante o processo de envio da solicitação de confirmação O coordenador falha, o que faz com que apenas alguns participantes recebam solicitações de confirmação. Após esta parte dos participantes receber a solicitação de commit, eles realizarão a operação de commit. Porém, outras máquinas que não receberam a solicitação de commit não poderão realizar o envio da transação, resultando em inconsistência de dados.

Como o modelo de transação TCC resolve transações distribuídas?

O modelo de transação TCC adota três etapas: reserva de recursos, execução de confirmação e execução de cancelamento, e atinge a consistência das transações distribuídas por meio da divisão da lógica de negócios e gerenciamento de estado.

O modelo de transação TCC (Try-Confirm-Cancel) é um modelo para processamento de transações em um sistema distribuído.Ele alcança consistência de transação decompondo as operações de transação em três fases. Cada etapa do modelo de transação TCC e sua função são apresentadas detalhadamente a seguir:

Fase de teste:

Na fase try, os participantes da transação tentam reservar e bloquear recursos, realizar algumas verificações e preparações, mas na verdade não modificam os recursos.
Se as tentativas de operações de todos os participantes forem bem-sucedidas, significa que a reserva e o bloqueio dos recursos estão disponíveis e a fase de confirmação foi iniciada.
Se a tentativa de operação de algum participante falhar, indicando indisponibilidade de recursos ou outros problemas, a transação será revertida ou ações compensatórias correspondentes serão tomadas.
2. Etapa de confirmação:

Na fase de confirmação, os participantes da transação realizam operações reais de atualização de recursos e atualizam o status do recurso anteriormente reservado.
Se as operações de confirmação de todos os participantes forem bem-sucedidas, significa que a transação foi executada com sucesso e a transação pode ser enviada.
Se a operação de confirmação de algum participante falhar, significa que há um problema com a execução da transação e é necessária uma operação de reversão ou compensação correspondente.
3. Fase de cancelamento:

Na fase de cancelamento, os participantes da transação realizam as operações de cancelamento de reservas e bloqueios de recursos realizados anteriormente e restauram o status do recurso para o estado anterior à fase de tentativa.
Se as operações de cancelamento de todos os participantes forem bem-sucedidas, significa que a execução da transação falhou e uma operação de rollback pode ser executada.
Se a operação de cancelamento de algum participante falhar, outras medidas compensatórias ou intervenção manual poderão ser necessárias para reparar o estado do sistema.
O modelo de transação TCC atinge a consistência e a consistência das transações distribuídas dividindo as transações em três estágios: tentativa, confirmação e cancelamento, permitindo que lógicas de negócios relevantes e verificações de status sejam executadas em cada estágio.

As vantagens do modelo de transação TCC incluem:

Alta flexibilidade: A lógica e as operações de cada etapa podem ser definidas de acordo com as necessidades do negócio.
Lógica de compensação explícita: Ao cancelar a operação de compensação na fase, as operações realizadas anteriormente podem ser revertidas ou compensadas para garantir a consistência dos dados.
Tolerância a falhas e escalabilidade: as operações de compensação podem manter a consistência do sistema mesmo no caso de falha dos participantes ou da rede.
No entanto, o modelo de transação TCC também tem algumas limitações:

Complexidade de desenvolvimento: A implementação do modelo de transação TCC requer divisão e design cuidadosos da lógica de negócios e consideração da sequência de execução, tratamento de exceções, etc. de cada estágio.
Desempenho de simultaneidade: o modelo TCC pode ter competição de recursos em situações de alta simultaneidade

Qual é a diferença entre consistência forte e consistência eventual em transações distribuídas?

A consistência forte exige que todos os participantes de uma transação alcancem um estado consistente imediatamente após a conclusão da transação, enquanto a consistência eventual permite que exista inconsistência de dados dentro de um determinado período de tempo, mas eventualmente atingirá um estado consistente.

Como garantir a confiabilidade das transações distribuídas?

As transações distribuídas são, na verdade, processamento de transações em sistemas distribuídos. Para ser franco, a questão da confiabilidade é como garantir a confiabilidade em sistemas distribuídos.
Você pode usar filas de mensagens para garantir entrega e processamento confiáveis de mensagens de transação, usar bloqueios distribuídos para garantir acesso mutuamente exclusivo aos recursos e implementar mecanismos razoáveis de repetição e compensação para lidar com exceções em transações.

As transações distribuídas referem-se a operações de transação envolvendo vários nós ou participantes, que podem ser distribuídas em diferentes locais físicos ou ambientes de rede. Em sistemas distribuídos, garantir a confiabilidade das transações é uma questão fundamental porque a comunicação entre os nós pode sofrer atrasos, falhas ou inconsistências de dados. Aqui estão várias maneiras de garantir a confiabilidade das transações distribuídas:

Two-Phase Commit (2PC): 2PC é um protocolo clássico de transação distribuída que usa o nó coordenador para garantir que todos os nós participantes cheguem a um consenso antes que a transação seja confirmada. No 2PC, o nó coordenador envia solicitações de pré-comprometimento a todos os participantes e aguarda suas respostas. Se todos os participantes estiverem prontos para cometer, o nó coordenador envia uma solicitação de confirmação; caso contrário, uma solicitação de aborto é enviada. 2PC garante a atomicidade das transações distribuídas, mas pode causar bloqueio quando o nó coordenador falha.

Three-Phase Commit (3PC): 3PC é uma melhoria em 2PC e foi projetado para resolver o problema de bloqueio em 2PC. Ao contrário do 2PC, o 3PC introduz uma fase de pré-comprometimento onde o nó coordenador pergunta a todos os nós participantes se eles estão prontos para confirmar a transação. Se todos os participantes estiverem prontos, entre na fase de submissão; caso contrário, entre na fase de aborto. O 3PC reduz o problema de bloqueio quando o nó coordenador falha, introduzindo um mecanismo de tempo limite e estados intermediários adicionais.

Envio assíncrono baseado na fila de mensagens: Este método assíncroniza o processo de envio de transações distribuídas, colocando a solicitação de envio na fila de mensagens e processando-a por um processo ou serviço em segundo plano. Nesse modo, o nó participante envia os resultados da operação da transação para a fila de mensagens, e o processo em segundo plano é responsável por coletar e processar esses resultados para decidir se deve confirmar a transação. Esta abordagem reduz a dependência do nó coordenador e proporciona maior confiabilidade e escalabilidade.

Protocolo de consistência distribuída: O protocolo de consistência é um mecanismo usado para garantir a consistência de sistemas distribuídos, como Paxos, Raft, etc. Esses protocolos alcançam consenso através da realização de votações e eleições entre nós e garantem que todos os nós no sistema distribuído alcancem um estado consistente. O uso de um protocolo de consistência pode fornecer alta disponibilidade e tolerância a falhas, garantindo ao mesmo tempo confiabilidade.

Controle de simultaneidade otimista (OCC): OCC é um método de lidar com conflitos de transação em um ambiente distribuído. Assume que os conflitos entre transações ocorrem com menos frequência e permite a execução simultânea. OCC usa mecanismos de controle de versão e detecção de conflitos para garantir a consistência dos dados. Antes de uma transação ser confirmada, o OCC verificará se outras transações modificaram os mesmos dados durante a transação. Se houver um conflito, a transação atual será abortada e uma operação de reversão será executada.

Bloqueio distribuído: O bloqueio distribuído é um mecanismo para coordenar o acesso simultâneo em um sistema distribuído. Pode ser usado para proteger recursos compartilhados e evitar inconsistência de dados causada por acesso simultâneo. Os bloqueios distribuídos podem ser implementados com base em diversas tecnologias, como ZooKeeper, Redis, etc. Ao adquirir bloqueios distribuídos, as transações podem garantir que outras transações não acessem os mesmos recursos ao mesmo tempo durante a execução de operações críticas.

Replicação de dados e tolerância a falhas: Para melhorar a confiabilidade dos sistemas distribuídos, podem ser utilizados mecanismos de replicação de dados e tolerância a falhas. A replicação de dados pode armazenar dados em vários nós para que, quando um nó falhar, outros nós possam continuar a fornecer serviços. Tecnologias tolerantes a falhas, como backup redundante e recuperação de falhas, podem garantir que o sistema possa retomar automaticamente a operação normal em caso de falha de nó ou de rede.

Quais são as vantagens e desvantagens das transações distribuídas?

As vantagens incluem a capacidade de implementar operações de transação entre sistemas e melhorar a escalabilidade e simultaneidade do sistema; as desvantagens incluem a introdução de complexidade e sobrecarga de desempenho e o risco de pontos únicos de falha e comunicação de rede.

O que são reversão vazia e prevenção de travamento?

Rollback vazio: Rollback vazio significa que quando uma transação é revertida, uma vez que a transação não executa nenhuma operação de modificação ou gravação real, a operação de rollback em si não produzirá efeitos reais. Uma reversão nula pode ocorrer porque uma transação não executou nenhuma operação de modificação de dados ou ocorreu um erro durante a reversão e a operação de reversão não desfez realmente nenhuma alteração na transação. Uma reversão vazia causa sobrecarga desnecessária de desempenho porque a operação de reversão consome recursos do sistema, mas não produz alterações substanciais nos dados.
Prevenção de travamento: Anti-travamento refere-se ao processo de processamento de transações simultâneas para evitar que uma transação seja permanentemente bloqueada por outras transações enquanto espera por recursos, fazendo com que o sistema caia em um estado de deadlock ou em um estado de longa espera. Suspensão refere-se a uma situação em que uma transação é suspensa e não pode continuar a ser executada. O objetivo do anti-penduramento é garantir que todas as transações no sistema possam ser executadas normalmente e evitar que qualquer uma delas seja incapaz de continuar a execução devido à competição de recursos.

Para evitar enforcamento, as seguintes medidas podem ser tomadas:

Defina um tempo limite de transação razoável: se uma transação não for concluída dentro de um determinado período de tempo, o sistema poderá revertê-la para evitar longas esperas.
Defina um tempo limite de bloqueio razoável: quando uma transação solicita a obtenção de um bloqueio, se o bloqueio não puder ser obtido dentro de um determinado período de tempo, a execução da transação pode ser interrompida ou uma operação de reversão pode ser realizada para evitar a suspensão.
Use o mecanismo de detecção e resolução de impasse: por meio do algoritmo de detecção de impasse, descubra e resolva oportunamente situações de impasse que podem causar suspensão.
Otimize a estratégia de controle de simultaneidade: projete razoavelmente a estratégia de controle de simultaneidade das transações para evitar competição desnecessária de recursos e acesso mutuamente exclusivo, reduzindo assim a possibilidade de suspensão.
A reversão nula e o anti-travamento são problemas que precisam ser considerados e resolvidos no processamento de transações simultâneas. Através de estratégias razoáveis de design de transação e controle de simultaneidade, a ocorrência de reversão nula pode ser reduzida e medidas podem ser tomadas para evitá-lo. A ocorrência de suspensão melhora o desempenho de simultaneidade e a confiabilidade do sistema.

Bloqueio distribuído

O que é um bloqueio distribuído? Por que precisamos usar bloqueios distribuídos em sistemas distribuídos?

Bloqueios distribuídos são um mecanismo usado para coordenar o acesso simultâneo a recursos compartilhados em sistemas distribuídos. Em um sistema distribuído, vários nós acessando recursos compartilhados ao mesmo tempo podem causar inconsistência ou conflitos de dados.Portanto, bloqueios distribuídos precisam ser usados para garantir que apenas um nó possa acessar o recurso ao mesmo tempo para garantir a consistência e correção dos dados.

Quais são os métodos de implementação de bloqueios distribuídos?

base de dados
Baseado em cache (como Redis)
Baseado em ZooKeeper etc.

Como ZK implementa bloqueios distribuídos

O ZooKeeper pode servir como um serviço de coordenação para bloqueios distribuídos. As etapas para usar o ZooKeeper para implementar bloqueios distribuídos incluem a criação de um nó ordenado temporário, a verificação se é o menor nó e a aquisição do bloqueio se for o menor nó, caso contrário, escuta o evento de exclusão do nó anterior. Quando o nó anterior de um nó é excluído, o nó atual é notificado e tenta novamente adquirir o bloqueio. Este método pode garantir que apenas um nó possa obter o bloqueio, realizando acesso mutuamente exclusivo em um ambiente distribuído.

Crie um caminho de bloqueio exclusivo, como a criação de um nó temporário sequencial no ZooKeeper.
Verifique se o nó que você criou é o menor entre todos os nós atuais. Ele pode ser avaliado colocando todos os nós filhos no caminho de bloqueio e comparando o número de seu próprio nó com o número de outros nós.
Se for o menor nó, significa que o bloqueio foi obtido com sucesso e a lógica de negócio foi executada.
Se não for o menor nó, ele escuta o evento de exclusão do nó anterior.
Quando o nó anterior for excluído, receba a notificação, tente adquirir o bloqueio novamente e retorne ao passo 2.
O princípio de usar o ZooKeeper para implementar bloqueios distribuídos é baseado nos nós temporários ordenados e no mecanismo de monitoramento fornecido pelo ZooKeeper. Os nós temporários ordenados garantem a ordem dos nós, e o mecanismo de escuta é usado para implementar funções de espera e ativação. Dessa forma, apenas um nó pode se tornar o menor nó e adquirir o bloqueio com sucesso, enquanto outros nós aguardarão e competirão pela liberação do bloqueio.
Deve-se observar que ao usar o ZooKeeper para implementar bloqueios distribuídos, exceções e tratamento de tempo limite de bloqueio devem ser considerados para evitar conflitos e problemas de longa espera.

bloqueio distribuído redis resolve problemas de impasse e renovação de bloqueio

Os bloqueios distribuídos baseados em Redis são implementados através das seguintes etapas:

Use o comando SETNX para tentar definir uma chave específica como bloqueio no Redis. Se a configuração for bem-sucedida, o bloqueio será obtido; caso contrário, significa que o bloqueio já está mantido por outro nó.
Defina o tempo de expiração do bloqueio para evitar que o bloqueio fique ocupado por um longo período e evite deadlock.
Execute a lógica de negócios, libere o bloqueio após a conclusão e use o comando DEL para excluir a chave de bloqueio.
Ao lidar com problemas de contenção de bloqueios, as seguintes estratégias podem ser usadas:

Um nó que não consegue competir por um bloqueio pode usar spin (espera de giro) ou esperar um período de tempo e então tentar adquirir o bloqueio novamente.
Para evitar que o bloqueio seja liberado devido a negócios inacabados devido ao tempo de expiração do bloqueio ser muito curto, você pode usar o mecanismo de renovação antes do tempo de expiração do bloqueio e usar o comando EXPIRE para estender o tempo de expiração do bloqueio.
O middleware usado para isso é o watchDog watchdog.

Lidando com problemas de deadlock e livelock de bloqueios distribuídos

O problema do impasse pode ser resolvido introduzindo um mecanismo de tempo limite e detecção de impasse. Quando uma transação não consegue obter um bloqueio dentro de um período de tempo, ela pode optar por desistir de adquirir o bloqueio ou realizar uma operação de reversão para evitar o bloqueio de longo prazo. A detecção de deadlock pode verificar periodicamente o status de ocupação do bloqueio e realizar operações de desbloqueio ou reversão após detectar um deadlock.
O problema do livelock pode ser resolvido introduzindo aleatoriedade, estratégia de backoff e mecanismo de nova tentativa. A aleatoriedade pode evitar problemas de concorrência causados por múltiplas tentativas de transações ao mesmo tempo.A estratégia de backoff permite que as transações esperem temporariamente ao encontrar concorrência e selecionem aleatoriamente o intervalo de novas tentativas.

Problemas de tempo limite de bloqueios distribuídos e considerações relacionadas

O problema de tempo limite de bloqueios distribuídos pode ser resolvido definindo um tempo limite de bloqueio apropriado. Quando uma transação leva mais tempo para adquirir um bloqueio do que o tempo limite definido, ela pode optar por desistir da aquisição do bloqueio ou realizar outro processamento.
O mecanismo de tempo limite precisa ser definido adequadamente com base nos requisitos de negócios e no desempenho do sistema. Definir o período de tempo limite muito curto pode levar à competição frequente de bloqueios e novas tentativas malsucedidas, afetando o desempenho; definir o período de tempo limite muito longo pode fazer com que as transações esperem por bloqueios por um longo tempo, afetando a capacidade de resposta do sistema.

O significado e a importância da reentrada de bloqueios distribuídos:

Reentrada significa que o mesmo thread pode adquirir o bloqueio novamente sem causar deadlock enquanto mantém o bloqueio.
Em bloqueios distribuídos, a reentrada é muito importante, porque em um ambiente distribuído, uma transação pode envolver múltiplas suboperações, e essas suboperações podem precisar adquirir o mesmo bloqueio. Se o bloqueio distribuído não suportar reentrada, ocorrerão conflitos ou erros de lógica.

Em cenários de alta simultaneidade, os bloqueios distribuídos podem enfrentar os seguintes desafios de desempenho e escalabilidade:

Concorrência de bloqueio: Sob condições de alta simultaneidade, vários threads competem por recursos de bloqueio ao mesmo tempo, resultando em uma competição acirrada por bloqueios, o que pode causar gargalos de desempenho e aumento de latência.
Granularidade de bloqueio: Se a granularidade de bloqueio for muito grande, ou seja, muitos recursos bloqueados, isso levará a uma diminuição na simultaneidade e limitará a escalabilidade do sistema. Se a granularidade do bloqueio for muito fina, poderá aumentar a contenção de bloqueio e causar problemas de contenção de bloqueio.
Gerenciamento de bloqueios: Os bloqueios distribuídos precisam gerenciar o processo de aquisição e liberação de bloqueios, incluindo registro de nós, detecção de pulsação, manutenção do status de bloqueio, etc.

Para otimizar o desempenho dos bloqueios distribuídos, em cenários de alta simultaneidade, podem ser consideradas as seguintes estratégias:

Otimização da granularidade de bloqueio: avalie a granularidade de bloqueio com base nas necessidades de negócios e nos padrões de acesso a dados. Tente minimizar a granularidade do bloqueio para reduzir a contenção de bloqueios.
Otimização de cache: Use cache para reduzir o acesso frequente a bloqueios distribuídos. Você pode reduzir o número de solicitações de bloqueios distribuídos por meio de pré-busca de cache, status de bloqueio de cache, etc.
Processamento assíncrono: operações assíncronas que não exigem a obtenção de bloqueios distribuídos para reduzir a competição por recursos de bloqueio. Desacople as operações que podem ser executadas em paralelo para melhorar o desempenho de simultaneidade do sistema.
Otimize algoritmos de bloqueio: Escolha algoritmos de bloqueio distribuído de alto desempenho, como bloqueios distribuídos baseados em ZooKeeper, bloqueios distribuídos baseados em Redis, etc., e selecione a implementação de bloqueio distribuído mais apropriada com base em cenários de negócios específicos.
Bloqueio de fragmentação: se possível, divida os dados em fragmentos e use bloqueios independentes em cada fragmento para reduzir o escopo da competição de bloqueios e melhorar o desempenho da simultaneidade.
Configuração de tempo limite de bloqueio: Defina o tempo limite de bloqueio de maneira razoável para evitar ocupação de bloqueio de longo prazo e melhorar a capacidade de resposta do sistema.
Evite deadlocks e livelocks: Um protocolo de bloqueio bem projetado pode evitar a ocorrência de deadlocks e livelocks e garantir a operação normal do sistema.

As estratégias acima podem ser ajustadas e otimizadas de acordo com cenários de negócios específicos e requisitos de sistema para melhorar o desempenho e a escalabilidade de bloqueios distribuídos em cenários de alta simultaneidade.

algoritmo

algoritmo de hash

Aqui estão alguns algoritmos de hash comuns:

MD5 (Message Digest Algorithm 5): Gera um valor hash de 128 bits, frequentemente usado para verificar a integridade dos dados. Devido à sua baixa segurança e vulnerabilidade a ataques de colisão, não é mais recomendado para cenários de segurança como armazenamento de senhas.
SHA-1 (Secure Hash Algorithm 1): Gera um valor hash de 160 bits e também é comumente usado para verificar a integridade dos dados. Semelhante ao MD5, seu uso em cenários sensíveis à segurança não é mais recomendado.
SHA-256 (Algoritmo Hash Seguro de 256 bits): Um da série SHA-2, que gera um valor hash de 256 bits e é amplamente utilizado em criptografia, assinaturas digitais e outros campos.
SHA-3 (Secure Hash Algorithm 3): Um dos da série SHA-3, é o mais recente padrão de algoritmo de hash, fornecendo maior segurança e recursos anticolisão.
CRC32 (Cyclic Redundancy Check 32): Gera um valor hash de 32 bits, usado principalmente para verificação de dados e detecção de erros, comumente usado em sistemas de transmissão e armazenamento de rede.
MurmurHash: Uma série de algoritmos hash não criptografados de alto desempenho, com cálculo rápido e baixo risco de colisão. É comumente usado em tabelas hash, caches distribuídos e outros cenários.
CityHash: Um algoritmo de hash de alta velocidade adequado para processar grandes conjuntos de dados e amplamente utilizado em sistemas distribuídos, mecanismos de pesquisa, etc.
Hash FNV (Fowler-Noll-Vo): Um algoritmo hash simples, mas eficiente, que fornece boa distribuição e baixa probabilidade de colisão e é adequado para aplicações como tabelas hash.

Esses são algoritmos de hash comuns e cada algoritmo tem seus cenários de aplicação específicos, vantagens e desvantagens. Ao escolher um algoritmo hash, você precisa considerar fatores como segurança, velocidade, distribuição e resistência a colisões de acordo com necessidades específicas para selecionar um algoritmo adequado.

Alguns algoritmos comuns de limitação de corrente

Algoritmo de contador de janela fixa (contador de janela fixa): conta solicitações dentro de uma janela de tempo fixa e limita o fluxo quando o número de solicitações atinge o limite. Por exemplo, apenas 100 solicitações por segundo podem ser processadas.
Algoritmo do contador de janela deslizante: semelhante ao algoritmo do contador de janela fixa, mas dentro de cada janela de tempo, o número de solicitações permitidas pode ser ajustado dinamicamente. Por exemplo, é permitida uma média de 100 solicitações por segundo, mas não são permitidas mais de 200 solicitações.
Algoritmo Leaky Bucket: coloca as solicitações em um bucket de tamanho fixo a uma taxa constante. As solicitações que excedem a capacidade do bucket serão descartadas ou atrasadas. A taxa de solicitações pode ser controlada.
Algoritmo Token Bucket: semelhante ao algoritmo leaky bucket, mas os tokens são gerados no bucket a uma taxa fixa em cada unidade de tempo. A solicitação precisa obter um token antes de poder ser processada. Quando não houver tokens suficientes no bucket, a solicitação será descartada ou atrasada.
Algoritmo de funil: O processamento de solicitações é limitado com base na capacidade e taxa do funil. Cada solicitação ocupará uma determinada capacidade, quando a capacidade restante do funil for insuficiente, a solicitação será descartada ou atrasada.

Esses algoritmos podem ser selecionados e usados de acordo com cenários e necessidades específicas de aplicação. O algoritmo de limitação de corrente pode proteger o sistema contra pressão excessiva de solicitação, evitar sobrecarga do sistema e garantir uma alocação razoável de recursos e operação estável.