Melhores Práticas do Tokio

Regras operacionais para runtimes Tokio em produção - dimensionamento de workers, higiene do pool de bloqueio e disciplina de encerramento.

Como Usar Esta Lista

Aplique antes do primeiro deploy em produção de um serviço Tokio/Axum.
Revise após incidentes de latência ou travamentos em rollouts do Kubernetes.
Combine com tracing, testes de carga e tokio-console opcional.

A - Configuração do Runtime

Use multi_thread para servidores de API. current_thread para testes e apenas LocalSet.
Defina worker_threads a partir de profiling, não de suposições. Comece com a contagem de CPUs.
Ajuste max_blocking_threads ao usar spawn_blocking intensivamente. Monitore a profundidade da fila.
Ative apenas os recursos tracing e tokio que você precisa. Binários menores, builds mais rápidas.
Um Runtime por processo. Bibliotecas não devem incorporar #[tokio::main].

B - Higiene de Tarefas e I/O

Crie tarefas por conexão ou use Axum - não bloqueie o loop de aceitação. A vazão cai em aceitação serial.
Nomeie tarefas em caminhos críticos para depuração. task::Builder::new().name(...).
Aguarde ou aborte cada JoinHandle. Rastreie o trabalho em segundo plano em JoinSet.
Use BufReader/BufWriter em I/O de socket. Reduza o overhead de syscall.
Prefira tokio::fs e crates async em vez de std em workers. Bloquear causa starvation de tarefas.

C - Canais e `select!`

Dimensiona canais mpsc para backpressure de rajada. Não filas infinitas.
Use watch ou CancellationToken para encerramento. Propague para todos os loops.
Projete loops select! com branches cancel-safe. Documente leituras de protocolo.
Defina MissedTickBehavior::Skip em heartbeats. Evite tempestades de timers após pausas.
Adicione timeouts em I/O de saída. Peers travam; recursos vazam.

D - Estado e Integrações

Armazene sqlx::Pool e reqwest::Client no estado Arc na inicialização. Reutilize conexões.
Use tokio::sync::Mutex se o mutex precisar cruzar um await. Não std::sync::Mutex.
Considere tarefas de ator para estado mutável crítico. Reduza a contenção de locks.
Feche o pool e descarregue logs no encerramento. pool.close().await no hook de graceful.
Propague IDs de trace através de spans e headers de saída. Correlacione logs entre serviços.

E - Operações

Implemente encerramento gracioso (SIGTERM + timeout de drain). Corresponda ao período de graça do K8s.
Monitore a saturação do pool de bloqueio e os tempos de poll de tarefas. Sinal precoce de regressão.
Teste de carga nos caminhos de deploy e SIGTERM. Encerramentos travados bloqueiam rollouts.
Use #[tokio::test(start_paused = true)] para testes de timer. CI determinístico.
Documente a versão do runtime e do Axum nos runbooks. Upgrades afetam APIs de I/O e encerramento.

FAQs

Contagem padrão de threads workers?

Tokio usa por padrão a contagem de núcleos da CPU - ajuste apenas com métricas que mostrem starvation de workers ou excesso de threads ociosas.

Quando usar spawn_blocking?

I/O legado síncrono, lotes de CPU, seções Rayon - sempre limite a concorrência com semáforos quando o volume for alto.

tokio-console vale a pena?

Valioso durante incidentes e ajuste; opcional em produção devido ao overhead - ative em nós canários.

Axum sem entender Tokio?

Arriscado - handlers são tarefas Tokio; o comportamento de bloqueio e encerramento é de propriedade do runtime.

feature = "full"?

Ok para aprender; crates de produção devem ativar o conjunto mínimo de features (rt-multi-thread, net, time, macros, etc.).

picos de latência?

Primeiro verifique bloqueios em workers, contenção de locks e timeouts ausentes - não "async é lento".

limites de conexão?

Corresponda a concorrência do Tokio ao tamanho do pool de DB e limites de taxa upstream - semáforos nas fronteiras.

atualizar Tokio?

Leia o changelog para mudanças de I/O, timer e MSRV; reexecute testes de encerramento e carga.

CLI de binário único?

#[tokio::main(flavor = "current_thread")] pode ser suficiente para comandos async de execução única.

primeiro item da checklist de produção?

Encerramento gracioso com drain rastreado e fechamento do pool - antes de otimizar ganhos de microssegundos.

Relacionado

Fundamentos do Tokio - primeiros passos
Encerramento Gracioso - segurança de deploy
Bloqueio em Async - pool de bloqueio
Melhores Práticas Async - regras gerais de async
Tracing & Instrumentação - observabilidade

Versões de Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.

Melhores Práticas do Tokio

