Quando não é bom usar atores em akka / erlang?

Estou trabalhando com akka por 7-8 meses agora diariamente. Quando comecei, trabalhava nos aplicativos e notava que os atores seriam usados ​​basicamente em qualquer lugar do sistema de atores para se comunicar entre a maioria dos objetos. Então eu fiz o mesmo - criar outro ator por x / y / z.

Parece-me que isso pode ser muito indiscriminado, adicionando complexidade onde não é necessário - mas não consigo encontrar nenhuma discussão sobre onde os atores versus a lógica síncrona ou assíncrona simples, via futuros, devem ser usados. Comecei a ponderar minha posição depois que meu colega de trabalho mencionou algo semelhante. Percebi vários casos, mais recentemente, em que ponderei uma tarefa e evitei criar outro ator porque consegui o mesmo resultado com segurança em uma implementação imutável - por exemplo, algo como obter valores de configuração de um banco de dados ou arquivo em algum lugar em que você acessa com pouca frequência e aguardar o resultado é o caso de uso real.

Em particular, parece-me que, em qualquer caso em que você esteja jogando com um estado imutável, os atores criam complexidade e limitam a taxa de transferência - uma função pura em um objeto, por exemplo, pode ser chamada simultaneamente, sem risco de qualquer nível de simultaneidade. um ator pode processar apenas uma mensagem de cada vez. A consideração alternativa é que você estacionará o encadeamento se precisar esperar pelo resultado, a menos que comece a usar futuros, mas nos casos em que não precisa se preocupar com mensagens ou escala assíncronas, parece que pode ser um exagero empregar um ator.

Então, minha pergunta é - há um momento ruim para usar atores? Estou curioso para saber como erlang parece e realmente gostaria do insight de outras pessoas. Ou se existem alguns princípios sobre o uso do ator.

Esta é uma pergunta em que estou interessado e tenho pesquisado. Para outros pontos de vista, consulte esta postagem de Noel Walsh ou esta pergunta no Stack Overflow. Tenho algumas opiniões que gostaria de oferecer:

• Eu acho que o Akka, por trabalhar com mensagens, incentiva uma "mentalidade de empurrar". Muitas vezes, por concorrência, eu argumentaria que não é isso que você deseja. Puxar é muito mais seguro. Por exemplo, um padrão comum para sistemas distribuídos é ter um conjunto de trabalhadores processando informações em uma fila . Obviamente isso é possível em Akka, mas não parece necessariamente ser a primeira abordagem que as pessoas tentam . O Akka também oferece caixas de correio duráveis, mas novamente depende de como você as usa - uma única fila compartilhada é muito mais flexível do que as filas por trabalhador para equilibrar / reatribuir o trabalho.
• É fácil entrar na mentalidade de substituir suas aulas por atores. De fato, algumas pessoas parecem advogar dizendo que os atores devem fazer apenas uma coisa . Levado à sua conclusão lógica, isso aumenta a complexidade do código, como Jason descreve, porque se toda classe é um ator, há muitas mensagens extras e blocos de recebimento / envio. Também torna mais difícil entender e testar o código porque você perde a formalidade das interfaces - e não estou convencido de que os comentários sejam uma solução para isso . Além disso, apesar da lendária eficiência da Akka , suspeito que a proliferação de atores não seja uma boa ideia em termos de desempenho - quando usamos encadeamentos Java, sabemos que eles são preciosos e os conservam adequadamente.
• Está relacionado ao ponto anterior, mas outro aborrecimento é a perda de informações de tipo que Noel e Pino destacam, pois para muitos de nós é por isso que estamos usando Scala em vez de outras linguagens como Python. Existem algumas maneiras de contornar isso, mas elas não são padrão , não são recomendadas ou experimentais .
• Finalmente, a simultaneidade, mesmo se você tiver uma mentalidade de "deixe travar" , é difícil. Modelos de programação alternativos podem ajudar, mas eles não fazem os problemas desaparecerem - eles os modificam - é por isso que é bom pensar sobre eles formalmente . É também por isso que o desenvolvedor Joe Average busca ferramentas prontas, como os bancos de dados RabbitMQ, Storm, Hadoop, Spark, Kafka ou NoSQL. A Akka possui algumas ferramentas e componentes pré-construídos, o que é legal, mas também parece um nível bastante baixo; portanto, elementos comuns mais construídos de sistemas distribuídos ajudariam os desenvolvedores e garantiriam a criação correta dos sistemas.

Como Jason, estou ansioso para ouvir a visão de outras pessoas aqui. Como posso resolver alguns dos problemas acima e usar o Akka melhor?

Vale a pena considerar para que serve o modelo de ator: o modelo de ator é

1. um modelo de simultaneidade
2. que evita o acesso simultâneo ao estado mutável
3. usando mecanismos de comunicação assíncrona para fornecer simultaneidade.

Isso é valioso porque o uso do estado compartilhado de vários encadeamentos fica realmente difícil, especialmente quando há relacionamentos entre diferentes componentes do estado compartilhado que devem ser mantidos sincronizados. No entanto, se você tiver componentes de domínio nos quais:

• Você não permite simultaneidade OU
• Você não permite estado mutável (como na programação funcional), OU
• Você deve confiar em algum mecanismo de comunicação síncrona,

então o modelo do ator não trará muitos benefícios (se houver).

Espero que ajude.

Sua intuição está correta, IMHO. Usar atores em todos os lugares é como ter o martelo proverbial e ver apenas pregos.

A melhor prática de Erlang é usar processos / atores para todas as atividades que ocorrem simultaneamente. Ou seja, assim como na vida real. Às vezes, é difícil encontrar a granularidade certa, mas na maioria das vezes você apenas conhece o domínio modelado e usa um pouco de bom senso. Receio não ter um método melhor do que isso, mas espero que ajude.

Em ordem de entrada / saída de mensagens:

Encontrei recentemente um aplicativo baseado em akka, em que o modelo de ator realmente causava problemas de simultaneidade; um modelo mais simples seria suficiente sob carga.

O problema era que as mensagens recebidas estavam se movendo em diferentes 'faixas' (por diferentes caminhos de ator), mas o código supunha que as mensagens chegariam ao seu destino final na mesma ordem em que chegaram. Desde que os dados chegassem com intervalos suficientemente grandes, isso funcionaria porque haveria apenas uma única mensagem conflitante correndo para o destino. Quando os intervalos diminuíram, começaram a chegar fora de ordem e a causar comportamentos estranhos.

O problema poderia ter sido resolvido corretamente com um pouco menos de atores, mas é um erro fácil de cometer ao usá-los em excesso.

Na minha opinião, existem dois casos de uso para atores. Recursos compartilhados, como portas e similares, e estado grande. O primeiro foi bem coberto pela discussão até agora, mas o estado grande também é uma razão válida.

Uma grande estrutura sendo passada a cada chamada de procedimento pode usar muita pilha. Esse estado pode ser colocado em um processo separado, a estrutura substituída por uma identificação de processo e esse processo consultado conforme necessário.

Bancos de dados como mnésia podem ser considerados como um estado de armazenamento externo ao processo de consulta.