Como o token de aluguel resolve o problema do stale sets nos servidores memcached do Facebook?

A razão pela qual você'não está entendendo como isso funciona é porque você'está fazendo uma pequena mas importante suposição incorreta. Você escreve:

p>Suponha que o Cliente A tentou obter a chave K, mas ele'é um erro. Ele também recebe a ficha L1. Ao mesmo tempo, o Cliente B também tenta obter a chave K, it's novamente, uma falha. B recebe a ficha de aluguer L2 > L1. Ambos precisam de ir buscar a K ao DB.

No entanto, isto não vai acontecer porque se o servidor memcached deu recentemente um token de aluguer, ele não vai dar outro. Em outras palavras, B não recebe um token de aluguel neste cenário. Em vez disso, o que B recebe é um resultado de hot miss que diz ao cliente B que outro cliente (nomeadamente o cliente A) já está a ir para o BD para o valor, e que o cliente B terá de tentar novamente mais tarde.

Então, os alugueres funcionam na prática porque apenas um cliente está a ir para o BD num determinado momento para um determinado valor no cache.

Outras vezes, quando um novo apagamento chegar, o memcached saberá que o próximo contrato de arrendamento (o do cliente A) já está obsoleto, por isso aceitará o valor (porque é mais recente) mas marcará como obsoleto e o próximo cliente a pedir esse valor receberá um novo token de arrendamento, e os clientes depois disso obterão mais uma vez resultados de "hot miss".

Note também que os resultados de hot miss incluem o último valor stale, para que um cliente possa tomar a decisão de avançar com dados ligeiramente stale, ou tentar novamente (via backoff exponencial) para obter os dados mais atualizados possíveis.