Regras operacionais para runtimes Tokio em produção - dimensionamento de workers, higiene do pool de bloqueio e disciplina de encerramento.

Como Usar Esta Lista

Aplique antes do primeiro deploy em produção de um serviço Tokio/Axum.
Revise após incidentes de latência ou travamentos em rollouts do Kubernetes.
Combine com tracing, testes de carga e tokio-console opcional.

A - Configuração do Runtime

Use multi_thread para servidores de API. current_thread para testes e apenas LocalSet.
Defina worker_threads a partir de profiling, não de suposições. Comece com a contagem de CPUs.
Ajuste max_blocking_threads ao usar spawn_blocking intensivamente. Monitore a profundidade da fila.
Ative apenas os recursos tracing e tokio que você precisa. Binários menores, builds mais rápidas.
Um Runtime por processo. Bibliotecas não devem incorporar #[tokio::main].

B - Higiene de Tarefas e I/O

Crie tarefas por conexão ou use Axum - não bloqueie o loop de aceitação. A vazão cai em aceitação serial.
Nomeie tarefas em caminhos críticos para depuração. task::Builder::new().name(...).
Aguarde ou aborte cada JoinHandle. Rastreie o trabalho em segundo plano em JoinSet.
Use BufReader/BufWriter em I/O de socket. Reduza o overhead de syscall.
Prefira tokio::fs e crates async em vez de std em workers. Bloquear causa starvation de tarefas.

C - Canais e `select!`

Dimensiona canais mpsc para backpressure de rajada. Não filas infinitas.
Use watch ou CancellationToken para encerramento. Propague para todos os loops.
Projete loops select! com branches cancel-safe. Documente leituras de protocolo.
Defina MissedTickBehavior::Skip em heartbeats. Evite tempestades de timers após pausas.
Adicione timeouts em I/O de saída. Peers travam; recursos vazam.

D - Estado e Integrações

Armazene sqlx::Pool e reqwest::Client no estado Arc na inicialização. Reutilize conexões.
Use tokio::sync::Mutex se o mutex precisar cruzar um await. Não std::sync::Mutex.
Considere tarefas de ator para estado mutável crítico. Reduza a contenção de locks.
Feche o pool e descarregue logs no encerramento. pool.close().await no hook de graceful.
Propague IDs de trace através de spans e headers de saída. Correlacione logs entre serviços.

E - Operações

Implemente encerramento gracioso (SIGTERM + timeout de drain). Corresponda ao período de graça do K8s.
Monitore a saturação do pool de bloqueio e os tempos de poll de tarefas. Sinal precoce de regressão.
Teste de carga nos caminhos de deploy e SIGTERM. Encerramentos travados bloqueiam rollouts.
Use #[tokio::test(start_paused = true)] para testes de timer. CI determinístico.
Documente a versão do runtime e do Axum nos runbooks. Upgrades afetam APIs de I/O e encerramento.

FAQs

Contagem padrão de threads workers?

Tokio usa por padrão a contagem de núcleos da CPU - ajuste apenas com métricas que mostrem starvation de workers ou excesso de threads ociosas.

Quando usar spawn_blocking?

I/O legado síncrono, lotes de CPU, seções Rayon - sempre limite a concorrência com semáforos quando o volume for alto.

tokio-console vale a pena?

Valioso durante incidentes e ajuste; opcional em produção devido ao overhead - ative em nós canários.

Axum sem entender Tokio?

Arriscado - handlers são tarefas Tokio; o comportamento de bloqueio e encerramento é de propriedade do runtime.

feature = "full"?

Ok para aprender; crates de produção devem ativar o conjunto mínimo de features (rt-multi-thread, net, time, macros, etc.).

picos de latência?

Primeiro verifique bloqueios em workers, contenção de locks e timeouts ausentes - não "async é lento".

limites de conexão?

Corresponda a concorrência do Tokio ao tamanho do pool de DB e limites de taxa upstream - semáforos nas fronteiras.

atualizar Tokio?

Leia o changelog para mudanças de I/O, timer e MSRV; reexecute testes de encerramento e carga.

CLI de binário único?

#[tokio::main(flavor = "current_thread")] pode ser suficiente para comandos async de execução única.

primeiro item da checklist de produção?

Encerramento gracioso com drain rastreado e fechamento do pool - antes de otimizar ganhos de microssegundos.

Relacionado

Fundamentos do Tokio - primeiros passos
Encerramento Gracioso - segurança de deploy
Bloqueio em Async - pool de bloqueio
Melhores Práticas Async - regras gerais de async
Tracing & Instrumentação - observabilidade

Versões de Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.

Melhores Práticas do Tokio

Buscar na documentação

Melhores Práticas do Tokio