Nota: Esta publicação está desactualizada. Você pode encontrar a versão mais atualizada aqui.
esta publicação está desactualizada. Por favor, Encontre a versão atualizada aqui. Estou intencionalmente deixando este artigo aqui para que eu não perturbe outros sites ligando de volta para mim.
vários anos atrás, o desempenho de construção em um sistema de software foi simples – você aumentou seus recursos de hardware (aumentar a escala) ou modificou sua aplicação para funcionar de forma mais eficiente (ajuste de desempenho). Hoje, há uma terceira opção: escala horizontal (escala para fora).A escala Horizontal de sistemas de software tornou-se necessária nos últimos anos, devido à natureza global da computação e às crescentes exigências de desempenho em aplicações. Em muitos casos, não é mais aceitável executar um único servidor com um único banco de dados em um único centro de dados adjacente à sede da sua empresa. Precisamos de ambientes verdadeiramente distribuídos para enfrentar os desafios empresariais de hoje.
infelizmente, os benefícios de desempenho que a escala horizontal proporciona vêm em um custo-complexidade. Sistemas distribuídos introduzem muitos mais fatores na equação de desempenho do que existiam antes. Os registos de dados variam entre os clientes / nós em diferentes locais. Pontos únicos de falha destroem o tempo de funcionamento do sistema, e problemas intermitentes de rede surgem no pior momento possível.
These concerns of consistency (c), availability (A), and partition tolerance (P) across distributed systems make up what ~~~~ ~ Eric Brewer ~ ~ coined as the CAP Theorem. Simplificando, o teorema do CAP demonstra que qualquer sistema distribuído não pode garantir C, A, E P simultaneamente, ao invés, os compromissos devem ser feitos em um ponto no tempo para alcançar o nível de desempenho e disponibilidade necessários para uma tarefa específica.
consistência-todos os nós vêem os mesmos dados ao mesmo tempo.
simply put, performing a read operation will return the value of the most recent write operation causing all nodos to return the same data. Um sistema tem consistência se uma transação começa com o sistema em um estado consistente, e termina com o sistema em um estado consistente. Neste modelo, um sistema pode (e faz) mudar para um estado inconsistente durante uma transação, mas toda a transação é revertida se houver um erro durante qualquer fase do processo.
as bases de dados relacionais típicas são consistentes: servidor SQL, MySQL, e PostgreSQL.
disponibilidade-cada pedido recebe uma resposta sobre sucesso/falha.
alcançar a disponibilidade em um sistema distribuído requer que o sistema permaneça operacional 100% do tempo. Cada cliente recebe uma resposta, independentemente do Estado de qualquer nó individual no sistema. Esta métrica é trivial de medir: ou você pode enviar comandos de leitura/escrita, ou você não pode.
bases de dados relacionais típicas também estão disponíveis: servidor SQL, MySQL, e PostgreSQL. Isto significa que existem bases de dados relacionais no espaço da CA – consistência e disponibilidade. No entanto, a AC não é apenas reservada para bases de dados relacionais – algumas ferramentas orientadas para documentos como a ElasticSearch também são abrangidas pela AC.Tolerância à partição – o sistema continua a funcionar apesar da perda da mensagem ou falha parcial.
a maioria das pessoas pensa no seu armazenamento de dados como um único nó na rede. “Esta é a nossa instância de servidor SQL de produção”. Qualquer um que tenha executado uma instância de produção por mais de quatro minutos, rapidamente percebe que isso cria um único ponto de fracasso. Um sistema que seja tolerante a partição pode sustentar qualquer quantidade de falha de rede que não resulte em uma falha de toda a rede. Os registos de dados são suficientemente reproduzidos através de combinações de nós e redes para manter o sistema em funcionamento através de interrupções intermitentes.
Sistemas de armazenamento que são abrangidos pela tolerância da partição com consistência (CP): MongoDB, Redis, Caching AppFabric, e MemcacheDB. Os sistemas de CP são excelentes caches distribuídos desde que cada cliente recebe os mesmos dados, e o sistema é dividido através dos limites da rede.
Sistemas de armazenamento que estão sob tolerância de partição com disponibilidade (AP) incluem DynamoDB, CouchDB e Cassandra.
conclusão
sistemas distribuídos nos permitem alcançar um nível de poder computacional e Disponibilidade que simplesmente não estavam disponíveis no passado. Nossos sistemas têm maior desempenho, menor latência, e quase 100% de tempo em centros de dados que abrangem todo o mundo. O melhor de tudo, os sistemas de hoje são executados em hardware commodity que é facilmente Obtenível e configurável com custos próximos de $0.
todo este poder de computação e benefício vem a um preço, no entanto. Os sistemas distribuídos são mais complexos do que os seus homólogos de rede única. Há muito mais ferramentas e habilidades que precisam ser adquiridas a fim de criar um sistema verdadeiramente escalável, de alto desempenho. Compreender a complexidade dos sistemas distribuídos, fazer os compromissos adequados para a tarefa em mãos (CAP), e selecionar a ferramenta certa para o trabalho são todas as habilidades críticas em um mundo onde os sistemas de computação estão se movendo para fora, não para cima.
