Resumo do artigo: Sagas

Feb 16 2023

H. Garcia-Molina e K.

Foto de Nathan Riley no Unsplash

H. Garcia-Molina e K. Salem. 1987. Sagas . Em Proceedings of the 1987 ACM SIGMOD conferência internacional sobre gerenciamento de dados (SIGMOD '87). Association for Computing Machinery, Nova York, NY, EUA, 249–259.

Palavras-chave: Processos de Longa Duração, Sagas, Transações, Compensação, Mitigação de Falhas, Tolerância a Falhas, Transparência de Falhas

Embora o artigo original sobre Sagas tenha sido escrito há 35 anos, o problema ainda é relevante hoje. Este post explora as origens do conceito de Sagas, processos de longa duração que abrangem várias transações de banco de dados.

Introdução

Em seu artigo Sagas, Hector Garcia-Molina e Kenneth Salem introduzem o conceito de sagas para implementar operações de “longo prazo”.

Molina e Salem referem-se a processos que consistem em uma única etapa como processos de “curta duração” ou “curta duração” e processos que consistem em várias etapas como “longa duração” ou “longa duração”. Portanto, execução curta ou longa não é uma declaração sobre o tempo físico, mas uma declaração sobre o tempo lógico, com cada etapa sendo um tique-taque do relógio (Figura 1).

Figura 1 Curto e Longo Prazo

O problema

Em um ecossistema que rejeita amplamente a ideia de transações distribuídas ou bloqueios por um longo período de tempo, qualquer processo de execução longa não pode simplesmente ser mapeado para uma transação distribuída de execução longa. Em vez disso, precisamos de um mecanismo diferente para compor processos de execução longa a partir de transações não distribuídas de execução curta.

O artigo define um processo P como uma sequência de passos a, b, etc, onde cada passo é uma transação de banco de dados. Para usar termos mais familiares, você pode pensar em um processo como uma função e na sequência de etapas como uma sequência de chamadas de API para o banco de dados.

Referimo-nos à sequência dos passos a, b, etc como um traço:

trace(P) = a • b • …

Em outras palavras: uma sequência de duas transações não é uma transação!

Figura 2. A composição sequencial de duas transações não é uma transação em si.

Trivialmente, se um processo consiste em uma única transação, o processo exibe as garantias de atomicidade de uma transação (Figura 3).

Figura 3. Um processo P consiste em uma etapa a

No entanto, se um processo consiste em várias transações, o processo não exibe as garantias de atomicidade de uma transação: o processo pode ser executado parcialmente (Figura 4).

Figura 4. Um processo P consiste em duas etapas aeb

No entanto, ao contrário de outras transações, as transações de um processo estão relacionadas e devem ser executadas como uma unidade, qualquer execução parcial de um processo é indesejável.

O artigo discute um aplicativo de reserva de viagens, onde uma viagem consiste em vários voos potencialmente em diferentes companhias aéreas. Aqui, reservar uma viagem envolve várias transações, uma por trecho da viagem. Como viajantes, queremos que todas as transações sejam executadas como uma unidade: queremos reservar todos os voos ou nenhum voo, reservar alguns voos é inaceitável.

A solução

O artigo apresenta o Sagas, um protocolo para implementação de processos de longa duração. O protocolo Saga garante que um processo seja atômico, ou seja, um processo é executado observavelmente equivalente a completamente ou não é executado.

Figura 5. Recuperação para frente e para trás

Para mitigar a execução parcial, um processo pode implementar a recuperação para frente ou para trás [2]:

Recuperação avançada

A recuperação de falha direta refere-se a estratégias de mitigação de falha que fazem a transição do sistema do estado intermediário para um estado equivalente ao estado final (movendo o processo adiante).

Recuperação para trás

Recuperação de falha reversa refere-se a estratégias de mitigação de falha que fazem a transição do sistema do estado intermediário para um estado equivalente ao estado inicial (movendo o processo para trás).

Recuperação e compensação retrógradas

Para habilitar a recuperação reversa, cada processo deve registrar uma etapa de compensação para cada etapa (Figura 6).

Figura 6. Transação sᵢ & Compensação cᵢ

A etapa de compensação desfaz — do ponto de vista semântico — a etapa, mas não necessariamente retorna o banco de dados ao estado que existia quando a etapa começou. A compensação restaurará o mundo a um estado que seja uma aproximação aceitável do estado que tinha antes do início da transação.

Por exemplo, voltando ao aplicativo de reserva de viagens, se uma viagem consiste em dois voos e a reserva do primeiro voo foi bem-sucedida, mas a reserva do segundo voo falhou, a saga precisa cancelar a primeira reserva para retornar o banco de dados a uma aproximação aceitável ao estado tinha antes do início da reserva da viagem.

Execução

Assim, na ausência de falha, um processo P produz o traço desejado

trace(P) = s₁ • s₂ • … sₙ • ✔️

trace(P) = s₁ • s₂ • … sᵢ • × • cᵢ … • c₂ • c₁ • ✔️

Quando uma falha interrompe um Saga, um Saga deve ser capaz de recuperar seu estado atual e executar uma recuperação para frente ou para trás. Portanto, uma Saga deve ser capaz de registrar o início de uma Saga, a conclusão de uma Saga e registrar pontos de verificação e compensações.

Se você possui o banco de dados, pode registrar pontos de verificação e compensações transacionalmente com cada etapa. Se você não puder registrar os pontos de verificação e as compensações transacionalmente a cada etapa, deverá criar um mecanismo para registrar as compensações dos pontos de verificação de maneira confiável.

Discussão

Embora o artigo tenha sido escrito há mais de 35 anos, o problema e Sagas como a solução proposta ainda são relevantes hoje. No entanto, a atenção mudou da composição de transações de banco de dados para a composição de chamadas de serviço.

Lembre-se de que os serviços não exibem propriedades transacionais: os serviços podem não ser atômicos após uma chamada de serviço e, se o serviço travar, você pode não saber se o serviço entrou em vigor ou não.

Portanto, você deve registrar uma ação de compensação antes de invocar um serviço e projetar a lógica de compensação para estar correta se o serviço entrou em vigor ou não.

Conclusão

As sagas continuam relevantes, apesar dos avanços significativos na teoria e na prática desde a publicação do artigo. O conceito básico de um Saga como um protocolo para implementar atomicidade em um ambiente distribuído entre transações ou serviços, as técnicas descritas no documento continuam a ser amplamente utilizadas hoje.