Baixar para ler offline
Carregado poriMasters
DevCommerce Conference 2016: Concorrência em aplicações que exigem baixa latência e alta disponibilidade
Este documento discute os desafios de concorrência, baixa latência e alta disponibilidade em sistemas de e-commerce. Ele propõe uma arquitetura inspirada no LMAX que usa filas de mensagens e bancos de dados NoSQL para gerenciar inventário de forma robusta e satisfazer clientes. A solução partiria produtos, usaria threads únicos e filas para processar pedidos de forma assíncrona e escalável.
Mais conteúdo relacionado
Semelhante a DevCommerce Conference 2016: Concorrência em aplicações que exigem baixa latência e alta disponibilidade
DevCommerce Conference 2016: Concorrência em aplicações que exigem baixa latência e alta disponibilidade
- 1. Concorrência, baixa latência e altadisponibilidade
- 2. HELLO! Guilherme Roveri Arquitetode Software – Grupo Netshoes @gbroveri 2 Eder Magalhães Arquiteto de Software – Grupo Netshoes @edermag
- 3. Agenda ▫ Realidadede um e-commerce ▫ Alguns desafios ▫ Caso de uso: Inventário ▫ Arquitetura LMAX ▫ Solução Proposta ▫ Conclusões ▫ Referências 3
- 4. Realidade ▫ Negóciodinâmico ▫ Marketing digital agressivo ▫ Oferecer ótima experiência de compra ▫ Evolução contínua nos bastidores ▫ Sazonalidade: Blackfriday 4
- 5. Concorrência Disputa frenética aoacesso a recursos partilhados… 5
- 6. Latência Intervalo de tempoentre a ação e o efeito… 6
- 7. Disponibilidade Percentual de tempoem que o sistema está no ar… 7
- 8. Caso de uso COMO umprovedor e-commerce PRECISO de um mecanismo robusto para gerenciar o inventário PARA evitar perdas E garantir satisfação dos clientes 8
- 9. LMAX ▫ Plataformapara comercialização de produtos do mercado financeiro para varejo ▫ Eliminar concorrência ▫ Regras de negócio usando memória e event sourcing ▫ Alto throughput c/ baixa latência ▫ Ex: 6 milhões de transações por seg 9
- 10. LMAX Composto por3 segmentos: 10
- 11. Business Logic Processor ▫ Fluxo denegócio ▫ Single thread ▫ Sem acesso a banco de dados ▫ Sem controle transacional ▫ Manipulação em memória 11
- 12.
- 13. Fila + NoSQLPropostade arquitetura c/ Fila e NoSQL p/ solução de controle de inventário 13
- 14. Inventário ▫ Operaçõescrédito e débito; ▫ Particionamento de Produtos; ▫ Single thread p/ Consumidor; 14
- 15. Inventário 15 Business Debit / Credit NoSQLPersistence REST Endpoint Message Broker
- 16. Inventário 16 Business Debit / Credit NoSQLPersistence Request REST Endpoint Message Broker
- 17. Inventário 17 Business Debit / Credit NoSQLPersistence Request Partition REST Endpoint Message Broker Request Queues
- 18. Inventário 18 Business Debit / Credit NoSQLPersistence Consumer Partition Request Partition REST Endpoint Message Broker Request Queues
- 19. Inventário 19 Business Debit / Credit NoSQLPersistence Consumer Partition Request Partition REST Endpoint Message Broker Request Queues
- 20. Inventário 20 Business Debit / Credit NoSQLPersistence Consumer Partition Partition Request Partition REST Endpoint Message Broker Request Queues
- 21. Inventário 21 Business Debit / Credit ReplyQueues Consumer Partition Partition NoSQL Persistence Request Partition REST Endpoint Message Broker Request Queues
- 22. Inventário 22 Request Business Debit / Credit Response ReplyQueues Partition Consumer Partition Request Queues Message Broker Partition NoSQL Persistence REST Endpoint
- 23. Inventário Tecnologias 23 Request Business Debit / Credit Response ReplyQueues Partition Consumer Partition Partition ü Spring Java; ü Spring Cloud; ü RabbitMQ ü Cassandra REST Endpoint Message Broker NoSQL Persistence Request Queues
- 24. Conclusão ▫ Odrive é o negócio ▫ Experimentar tecnologias ▫ Clean code: testes + testes + testes 24
- 25. Referências ▫ https://www.infoq.com/presentations/LMAX ▫ https://github.com/LMAX-Exchange ▫ http://martinfowler.com/articles/lmax.html ▫ http://www.datastax.com/dev/blog/scalable- inventory ▫ http://henryr.github.io/cap-faq/ ▫ http://www.slideshare.net/edermag 25
- 26. 26 Obrigado Questões? ▫ gbroveri@gmail.com ▫ edermag@gmail.com