Para um sistema de arquivos orientado por uma combinação de armazenamento de objetos e banco de dados, o armazenamento em cache é um link importante para a interação eficiente entre clientes locais e serviços remotos. Os dados de leitura e gravação podem ser carregados no cache antecipadamente ou de forma assíncrona e, em seguida, o cliente interage com o serviço remoto em segundo plano para realizar upload assíncrono ou pré-busca de dados. Comparado com a interação direta com serviços remotos, o uso da tecnologia de cache pode reduzir bastante a latência das operações de armazenamento e melhorar a taxa de transferência de dados.
a consistência dos dados
O JuiceFS fornece uma garantia de consistência "perto para abrir", ou seja, quando dois ou mais clientes lêem e gravam o mesmo arquivo ao mesmo tempo, as modificações do cliente A podem não ser imediatamente visíveis para o cliente B. No entanto, uma vez que o arquivo é escrito no cliente A e fechado, reabrir o arquivo em qualquer cliente posteriormente garante o acesso aos dados escritos mais recentemente, seja no mesmo nó ou não.
"Fechar e reabrir" é a garantia de consistência mínima fornecida pelo JuiceFS. Em alguns casos, pode não ser necessário reabrir o arquivo para acessar os últimos dados gravados. Por exemplo, vários aplicativos usam o mesmo cliente JuiceFS para acessar o mesmo arquivo (as alterações no arquivo são imediatamente visíveis) ou para visualizar os dados mais recentes por meio de tail -fcomandos .
cache de metadados
JuiceFS suporta cache de metadados no kernel e na memória do cliente (ou seja, processo JuiceFS) para melhorar o desempenho de acesso aos metadados.
Cache de metadados do kernel
Existem três tipos de metadados que podem ser armazenados em cache no kernel: attribute , entry e direntry. O tempo de cache pode ser controlado pelos seguintes parâmetros de montagem:
--attr-cache value 属性缓存时长，单位秒 (默认值: 1)
--entry-cache value 文件项缓存时长，单位秒 (默认值: 1)
--dir-entry-cache value 目录项缓存时长，单位秒 (默认值: 1)
JuiceFS armazena em cache atributos, itens de arquivo e itens de diretório no kernel por padrão por 1 segundo para melhorar o desempenho de lookup e getattr. Quando clientes de vários nós usam o mesmo sistema de arquivos ao mesmo tempo, os metadados armazenados em cache no kernel só podem ser invalidados ao longo do tempo. Ou seja, em casos extremos, o nó A pode modificar os metadados de um arquivo (por exemplo chown, ), e o acesso através do nó B não pode ver a atualização imediatamente. É claro que, depois que o cache expirar, todos os nós eventualmente verão as modificações feitas por A.
Cache de metadados na memória do lado do cliente
Nota : Este recurso requer JuiceFS versão 0.15.0 e superior.
Quando um cliente open()JuiceFS abre um arquivo, seus atributos de arquivo são automaticamente armazenados em cache na memória do cliente. Se a --open-cacheopção valor maior que 0, as operaçõesgetattr() subseqüentes e retornarão o resultado do cache na memória imediatamente, desde que o cache não tenha expirado.open()
Ao realizar read()uma operação , ou seja, ler um arquivo, as informações de fragmentos e fatias do arquivo serão automaticamente armazenadas em cache na memória do cliente. Durante o período de validade do cache, a leitura do fragmento novamente retornará imediatamente as informações do slice do cache de memória.
Dica : Você pode ler "Como o JuiceFS armazena arquivos" para saber o que são pedaços e fatias.
Por padrão, para um arquivo cujos metadados foram armazenados em cache na memória, se não for acessado por nenhum processo por mais de 1 hora, todo o seu cache de metadados será excluído automaticamente.
cache de dados
JuiceFS também fornece vários mecanismos de cache de dados para melhorar o desempenho, incluindo o cache de página no kernel e o cache local do nó onde o cliente está localizado.
cache de dados do kernel
Nota : Este recurso requer JuiceFS versão 0.15.0 e superior.
Para um arquivo que foi lido, o kernel armazenará automaticamente seu conteúdo em cache e, em seguida, abrirá o arquivo. Se o arquivo não foi atualizado (ou seja, o mtime não foi atualizado), o arquivo pode ser lido diretamente do cache no kernel para obter o melhor desempenho. Graças ao cache do kernel, leituras repetidas do mesmo arquivo no JuiceFS podem ser muito rápidas, com latência tão baixa quanto microssegundos e taxa de transferência em GiBs por segundo.
O cliente JuiceFS não habilitou a função de cache de gravação do kernel por padrão. A partir do kernel Linux 3.15, o FUSE suporta o "modo de cache de gravação", o que significa que as chamadas write()do sistema . Você pode habilitar o modo writeback-cache definindo a -o writeback_cacheopção . Recomenda-se habilitar esta opção de montagem quando dados muito pequenos (por exemplo, cerca de 100 bytes) precisam ser gravados com frequência.
Cache de leitura do cliente
O cliente JuiceFS pré-lê automaticamente os dados no cache de acordo com o modo de leitura, melhorando assim o desempenho das leituras sequenciais. Por padrão, ao ler dados, 1 bloco é pré-buscado e armazenado em cache localmente. O cache local pode ser configurado em qualquer sistema de arquivos local baseado em disco rígido, SSD ou memória.
O cache local pode ser ajustado com as seguintes opções ao montar o sistema de arquivos:
--prefetch value 并发预读 N 个块 (默认: 1)
--cache-dir value 本地缓存目录路径；使用冒号隔离多个路径 (默认: "$HOME/.juicefs/cache" 或 "/var/jfsCache")
--cache-size value 缓存对象的总大小；单位为 MiB (默认: 1024)
--free-space-ratio value 最小剩余空间比例 (默认: 0.1)
--cache-partial-only 仅缓存随机小块读 (默认: false)
Além disso, se você quiser armazenar o cache local do JuiceFS na memória, há duas maneiras, uma é --cache-dirdefini -lo como memory, a outra é defini-lo como /dev/shm/<cache-dir>. A diferença entre os dois métodos é que o primeiro limpará os dados em cache após remontar o sistema de arquivos JuiceFS, enquanto o último os manterá, e não há muita diferença entre os dois em termos de desempenho.
O cliente JuiceFS gravará os dados baixados do armazenamento de objetos (incluindo dados recém-carregados com menos de 1 tamanho de bloco) no diretório de cache o mais rápido possível sem compactação e criptografia. Como o JuiceFS gera nomes exclusivos para todos os objetos de bloco gravados no armazenamento de objetos e todos os objetos de bloco não serão modificados, não há necessidade de se preocupar com a invalidação de dados em cache quando o conteúdo do arquivo for atualizado.
Quando o espaço em cache atingir o limite superior (ou seja, o tamanho do cache for maior ou igual a --cache-size) ou o disco estiver cheio (ou seja, a proporção de espaço livre no disco for menor que --free-space-ratio), será A regra atual é limpar primeiro os arquivos acessados com pouca frequência de acordo com o tempo de acesso.
O cache de dados pode melhorar efetivamente o desempenho de leitura aleatória. Para aplicativos que exigem maior desempenho de leitura aleatória, como Elasticsearch e ClickHouse, é recomendável definir o caminho do cache em uma mídia de armazenamento mais rápida e alocar um espaço de cache maior.
Cache de gravação do cliente
Ao gravar dados, o cliente JuiceFS armazenará os dados em cache na close()memória fsync()e os dados não serão carregados no armazenamento de objetos até que um pedaço seja preenchido ou forçado por ou . Ao chamar fsync()ou close(), o cliente espera até que os dados sejam gravados no armazenamento de objetos e notifica o serviço de metadados antes de retornar, garantindo assim a integridade dos dados.
Em alguns casos, se o armazenamento local for confiável e o desempenho de gravação do armazenamento local for significativamente melhor do que o da gravação de rede (como disco SSD), o desempenho de gravação poderá ser aprimorado habilitando o upload assíncrono de dados, para que a close()operação não irá esperar que os dados sejam gravados no armazenamento de objetos, mas retornará quando os dados forem gravados no diretório de cache local.
O recurso de upload assíncrono está desabilitado por padrão e pode ser habilitado com as seguintes opções:
--writeback 后台异步上传对象 (默认: false)
Quando um grande número de arquivos pequenos precisa ser gravado em um curto período de tempo, é recomendável usar o --writebackparâmetro para montar o sistema de arquivos para melhorar o desempenho da gravação. Após a conclusão da gravação, você pode considerar cancelar esta opção e remontar para obter maior confiabilidade de dados escritos subseqüentes. Além disso, também é recomendável habilitar cenários que exijam um grande número de operações de gravação aleatórias, como backups incrementais do MySQL --writeback.
Atenção : Quando o upload assíncrono estiver habilitado, ou seja,
--writebackquando , não exclua<cache-dir>/<UUID>/rawstagingo conteúdo do diretório, caso contrário, causará perda de dados.
Quando o disco de cache estiver prestes a ficar cheio, a gravação de dados será suspensa e os dados serão carregados diretamente para o armazenamento de objetos (ou seja, a função de cache de gravação do lado do cliente será desativada). Quando a função de upload assíncrono está habilitada, a confiabilidade do próprio cache está diretamente relacionada à confiabilidade da escrita dos dados, devendo ser usada com cautela em cenários que exijam alta confiabilidade dos dados.
Resumir
Por fim, compartilhe uma pergunta que os usuários costumam fazer ** "Por que o tamanho do cache está definido para 50 GiB, mas na verdade ocupa 60 GiB de espaço?"**
Para a mesma quantidade de dados armazenados em cache, existem diferentes regras de cálculo de capacidade em diferentes sistemas de arquivos. JuiceFS atualmente é estimado acumulando o tamanho de todos os objetos em cache e adicionando um overhead fixo (4KiB), que não é exatamente o mesmo que o valor obtido pelo ducomando . Para evitar que o disco de cache fique cheio, quando o sistema de arquivos em que o diretório de cache está localizado ficar sem espaço, o cliente tentará reduzir o uso do cache o máximo possível.
Através da introdução acima, temos uma compreensão mais aprofundada do princípio do mecanismo de cache do JuiceFS. O próprio JuiceFS, como o sistema de arquivos subjacente, fornece vários mecanismos de cache, incluindo cache de metadados, cache de leitura e gravação de dados, etc., para garantir a consistência dos dados ao máximo. Espero que você possa aplicar melhor o JuiceFS através da compreensão deste artigo.
Leitura recomendada: Zhihu x JuiceFS: Using JuiceFS to Accelerate Flink Container Startup
Se for útil, siga nosso projeto Juicedata/JuiceFS ! (0ᴗ0✿)