pilha de cachorro
Dogpile consiste em dois subsistemas, um construído em cima do outro.
dogpile fornece o conceito de "dogpile lock", uma estrutura de controle que permite que um único thread de execução seja selecionado como o "criador" de algum recurso, enquanto permite que outros threads de execução se refiram à versão anterior deste recurso como o a criação procede; se não houver versão anterior, esses threads serão bloqueados até que o objeto esteja disponível.
dogpile.cache é uma API de cache que fornece uma interface genérica para armazenar back-ends de qualquer variedade e, adicionalmente, fornece ganchos de API que integram esses back-ends de cache com o mecanismo de bloqueio de dogpile .
No geral, dogpile.cache pretende ser um substituto do sistema de cache Beaker, cujos componentes internos foram escritos pelo mesmo autor. Todas as ideias do Beaker que "funcionam" são reimplementadas em dogpile.cache de uma maneira mais eficiente e sucinta, e todo o lixo (os internos do Beaker foram escritos pela primeira vez em 2005) relegados à lixeira.
Documentação
Veja a documentação completa do dogpile.cache na documentação do dogpile.cache. As seções abaixo fornecem uma breve sinopse dos pacotes dogpile .
Características
- Uma API sucinta que incentiva a configuração inicial de "regiões" predefinidas, cada uma definindo um conjunto de características de cache, incluindo back-end de armazenamento, opções de configuração e tempo de expiração padrão.
- É fornecida uma API padrão de obtenção/definição/exclusão, bem como uma API de decorador de função.
- A mecânica de geração de chaves é totalmente personalizável. A API do decorador de função apresenta um "gerador de chaves" conectável para personalizar como as chaves de cache são feitas para corresponder às chamadas de função, e um recurso opcional de "gerador de chaves" fornece a manipulação conectável de chaves (como codificação, hash SHA-1) conforme desejado para cada região.
- O dogpile lock, desenvolvido inicialmente como o mecanismo principal por trás do sistema de cache Beaker, aqui foi amplamente simplificado, aprimorado e melhor testado. Alguns problemas importantes de desempenho que eram intrínsecos à arquitetura do Beaker, particularmente que os valores seriam frequentemente "buscados duas vezes" do cache, foram corrigidos.
- Os backends implementam sua própria versão de um bloqueio “distribuído”, onde a “distribuição” corresponde ao sistema de armazenamento do backend. Por exemplo, os backends do memcached permitem que todos os clientes coordenem a criação de valores usando o próprio memcached. O back-end do arquivo dbm usa um arquivo de bloqueio junto com o arquivo dbm. Novos back-ends, como back-ends baseados em Redis, podem fornecer seu próprio mecanismo de bloqueio apropriado ao mecanismo de armazenamento.
- Escrever novos back-ends ou hackear os back-ends existentes deve ser rotineiro - tudo o que é necessário são métodos básicos de obter/definir/excluir. Um bloqueio distribuído adaptado ao backend é uma adição opcional, caso contrário, o dogpile usa um mutex de thread regular. Novos backends podem ser registrados diretamente com dogpile.cache ou disponibilizados através dos pontos de entrada do setuptools.
- Os back-ends incluídos apresentam três back-ends memcached (python-memcached, pylibmc, bmemcached), um back-end Redis, um back-end baseado no anydbm do Python e um back-end de dicionário simples.
- Espaço para plugins de terceiros, incluindo um que fornece o mecanismo dogpile.cache para modelos Mako.
O Projeto SQLAlchemy
Dogpile faz parte do Projeto SQLAlchemy e segue os mesmos padrões e convenções do projeto principal.
Desenvolvimento / Relatório de bugs / Solicitações pull
Consulte o Guia da Comunidade SQLAlchemy para obter diretrizes sobre codificação e participação neste projeto.
Código de Conduta
Acima de tudo, SQLAlchemy dá grande ênfase à comunicação educada, atenciosa e construtiva entre usuários e desenvolvedores. Consulte nosso Código de Conduta atual em Código de Conduta.
Licença
Dogpile é distribuído sob a licença do MIT.
