Bloqueio otimista ou pessimista - qual deles você deve escolher?

Suponha que Alice e Joe leiam o mesmo item de dados do Couchbase Server, então eles ambos alteraram os dados e, em seguida, ambos tentaram gravar as novas versões de volta no banco de dados. De quem são as alterações que devem ser salvas? As da Alice? As do Joe? Nenhuma delas? Uma combinação? São perguntas como essas que determinam o vencedor no debate sobre bloqueio pessimista versus otimista.

Especificamente, os desenvolvedores usam o bloqueio para serializar o acesso a itens de dados compartilhados. Mas qual esquema de bloqueio você deve escolher para seu aplicativo?

Neste blog, vou explicar o bloqueio otimista versus o bloqueio pessimista e as diferenças entre os dois. Também vamos discutir as APIs de bloqueio otimista e pessimista que você pode usar no Couchbase Servidor para controlar o acesso simultâneo aos seus dados.

O que é o bloqueio otimista no Couchbase Server?

Vamos supor que estejamos criando um aplicativo semelhante à Wikipédia on-line usando o Couchbase Server: os usuários podem atualizar um artigo e adicionar novos artigos. Vamos supor que Alice esteja usando esse aplicativo para editar um artigo sobre "bicicletas para corrigir algumas informações. Alice abre o artigo e faz Essas mudanças, mas antes de clicar em salvar, ela se distrai e se afasta de sua mesa. Enquanto isso, vamos supor que Joe perceba o mesmo erro no artigo sobre bicicletas e queira corrigir o erro.

Se o bloqueio otimista for usado no aplicativo, Joe poderá editar o artigo e salvar suas alterações. Quando Alice retornar e quiser salvar suas alterações, Alice ou o aplicativo desejará lidar com as atualizações mais recentes antes de permitir que a ação de Alice altere o documento. Otimista O bloqueio adota a visão "otimista" de que os conflitos de dados devido a edições simultâneas ocorrem raramente, portanto, é mais importante para permitir edições simultâneas.

O que é Pessimistic Locking no Couchbase Server?

Agora vamos supor que seu processo comercial exija acesso exclusivo a um ou mais documentos ou um gráfico de documentos. Referindo-se ao nosso exemplo anterior, quando Alice estiver editando o documento, ela não quer que nenhum outro usuário edite o mesmo documento. Se Joe tentar abrir o a página, ele terá que esperar até que Alice libere o cadeado.

Com o bloqueio pessimista, o aplicativo precisará obter explicitamente um bloqueio no documento para garantem o acesso exclusivo do usuário. Quando o usuário termina de acessar o documento, os bloqueios podem ser removido manualmente ou usando um tempo limite.

Então, qual deles você deve escolher?

A resposta é que não há uma resposta correta. depende. Você deve escolher seu bloqueio com base nos requisitos de sua aplicação.

A menos que você espere que um documento seja muito disputado, o bloqueio otimista será muito menor sobrecarga do que o bloqueio pessimista - pegue o item que você precisa, atualize-o rapidamente e tenteou aplicá-lo. Se algum outro ator do sistema chegar antes de você, basta tentar novamente até conseguir.

Com o bloqueio pessimista, você pode obter acesso exclusivo a um determinado item - nenhum outro thread pode acessar o item enquanto ele estiver bloqueado. Você precisa ter certeza de que liberará o bloqueio durante as falhas. Imagine que eu tenha o objeto cereal e não o entregue até obter o objeto leite. Mas você tem o objeto de leite e não o entregará até obter o objeto de cereal. Os tempos limite podem ser usados para possivelmente quebrar deadlocks ou para lidar com clientes que não liberam o bloqueio. 

Para simplificar, os usuários podem escolher a mesma estratégia de bloqueio em todo o aplicativo. Essa funciona bem se os requisitos de acesso de todos os diferentes objetos em seu aplicativo forem mas, na realidade, esse não é o caso - objetos de aplicativos diferentes têm acesso diferente requisitos. Por exemplo, no caso de jogos sociais -

1. As informações do inventário do personagem e do jogador são muito acessadas durante o jogo,

que exigem acesso rápido de leitura e gravação. Primeira opção - Use o bloqueio otimista. Próxima opção - Use o bloqueio otimista.

Bloqueio pessimista

2. As contas e as preferências dos jogadores são lidas durante o login do jogador ou no início de um jogo

mas não é atualizado com frequência. O bloqueio otimista também funcionaria bem aqui.

Obtenção de um bloqueio pessimista no Couchbase Server

A obtenção de um bloqueio no Couchbase Server consiste nas seguintes etapas:

1. Use a API get-and-lock para recuperar um valor para uma determinada chave e bloquear essa chave
2. O aplicativo agora tem controle exclusivo sobre o documento

Obtenção de um bloqueio otimista no Couchbase Server

A obtenção de um bloqueio no Couchbase Server consiste nas seguintes etapas:

1. Use a API de check-and-set (CAS) para recuperar um número de revisão do CAS

Liberação de um bloqueio no Couchbase Server

Execute estas etapas para liberar manualmente um bloqueio:

1. Use o CAS para modificar o valor e liberar o bloqueio

Nos bastidores do CAS

A operação CAS é um conceito simples que pode ser usado para criar mecanismos de controle de simultaneidade mais avançados. O CAS determina se um objeto foi atualizado por outro cliente entre o momento em que foi lido inicialmente e o momento em que se tentou salvar. Se o objeto for modificado por outro cliente, será gerado um erro e o aplicativo terá de reler o valor e tentar novamente a operação. Se os objetos não estiverem em alta contenção, a transformação dos dados for idempotente e a repetição da operação for facilmente realizada sem muito desperdício de trabalho, o bloqueio otimista é uma boa solução que oferece alto desempenho no caso médio.

Uma maneira comum de interagir com o CAS envolve um loop do CAS, conforme mostrado na comunidade desenvolvida cliente go memcached.

Por exemplo: Imagine que há três clientes, conforme mostrado no diagrama de interação abaixo. Todos os três clientes tentam atualizar o objeto X usando o CAS - cada cliente é bem-sucedido, um de cada vez.

Você não liberou o bloqueio, deixe que o Couchbase faça isso por você

Ao executar uma operação get-and-lock, você fornece um prazo de validade para o bloqueio como parâmetro. O período de tempo padrão em que uma chave pode ser bloqueada é de 15 segundos. Após 15 segundos, se você não liberar o bloqueio manualmente, o Couchbase o liberará automaticamente.

Considerações finais sobre bloqueio pessimista e otimista em bancos de dados

O bloqueio otimista pode não ser a melhor solução para todas as situações. Embora alguns casos de uso funcionem bem com o bloqueio otimista, outros podem precisar de esquemas mais rígidos, como o bloqueio pessimista.

O bloqueio pode não ser bom para todos os casos - seu aplicativo pode ter um problema se houver uma contenção de bloqueio. Um thread pode manter um bloqueio e ter o agendamento cancelado pelo sistema operacional. Então, todos os threads que quiserem adquirir esse bloqueio serão bloqueados. Uma opção é evitar totalmente o bloqueio sempre que possível, usando operações atômicas. Essas APIs podem ser muito úteis em dados muito contestados.

No entanto, se você realmente precisar de bloqueio e achar que o bloqueio otimista abrange a maioria dos casos de uso dos seus aplicativos, o bloqueio otimista usando CAS no Couchbase Server é tão fácil de implementar que não há motivo para não tentar.