Arquitetura de Software - Concorrência

3,673 views
3,547 views

Published on

Introdução à Concorrência em Arquitetura de Software. Abordagem de conceitos como Processos, Threads, Bancos de Dados, Locking, Isolamento e ACID.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,673
On SlideShare
0
From Embeds
0
Number of Embeds
1,523
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Arquitetura de Software - Concorrência

  1. 1. Arquitetura de Software ConcorrênciaAndré Faria Gomes @andrefaria
  2. 2. Concorrência éum dos aspectosmais difíceis dodesenvolvimentode software @martinfowler
  3. 3. Threads em servidores Transações Arquivos
  4. 4. Leitura Inconsistente
  5. 5. Vamos contar uma estória...
  6. 6. 1. China abre o ticket #1456 no Pronto e começa aatualizar a descrição do ticket.2. Segundos depois Rodrigo entra noticket, e altera.3.China salva4. Rodrigo salva
  7. 7. Moral da Estória? As alterações de China foram perdidas para todo o sempre...
  8. 8. LivenessA quantidade deatividade concorrenteque pode acontecer
  9. 9. Quando maisliveness menossafety(correctness)
  10. 10. Contextos de Execução
  11. 11. RequestCorresponde a uma única chamada domundo externo para onde opcionalmenteuma resposta é enviada.O servidor processa a resposta e o cliente aguarda.Alguns protocolos permitem interromper a request.Clients podem gerar outras request interfiram em anteriores.
  12. 12. RequestCorresponde a uma única chamada domundo externo para onde opcionalmenteuma resposta é enviada.O servidor processa a resposta e o cliente aguarda.Alguns protocolos permitem interromper a request.Clients podem gerar outras request interfiram em anteriores.
  13. 13. Session É um interação de longa duração entre o cliente e o servidor, uma série de requests.Normalmente associada a login e loguoutComum na Web, em Bancos de Dados, etc...
  14. 14. Session É um interação de longa duração entre o cliente e o servidor, uma série de requests.Normalmente associada a login e loguoutComum na Web, em Bancos de Dados, etc...
  15. 15. Processo Geralmente um contexto de execução mais pesado que oferece isolamento para os dados que estão sendo trabalhados.Oferece isolamento de memória e dados, por isso, há poucapreocupação com concorrência nesse nível.
  16. 16. Processo Geralmente um contexto de execução mais pesado que oferece isolamento para os dados que estão sendo trabalhados.Oferece isolamento de memória e dados, por isso, há poucapreocupação com concorrência nesse nível.
  17. 17. Thread Um agente leve, pode haver múltiplas threads por processo.Com threads é possível suportar n requests em por processo.Melhor utilização de recursos, são mais “baratas” que processos.Geralmente compartilham memória e dados.Alguns ambientes oferecem threads com isolamento.
  18. 18. Thread Um agente leve, pode haver múltiplas threads por processo.Com threads é possível suportar n requests em por processo.Melhor utilização de recursos, são mais “baratas” que processos.Geralmente compartilham memória e dados.Alguns ambientes oferecem threads com isolamento.
  19. 19. TransaçãoTransações unem diversas requests queprecisam ser tratadas como uma únicaUsuáriosIntegraçãoBancos de Dados
  20. 20. Lindando com aConcorrênciaProblemasacontecem quandomais de um agenteativo tem acessoaos mesmosrecursos.
  21. 21. Isolamento Dividir os dados para que cada parte, seja usada apenas por um agente ativo.
  22. 22. Exemplo de IsolamentoO sistema operacionalreservando uma área dememória exclusiva para cadaprocesso
  23. 23. IsolamentoA abordagem é tambémusada para arquivos. SeDouglas abre o arquivo Xele fica bloqueado eninguém mais pode editá-lo (talvez nem abrí-lo).
  24. 24. ImutabilidadeSó há problemas deconcorrência quando osdados podem seralterados.Por isso é importante quetudo que possa serimutável, seja imutável.
  25. 25. Controle de Concorrência Otimista vs Pessimista
  26. 26. Optimistic LockDetecção de Conflito Todos editam ao mesmo tempo, o primeiro salva sem problemas, os próximos não conseguem porque há conflito
  27. 27. Pessmistic LockPrevenção de ConflitoSomente 1 editar por vez
  28. 28. Qual a Melhor abordagem?Depende! Nenhuma é livre de problemas!
  29. 29. Lock de Leitura Shared Lockevita write lock,permite mais readlocks
  30. 30. Lock de Escrita Exclusive Lockninguém maispode bloquear
  31. 31. Deadlocks Um problema da abordagem pessimista
  32. 32. DeadlocksImagine isso com30 agentesenvolvidos...
  33. 33. Deadlock DetectionUm software que detecta deadlocks e entãoescolhe uma vítima para eliminar o deadlock
  34. 34. Deadlock DetectionÉ difícil de detectarPrejudica vítimas
  35. 35. TimeoutsMata se demorar maisdo que x segundos
  36. 36. PrevençãõDetecção e Timeoutssão formas de lidarcom dead locks, mascomo previnir?
  37. 37. Tudo no inícioFazer todos os seuslocks no ínicio de formaa não começar otrabalho caso algo nãoesteja disponível.
  38. 38. Transações É um trabalho sequencial com pontos bem definidos de início e fim, que acontece de forma tudo ou nada.
  39. 39. Comprar uma Cerveja
  40. 40. Sacar Dinheiro
  41. 41. Pagamento com Cartão
  42. 42. ACID
  43. 43. Atômicidade Tudo ou Nada
  44. 44. Consistência Regras de integridade dos dados são asseguradas, ou seja, as transações não podem quebrar as regras
  45. 45. IsolamentoO resultado deuma certatransação não deveser visível paraoutras transaçõesem aberto até estarcompleta.
  46. 46. O resultadocomitado deveser permanente Durabilidade
  47. 47. transações devem ser PequenasQuanto menores forem melhor!
  48. 48. Quanto ocorrem em multiplas requestsLong Transactions
  49. 49. Request Transactions Começa e termina “junto” com a request
  50. 50. Late Transactions Começa o mais tarde possível Aumenta o risco de leituras incosistentes
  51. 51. Lock Escalation Você pode acabar gerando mais locks do pode gerênciar...Quando o banco de dados tem muitoslocks em linhas, acaba precisandobloquear a tabela todaCuidado comLayer Supertype
  52. 52. Níveis de Isolamento
  53. 53. Serializável O nível mais forte de isolamento
  54. 54. Mike está Bob estácontando incluindo 5arquivos arquivos
  55. 55. Garante um resultado sempre correto,embora possa ser anterior ou posterior aalteração
  56. 56. Não garante que toda vez que vocêexecutar o mesmo cenário terá o mesmoresultado
  57. 57. Repeatable Read permite fantasmas Você executa duas vezes a mesma consulta e recebe um número diferente de registros em cada uma delas. não gerencia range-locks
  58. 58. Read Committed permite leituras não repetíveisA transação lê duas vezes omesmo dado, e em cada umdas vezes recebe um resultadodiferente. não gerencia range-locks
  59. 59. Read Uncommited permite leitura suja Você consegue ler dados de transações que ainda não foram comitadas
  60. 60. Equilíbrio entreLiveness e Correctness
  61. 61. Dirty Nonrepeatable PhantomIsolamento Read Read Read Read Possível Possível Possíveluncommitted Read Impossível Possível Possível committedRepeatable Impossível Impossível Possível readSerializable Impossível Impossível Impossível
  62. 62. Referências http:// www.thedeveloperday.com/ domain-model-logic-patterns/ http://martinfowler.com/ eaaCatalog/
  63. 63. http://en.wikipedia.org/wiki/Isolation_(database_systems)
  64. 64. Obrigado @andrefaria

×